GitHub Community, 29 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: South Africa Developer Community Meetup

Description

The first of its kind meetup is one not to miss, bringing together key industry techies from FinTech to HealthTech, who will impart both knowledge and industry in the fast-paced tech industry.
In our quest to build a world-class tech industry in South Africa and beyond, one of the key moves is building a community, one that grows together and builds a collective network.

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub and join our Meetup group: https://www.meetup.com/GitHub-Africa/.

Thanks!

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

Good evening, everyone.

B

How's it doing I'm sure if this is live, so welcome everyone.

B

Maybe we can wait just for a few more minutes or minutes. um Okay, we live on youtube. You live in youtube, maybe that's honor african time in minutes.

B

Maybe we can do that just a minute.

B

Good to see you, man, um we'll just wait for a minute or two uh for more people to join us. If you're already in, let's see see you yolanda see you innocence hello world. Indeed, ah there we go. We here we're doing this. We have. uh Thank you, everyone for taking the time.

B

uh We really appreciate you joining us for for today's session, um just drop us a flag of where you from um tell us where you from where you joining us from I know some of us are joining us in uh dear situations of load shading, uh but thank you for joining us. Thank you so much for joining us. My name is tuba. uh We'll just get the show started. My name is tuba mamba, I'm a software engineer at rocket shop where we're building uh stuff in the nft electronic dance music.

B

Thank you for joining us. Thank you to thank you to github for allowing us this opportunity to do this to build a community in south africa. um I'm personally excited about the prospect of what we, what we've embarked on the journey that we embarking on building a community in south africa and it's it's exciting. Honestly, uh it's exciting to to to to be doing this with all of you guys. uh This is not a one-man show. This is about the community at the end of the day. Thank you guys for joining us.

B

um Basically, today, what we want to focus on is coding community. I will tell you guys right now. The speakers are amazing. I think amazing doesn't even begin to describe, doesn't even begin to describe all of these guys. um Everyone here is talented and and experienced and passionate about what they're doing, and I'm sure that today's session is is is really going to change.

B

It's really going to change how we deliver software, how we approach our careers individually. It's it's really really exciting. um We we do have one speaker joining us. Gordon he's he's running a bit late. um I know it's a visual thing, uh but technical problems um he's going to be joining us, um so maybe just to just to keep kick it off. um What why we're doing?

B

This is because much as there's a high demand for people with with with tech skills, there's also a demand for growth as well, which is why we're here today, which is why we're establishing the github south africa community with it will come opportunities for growth opportunities for networking, within the space and from from joburg to cape town, to limbo, to to even rural, south africa and, above and beyond that, we we are excited to to also be impacting to the neighboring countries.

B

So countries like like a swat in countries like botswana, like lesotho and so on, we we really believe in in the community. We really believe the fact in the fact that for us to to better build a much um bigger and better community, it starts with. With such events, it starts with us bringing the community together.

B

Without any further ado, I will introduce vt, um I'm sure people know him as churches. On on thursday. He's he's he's a soft engineer. uh He kind he kind of cares a little too much about fifa and he definitely loves sharing um what he knows in the space. um I'm excited to to to have him on here. I'll. Tell you guys right now. The stuff that is going to be dropping here is amazing.

B

um Please do please do share on twitter, hashtag, github, community, hashtag, za tech bring a friend. Take a friend grab a beer. Let's, let's do this I'll I'll leave you to it. Thank you so much.

C

Cool cool- thank you um very, very uh tough, introduction to to actually live up to. um I know I don't know about dropping the most amazing things, but I'll try I'll try my best um thanks for thanks for having me here. um It was tough. uh You know deciding what to what to talk about, but um I've I've seen a lot of teams struggle with delivery.

C

So I thought you know it might be like a nice thing to not talk about so uh tonight, I'll be talking about delivering faster with trunk, based development and feature flags. um So hello about myself, I'm vt. My current role is chief technology officer at assault technologies.

C

um That usually means I'm, you know involved in building running and helping our teams within the space. So I'm often faced with you know, making sure that teams are delivering.

C

If you have any questions you can reach out to me on twitter, I'm fairly active as tuber said churches. On thursday we host the space under the hashtag zatek radio, every thursday, which is another great place to come and ask um questions. So what's the problem that we are talking about tonight?

C

um Well, delivery is hard writing code. um Getting it into production and making sure that it meets business needs is extremely difficult. So, as you all know, um in in almost every team you work in you've got different streams and the same code base. So you you're, working on different um different features back face bug, fixes hot fixes, as well as maintaining code at different levels right. So the solution to the problem of having multiple streams has always been branches right, and I'm going to assume that all of us are here using git.

C

So you know you're familiar with what branches are and don't have to explain it, but whatever company you work on the likelihood of your space. Looking like this is very high, so in most cases you've got a developed branch which is where you're pushing all your code and then you've got a master branch which might all you know recently renamed to main on github, um which might be pointing to the code that you have in production and in between.

C

You might have things like your releases, um taking those as well as like hot fixes and like of this very uh convoluted um way of working it. It is organized, but there are some problems that exist with it. One of them is merge, help right, we've all been in the team where I started a feature about two months ago, and now I want to get back into develop and it's just not possible.

C

That's happening because, like you know the the rest of the code, that is on on on on the current trunk, on on developers kind of like diverged from the code that you have on your local machine. This leads to problems like semantic conflicts, uh recreations under undeployable code and so on, and so on. We've all run into into that case, where we just don't know, what's happening at all a little disclaimer before I continue. I'm not saying things like git flow are bad.

C

um I don't think there is such thing as good and bad in in software development. I think uh software dev is a game of trade-offs, uh but this method can slow teams down because of you know the issues um stated above. So how do you deploy much faster right? Which brings me to the conversation of the day for me, which is trunk based development? What is it? Well? What do I understand it to be?

C

I think if you, if, if you talk to people or you look it up, um some people might tell you that trunk based development means everyone is working on trump right. um So no, um no, no feature branches or or anything like that. Everyone is just kind of just deploy. I mean pushing the code uh to the main to the main branch, and I know teams that have tried that, and obviously that comes with its own issues as well, but I don't quite think that's what trunk based development is.

C

um I think trunk based development is guided by a few principles right. So, as I said the number one one being that you have one trunk uh branch where devs match the changes, this branch is, you know it can be called anything can be called develop, it can be called main, can be called master. It can be called release. You can really call it whatever you want, but the main idea is that they only exist one which is like the you know, the golden source of truth.

C

The second principle is that devs should match small changes as often as they can. As I said before, uh contrasting it with, uh you know, git flow and other approaches where you might have you know a feature branch that lives for, as you know, maybe as long as as three months or something like that uh with trunk based dev, like the principles like merge, as often as possible, multiple times a day, but aim for at least once a day right which obviously I can you know almost sense.

C

You know people watching, saying, okay, cool, imagine every day what, if I'm, not done cool we'll get that we'll get to that later. uh The third principle is that mergers must be reviewed, tested and must not destroy the trunk right and there's multiple ways of um of doing this. One of them is like pull request, so you have your colleagues looking at the code and you know checking it against your team contract.

C

um You know, are things done properly and just kind of looking for any code smells things like that, but another good way of that of of doing that is like having unit test. uh You know as well as integration tests. You just make sure that the expected code parts are still working um and some teams might opt for something like tdd, which does this very well to say.

C

You know every piece of code that we have is- or at least as much of our code is tested automatically, and when you submit your pull request, you can automatically check that nothing existing has been broken and the new code has been tested. The fourth principle is that all code that is in trunk uh must be ready for release at all time. As far as reasonable. The idea would be that it. You know you maintain a green pipeline uh throughout. Obviously this real world.

C

So maybe it's not always something that you can achieve, but it's something that should definitely be aiming for, and then uh you know the fifth one is that feature branches must be short-lived. So, as I said, I don't believe that uh trunk based development means working directly on one branch without branching, but you know you do employ some branching. You just make sure that those branches are short-lived and the last one is keeping your commit messages. As concise as possible and also meaningful right, I've seen you know people type.

C

I hope this works that type of thing, but in trunk based development. Having your your, you know, your feature, your feature, branches being descriptive as well as your commit being descriptive. Just it just helps with a you know, a meaningful log of of of work that has been done cool. So that means that we move from this kind of picture uh to something a bit more simplified. So, as you can see down the middle, you have your main. Your main branch, which is your your trunk.

C

uh A developer can check out from trunk uh work on the feature and match back on, and then you know you can uh branch out of that, create a release brian to release to to production and merge back in. You know the following that flow, but making sure that the trunk is always um functional, but that's hard to do right um because, in the the the practice of making sure that you have um branches was not by accident.

C

As I said, it solves the problem of people working on multiple streams, but it introduces another problem, mainly being merged hell and when you get rid of those feature flags. Suddenly your branching by source control is, you know, goes out of the window, but branching is still necessary, so you can enjoy introduce something like branches by abstraction and this can be done with uh feature flags. So I'm going to show um you know a bit of a bit of code around that. um You know there's an example here on the screen uh currently in typescript.

C

I hope everyone here has at least worked with with react and typescript, and this makes makes sense for them. But you know uh trunk base uh development uses feature flags as a mechanism to manage like new feature releases.

C

So a feature is simply like a boolean condition that modifies the behavior of a component a module or function in your application right so like following a feature flag uh pattern, trace the simplicity of like having an isolated branch uh workflows such as skip floor, as I've mentioned in flavor in favor of something a bit more flexible in uh you know, feature rollout, continuous delivery and application uh personalization right. So a simple way to begin using feature flags is to maintain like a single file containing your feature flex.

C

So, as you can see there, the feature flex or tiers, where I have hello world new feature um initially set to false the feature. Flex can also be managed through, like external tools um like launch, darkly or optimizer.

C

Here, the new feature is returned based on the flag. um So hello, hello, world new feature is like a flag. If the flag is true, then the feature create new hello. World is return. Otherwise the old feature uh create um old hello. World is return right. uh This typescript module like feature flex or ts, can be like extended to fetch the features from external or internal services, um but there's you know also an approach of thinking about, like existing feature development with feature flag.

C

So it's quite easy or you know straightforward, when you're working with like introducing like a a new feature as you can, as you can see above, but you might have a case where uh you already have like you know, existing features that you want to slightly um modify um and it's slightly more complex but offers more flexibility. For you know continuous delivery and and personalization. As I said, um the first type is like you know, applying a small incremental change.

C

So if the, if the proposed feature is a small incremental change, we can modify like an existing code path to like augment behavior. So take the following example: um where we, you know, we have an existing calculation, so our function returns, um quantity, multiplied by value and we want our new calculation to include text um while we're still working on the feature. You simply say if that feature flag is enabled then return quantity times, value time, text, text otherwise return.

C

Like the old um calculation right, but this is quite like straightforward- you could also have like a large modification. um So if the proposed feature is large, for example, we want to display like a completely new text, calculator component. We would need to find a new code path and entry point for that specific component, as you can see here.

C

So instead of you know something as small as that text calculation, we return a whole other component and, like new feature feature flags are very, very helpful. I I've met a lot of people. Who've said feature flags, make everything very complicated, but you can find a way to simplify it by trying to make sure that the change is localized to the entry point um of your code base right. um So you know new feature.

C

Development with feature flags is simpler than existing features, uh but it's not impossible, but since there are no existing code parts for your code to execute the code path will be. You know disabled by default. While this feature is like a work in progress and a few things to keep in mind, are that new feature development process with flags should look like you know what you have in the screen, so you create a new feature flag for your new feature. uh You begin working on that code.

C

You ensure that the flag is false uh before merging into you know, into master or main, and then make sure that you measure code frequently when the feature is ready for release, then you remove the flag and, in conclusion, I think trunk based development and feature flags together can be used for continuous delivery, delivering the features faster to market planning them carefully, however, will allow you to quickly deliver the new business features to the system.

C

uh The feature flags can also be managed through external tools like optimizer and launch darkly and tools that provide sdk to manage the features or extend that external to their application. I think my time is up and I hope I hope that was useful um to you know to a lot of you, as I said um happy for you to reach out after this. I think there will be time for questions, um but I hope to see more teams and more people adopt feature flags and uh trunk based development to help the businesses deliver faster.

C

B

Thank you, vt. uh That was brilliant. um I see I see a lot of people still joining in. um That was brilliant. uh Thank you, so much vt for sharing that um you you that you guys can connect with vt on twitter at vt underscore codes. um I do see a question here. uh There's a question coming in from steve.

B

um I believe steve is in is in malawi, okay. uh His question is: what should a standard commit message? Look like can.

C

Yeah look, I think I think the the multiple uh the multiple practices, um but the format that I go with is first of all, just like breaking down my my commit message into two right, so the top one being a very short brief description right um so, let's say: there's a there's, a bug that uh there is about causing users to log out when they refresh right. um I proceed like that that message that description with my jira ticket number or my github issue right.

C

um So it could be uh issue number eleven, so you know hashtag eleven and say fix bug causing users to log out when they refresh or something like that, keep it short. um I tried to keep it just under like a hundred um hundred characters or even less just to make sure that it it's easy to read um in the uh when you like quickly glance at them.

C

You know at the history, but I try to make sure as well that, like under under the message, I make sure that I have a description, especially for like very tricky bugs um where it might be like a unique case where you might be. You might need to apply a hack, so same format, very brief description and then underneath you go into detail of what the problem was, but there's another approach that you've taken as well as um like why you've taken the approach and maybe any caveats that might uh might exist.

C

It just helps when someone else is looking at a piece of code and says this is very crappy code. And then, when they look at the reasoning, then they you know they're. In the same mind, space you're in when you committed.

B

Yeah cool, that's that's great advice. I see human solarian commenting there less is more! That's! I totally agree with that. I think uh yeah, the less is more and just making sure you know that anybody that's going to be touching that code piece as well shouldn't be confused as to what's going on in here. So I I like her.

C

But, but not so little as as so that, like it's, it's it's vague, and um so you know like wtf uh as a commit message, doesn't help anyone um but try to keep it brief. Like implemented a new login vision too, it's it's quite.

B

Easy yeah cool that makes sense uh thanks a lot vt um uh thanks man. Personally, I've learned a lot. Thank you so much for for joining us um yeah. Let's, let's meet again again, you can you guys, can follow vt on twitter at vt, underscore codes changes on thursday hashtags that uh then they take uh we're doing this. um We do have one speaker coming up. Derek crossan. um I met personally met derek a couple of years ago, um he's the gentleman responsible for introducing me to ruby and rails. Thank you derek.

B

um He is he's, got a background in system administration enjoys doing maintenance, work, uh working with tools that automate tasks and make systems more stable, he's currently working for doc fox.

B

He is going to be taking us through delivering uh software delivery with spinach. I will hand it over to you derek.

A

uh Awesome thanks man. Let me just share my screen.

A

Can you all see it.

A

Cool, I think it's on screen now um awesome so yeah. Today, I'm going to talk about software delivery with a tool called spinaker got some good news and some bad news. My talk was mainly focused around the really awesome demo I was going to do, but I kept hitting the resource limits, we're not trying to create the infrastructure, so we'll, probably like record a video and send it out to you soon, um but I'm gonna try and make sense of what's on the slides and hopefully you'll understand it um so cool.

A

um So this is what I'm going to chat about. Just uh tell you a little bit about myself in like a minute or two and then give you an intro into spinnaker and talk about um how it came about what problems it solves uh its concepts and then talk a little bit about monitoring resilience and that would have been the place where I did the demo. But that's not gonna happen today.

A

So this is a really bad photo of me. um My name is derek. I'm a software engineer at a company called doc box. We do onboarding of businesses and clients and basically build compliance. Software and we like scan terrorist database and political party databases and that kind of stuff and make sure that people aren't money laundering.

A

I used to do system, administration and technical work years ago, and what I want to do in the future is more of their box work and less writing features. So that's me cool, so spinnaker. What is vinnica so spinnaker is this tool that helps you manage the delivery of your software and it was created by netflix and now it's used and maintained by loads of different companies. It's written in java and where it does is allow you to continuously deliver software and also like run your software in multi-cloud environments.

A

So, for example, you could have half of your infrastructure on google off on amazon, azure, etc.

A

um So one of the the problems that spinnaker solves is you have like complete observability into your software and, what's going on at all times and I'll talk about that more a bit later,.

A

So some of the main things uh to grasp in spanica is everything kind of revolves around these things called applications, uh clusters, server groups and pipelines. uh Sorry ignore the description yeah. I just realized I forgot to put in the proper ones, but they are in the next slides.

A

So applications are clusters which in turn are collections of server groups and applications can also include firewalls and load balancers. So an application is basically in in spinach. An application is a service which you will deploy. So, for example, if you have a login service, a single sign-on service and a service to upload documents, for example, those will be seen as two separate applications, along with all the configurations and the infrastructure that will run on uh that the services will run on.

A

So that's just basically the definition of an application in spanica, and then we also have these things called clusters and server groups. So um server groups are the deployable artifacts, such as like a docker container or an aws ami, and the configuration settings like the auto scaling settings, the number of instances, any policies, security policies etc, and these you can have multiple of these server groups within a cluster and they can also be connected to a firewall or load balancer.

A

So when, when deployed a server group is just basically a collection of instances running your software- and this is what a cluster will look like in spinnaker. This is supposed to be like part of my demo, but I just had to find some screenshots since that's not happening. So um you you, you have your your different, uh your environments with uh all these green things and these rate things are actually um instances, so these would be either like containers or machine images, etc, and, in this case you'll see that they are behind the load balancer.

A

So that's just basically what the the ui looks like and then another important thing. A very important thing is pipelines and stages. So almost everything in spinnaker in terms of delivering the software is there's some reliance on the pipeline.

A

So um a pipeline is basically just a sequence of actions um and events known as stages and um within those stages. When something happens, and you you, like output, certain values, you can pass those params from one stage to another, so a pipeline can be triggered in multiple ways, so in some cases you'd want to trigger them automatically like when a job, completing getup actions or jenkins or whatever tool you're running same for.

A

If a container is created in a registry, you might um have an automatic pipeline trigger and there are also cases where you would manually um trigger pipelines. So um in cases where, like your, your, your pipeline goes through a process of testing and deployment to a staging environment, you'd usually have like your your qa engineer that will do whatever test.

A

They need to do, make sure everything runs, and then it will either be the qa person or a product person who would actually do like a manual step and approve that and once they do, that it will automatically deploy to production cool, and this is just an example of a pipeline. In this case, there's a bunch of things going on here and you'll see that there's these two periods where um the pipeline will wait and then deploy- um and you also have these uh these steps, where you can like manually, override certain things.

A

So in this case, if, if you're happy with whatever is going on here, you can just manually override and you don't have to wait for the 30 minutes or two hours in this case um and in within spinach. This is what um where a pipeline would look like. So in this case, uh what this person was doing is they had their tests running in jenkins and they have probably a containerized application.

A

So it goes through this bakery process where it's, basically just an image being created for an artifact being created from a helm, chart or something, and then once that's done, it will deploy and yeah in these steps. You'll see that um there's uh these, these things are uh and it's got a status. So what will usually happen? Is um your application will be behind the load?

A

Balancer, let's say, for example, you have like three instances running and as soon as this deploy happens, it'll put this new image behind the load balancer and take one of them off. So that's why you you deploy with no downtime, because the request- that's under the instance that's being taken off the load.

A

Balancer is still continuing, but uh the the new requests will go into the other containers, um which is just something that's quite smart to do, and also um the containers can be destroyed immediately or you can keep them for whatever duration you want to keep them for afterwards, so that makes it very very easy to like roll backwards in like minutes. If something goes wrong, because all that the software is doing, the the bulk system is transferring um transferring instances uh up to him from the load balancer.

A

So you can easily roll back or roll forward when things go wrong. This is also quite helpful in cases where, like you get uh something going wrong in production, you test it on staging, it's all good and, like you can only test again in the night, some production when people are offline. So I'm in that case you're going to roll forward again, and should you like delete the old image um you can still roll back?

A

It will just take a little bit longer because it needs to go through the process of creating the artifact again so yeah, that's uh basically, some of the stuff you can do in uh in a pipeline and then uh spinach also supports multiple deployment strategies.

A

um This is just a few of them um red black, which is actually blue, green. For some reason, spanica calls its red black, rolling red black and an area.

A

Analysis, um canary analysis is quite cool where you can like release some part of the feature to some users and some users uh get something different kind of like a b testing, um so yeah I've got some some resources at the end of the slides, um which actually um at all like one of the links, will take you to all the different deployment strategies that spinnaker has, and it will explain what all the differences are and actually show you in diagrams how they differ.

A

And then another thing that's important with any system is monitoring um and alerting. uh So spinnaker supports uh datadog, prometheus and staffdriver out of the box. You just need to put in your credentials in the right places and they'll work and you can send that data to a different tool like grafina or whatever you use for your graphing and dashboard creation and will just make things easier to look at and with within a spinnaker pipeline at any given point. You can also send out alerts for specific events that happen.

A

So, for example, when the pipeline is triggered, you can send a message to slack or text or the email or whatever you want to send um same for if it fails and just bring in images back or whatever you find necessary to send an alert for um so yeah.

A

That's uh just like the the default monitoring that it has and um something um like that's often um not practiced enough, I think, is resilience, um so your software needs to like scale and be able to like fail over and you need to have like um proper insights. I also didn't update that description, sorry and practice ks engineering, so in terms of scaling.

A

What many like larger companies do? Is they use microservices, so they they keep their services as small as possible and horizontally scale them, and often this is done using a tool like kubernetes and with that, what you can do is you can allow your disease like containers that are called pods. So what you can do is set a minimum and maximum value and it will always try and keep it within that range.

A

So um when you have automatic scaling turned on, and even when you don't it will, it will do what's called self-healing and when one instance of your software goes down another one comes back up immediately, so that just gives you high availability and prevents um many issues.

A

If it's done right and then in terms of failover, um there's a there's, a bunch of different ways to do this um with the bigger companies uh what they usually do is they run multi-cloud setup, so they'll have like a kubernetes cluster on aws, another one on google cloud or azure, or maybe all three, and then when, when a request, what what the first will do is when a request fails in one region, it will automatically fail over to the net region and then, um if, like for example, aws is down, it will end up getting re-routed to google cloud or somewhere and there's yeah there's a bunch of different ways.

A

You can do that um in terms of insights. uh That is also like part of like the previous slide. um If you, if you, if you know what's going on at all times, you can prevent things from happening and often we we we get like certain insights and alerts that maybe you are not very useful, but um we don't get enough of the stuff that um we don't spend enough time like getting the insights that we we could um get to like make things more stable.

A

So if you like, go, go and google like how uber detects their incidents and stuff um they've got some really good articles. I forgot what they call the the tool, but um they've got some really cool articles where they explain how they use like production-like environments and even their stubbed data for for their test.

A

Users are um like almost like production, and they they have like this single page where they can uh view whenever something is going wrong anywhere in the world and um if, if you catch it at the right time, you can prevent, um like the whole world, having issues compared to just one city, so um I'll, try and find an article and send it to like post it in the chat for something. um Then, in terms of chaos, engineering, I think netflix are probably like the best athletes and uh they have a tool called chaos.

A

Monkey that's actually built for spinnaker, um so um like in a lot of the talks I've watched from them.

A

um One of the things I have often noticed is they talk about experimenting versus testing so often when we're doing lqa or doing like any kind of testing to see when things are going to go wrong, we often testing for specific cases, whereas we should be like testing for things that probably aren't going to happen or just doing random stuff to see what happens and that's how you end up preventing a lot of race conditions and just making your software more stable.

A

um So yeah, that's just like a little bit um about resilience and then this is like an example: multi-cloud environment. So in this case you've got google cloud and another vendor you can assume. This is maybe aws and you've got some kubernetes classes, some engineers fingers ingresses and some communities pods. So what would happen would be. uh This is all behind a cloudflare load balancer.

A

So the user would visit this address and um while this request is being made, if the pool goes down or if there's something wrong on the one side at this point, that would reroute the request before the ttl expires. So what happens is everything just seems normal?

A

The user doesn't even know there was a problem and they have a really good experience and in most cases your team won't even have a problem unless, uh uh if your team won't even notice an issue like closely monitoring the log or unless it's um like a major outage- and that's probably like the way it should be because small outages should be handled this way. And if it's something bigger, then you need to look into it.

A

So that's just like a simple example of a multi-cloud setup and what it could look like and then, like the result of uh all of this, delivering your software in this manner and um chaos testing, especially with production like data or even in production. um It just makes things more stable and it helps prevent like lengthy outsiders and lots of revenue.

A

So the happier that your customers are the more money you're going to make in the business and everyone's just going to be more happy provided you've got a great culture and then I've just put in some resources on the slide.

A

So if you're interested in spinnaker home depot believe it or not, their engineering team brought something called spingo, which is probably the easiest way to um to set up spinach it's enterprise grade and production, really with all the security and everything um but yeah. If you do this, I recommend contacting whichever cloud provider using getting in touch with their sales people and uh getting your like getting the the access to the resources you need. So you don't have the problem.

A

I had and then there's about, there's a bunch of other um uh resources like um the youtube series on uh spanika and why we need chaos, engineering and that kind of stuff and uh check out this as well. It's called opta, it's it's like terraform, where it's very high level constructs and they even have something called um like a playground or something I think they call it where you can like generate your infrastructure code without even writing code.

A

You just click buttons and say, like you want so vpc and aws and this and that and it will generate the mo file for you, which is pretty cool and it uses terraform under the hood. um So yeah, that's just um some of the resources that are put together if anyone's interested, and I will record a demo soon. Sorry it wasn't available tonight.

A

um I hope some of this made sense, at least without the demo and then yeah thanks. So if you've got any questions, this is my details. You can contact me just to chat or connect with me on linkedin or get up or somewhere um yeah awesome.

B

Oh thanks derek that was amazing. um I see there's a question in there from steve. um Does this enable auto scaling before you respond? All I had from your talk was no more friday deployment, headaches, yeah.

A

D

B

I think everyone that's on here will will agree to you know these usually.

D

B

On fridays, because you know poor infrastructure and whatnot, so I think I think I love the spinnaker too it. It will really really just you know enable better engineering but yeah we've got a question from from steve. um Does this enable auto scaling.

A

um Yeah, I would have loved to have done the demo, so I could have actually showed you how to do the config and stuff. um So auto scaling is more about the infrastructure you're using like under the hood, so with autoscaling. You'd, probably want to use something like kubernetes to deploy your services if you've got a bunch of services and make your your kubernetes cluster auto scale so make make sure that the nodes uh also scale all the pods.

A

So whenever you, whenever you need to based on whatever your loads, are, and you could probably yeah, you could probably do it with like other images as well, um but yeah. uh Your spinnaker is just more like the management and delivery tool that gives you like a high uh level of observability and also um like um when you log into the dashboard. It also shows you, like your uptime and a whole lot of other stuff that we didn't see in you.

B

Okay, all right all right cool. I hope that answers your question steve um and just a question from me. They will not be any surprise bills coming from aws. If I use aws with this some ten thousand rand, you have ten thousand rand um bills coming in.

A

Well, uh if you're also scaling that could happen, um but it's all based on your load, so um yeah it's with any cloud provider. I think um it's easy to make a mistake, but, like I said like before, this is just the management tool. So you still writing the code to say this is how many resources you want- and this is when you want them.

A

So um usually, if you, if you your code, is really good and your infrastructure is solid, then, when you're getting more polls, that's a good thing, because it means you're getting lots of users and hopefully they will pay you. This.

B

A

B

Hopefully, um thanks a lot thanks, a lot uh derek for taking the time um we will make derek's slides available as well, and he did mention that he's going to be recording a video, um I'll post it on twitter as well. Just so that you see the demo as well. I do see a question from henry. Thank you henry for that we're going to bring vt back on, but for now we do have our last speaker. For today we had a speaker schedule, but unfortunately she had to undergo some sort of procedures with the doctors.

B

So we we just hope that all everything went well and she is getting better, but we do have garden. Beaming uh gordon is a father. He is uh he's a software engineer, I believe as well. He is he's a devops specialist at what's the name of the place.

D

B

Yes, um it's also a microsoft mvp um he's he's he's he's gonna be dropping some amazing stuff on he's, gonna be talking on on on why github um white github. So please help me in joining gordon to the stage.

D

Awesome great stuff thanks. Yes, I thought um something a bit later to finish us off. um We should have doubted some some deep topics which, uh if you've had to have those conversations at work. You know they get a very sort of.

D

um I think energize might be the right word um to describe that it's sort of a tabs versus spaces conversation when you start talking about uh branching strategies- and I think vt personally uh called me out when he says your commit messages and the hope this works, because at some point, when things just aren't working, I tend to use emojis to explain my current emotional state as my commit message, because I really have nothing else to say, but now that that's done, let's, let's dive in and see the sort of.

D

Why github, um just largely from a from my perspective of how um sort of my career and how things started off and and sort of where we how we are now um and why you should potentially start using github if you're, not so a little bit about me. You heard a little explanation already so yeah father husband, um currently a devops specialist at the rivko.

D

Also, I'm a triathlete and do other ultra endurance, sports and then yeah, some microsoft, mvp for github and azure devops and just a disclaimer, because we need those these days. Like all my opinions, of course, my own um so come at me with the pitchfork app the pitchforks um and not any of the other guys that you might think I represent cool. So why github? uh Where do we get started so long ago and sort of um discussed a bit about vt um introducing source code?

D

We did very dark things, so some of those things could have looked like the picture. You see on the right hand, side there, um those folders aren't git tags. Those folders are, I think, my code's at a good place. Now let me copy the folder paste, the folder change, the name or what you do.

D

Is you copy it and you paste and you say underscore back and then, when you copy the next one, it becomes underscore back underscore back and eventually you have a whole bunch of those folders and it gets interesting when you want to roll back.

D

You also tend to then have lots of comments in your code um and not the good kind of comments. You have comments of huge code blocks that are therefore in case. You might need them later, which is all the kinds of things that source control solves for you and then from a a backup perspective. When you say well, I use the cloud right.

D

You might turn to saying like dropbox or onedrive, and then you have your code sitting in a folder, that's synced, and that way your code is at least backed up and you sort of don't have to worry about, losing it completely, which again is something that, um when you're using version control, especially if you're pushing in the case of git to remote source like github, that's sort of taken care of for you, so next I'll just run through some of the things that github has and why I like it as a platform.

D

So the starting point, of course, like I just mentioned, is that it has source control. So if nothing else push your stuff to github, um you can have as many branches as or as many repositories as you want. So push all your code there. If it's some random project that you kicking the tires on you're, not sure if it's going to be anything just push it out there get into the habits of always using source control locally in visual studio, even if I do have a repo locally just to some random console app.

D

That does, I don't know some pausing of text files I'll put that under source control. Even if that is just get on locally, I don't push it to remote source. It just sits locally, but it's always still under source control. Basically just build that habit. That is part of your life and how you you work um day to day the nice thing, though, with github. Is it's not just a source control platform so forever ago, as I mentioned, I sort of had these folders and you renamed the folders and that wasn't great.

D

Then I moved on to something called codeplex, um which was an interesting beast. um It basically did source control for you, but it allowed you to sort of integrate with any well with a lot of different kinds of tools, so you could use svn into there. You could use cfvc, which the team foundation version control. You could use mercurial and the platform itself was great and it started building like for me personally good habits into having your source control somewhere your source somewhere else.

D

That's not on your machine only, but the last thing when you're using a platform like github, is that once you start putting your source out there, it's also good place for you to start planning your work. So, whether that's you just jotting down a bunch of issues saying I want to add this feature. I want to add this other feature. I want to add this other feature or if you go a bit more complicated and use the projects feature.

D

That was recently, I think now in public preview, where you can manage more complex projects like it gives you everything you need to manage what you want to do with your work, so don't have a notepad locally somewhere or a bunch of comments in your code. That says. Well, I need to add a button to this page. I need to go and make this one thing.

D

Green um rather come create issues for that and later on, when you start building a community, your community can come log issues to tell you hey, they found a bug and they can give you some information around what they found with their bug, because you can then go and fix that for yourself as part of that process, and because I mentioned community and there's pull requests so your if your code is public to um to everybody, anyone can go there fork your repo make a change and submit a pr to you.

D

So if there's some parsing bug that you that someone's logged an issue for I can walk up to your repo, I can be like oh there's, this parsing bug go and fork it because I think I know how I can fix it. I fix the bug and I tested on my side and it works, and then I submit a pull request to you.

D

You accept that pull request, and now I've contributed to your project um that bug's fixed and you didn't have to fix it um and that's what's great about github um is the community, so you can see in this case as well, you'll notice with this pr. It says it's busy running some checks. um Awesome checks haven't completed yet, which has a little section at the bottom there.

D

In this case it's busy running a workflow. That's busy checking that everything's. Okay with this build, so it's busy doing a cr, build just to make sure that the code functionally works. At this point, you generally have tests running potentially deploying to an integration environment running a bunch of automated tests against that just verifying that the quality of the code that's coming in is actually good enough to go into maine, and these kinds of things is what facilitates things like trunk based development, which vt mentioned earlier.

D

Once that's done, you basically click a button that merges that code into your main branch and you can move ahead.

D

The I mean I slightly touched on it, which was the fact that a workflow was running in the background um in github the the platform, the part of the platform for that is called github actions, and that runs multiple workflows that you can trigger off almost any events inside github. So if someone creates a new issue, you can run a workflow. If someone adds a new comment to an issue, you can run your workflow.

D

If there's a new pull request, you can run your workflow um pretty much anything that you want to almost automate on the platform. You can run a workflow for and then of course, the obvious thing that of actually building your software and packaging it to deploy it into environments. You can also do that with github actions.

D

So if we dig into this workflow specifically, you can see there's a whole bunch of jobs, so there's a build job. There's one downloads, backup files, there's one that logs into the github container registry, and then we do a docker build image which we also push then to that github container registry, so not a very complicated workflow, but for the specifics of this project, that's all it needed to do, and if we run, if you open up one of those jobs, you can see that you have the command line output.

D

So if you were running this locally, that's the kind of thing that you would see so from debugging. You are able to see that inside the platform and if you do click on like the line number there you'll get a a direct link to that line.

D

If you do need to share that with the friends you say like you, don't know why maybe something's breaking on a certain line once you sort of go past the sort of intermediate stuff of the platform- and you start looking at security, um which also these these things are literally just going and enabling um some toggles that says.

D

Oh, I want some more some more security, please um in in the case of code scanning, that's using in this case an external provider called snake, but what they doing here is constantly scanning the code to check for security vulnerabilities and then servicing that in the interface. For me to be able to see where I have issues with my code as part of the platform, you can see there's a little tab there for depender bots.

D

So what that will do is check for any dependencies that you have so it's their nougat dependencies or npm dependencies that might have vulnerabilities in the case of depender bots. It actually makes the pull request for you, giving you all the information of what the vulnerability is.

D

Obviously, because it's changed code you get to see exactly what the dependency is, that it's updated and then, if you have your cr builds in place, those will run to validate that nothing's breaking by updating that dependency, and then you can just pull that that updates a change into your main branch again without having to do any real work.

D

There I mentioned it earlier, um but obviously the big thing about github is the community, so from the um dr verse update uh latest update from, I think it was last year I said that there's 56 million um plus total developers on github and they're 72 percent of the fortune. uh That's supposed was it. I thought it was 500, maybe it's 50, maybe I topped companies are using currently github enterprise and that specifically in 2020 there was 60 million plus new repos that were created on the platform.

D

So when derek was talking about scaling like just imagine all that workload on github and you never notice it, the the experience you get using the platform as if you're running it locally on your own machine, and you are the only person, um that's how well the platform currently scales, there's a lot of obviously cogs behind the scenes to allow that to happen. um But this gives you an idea of the sort of size of the vol of the service.

D

um So you could be certain that if you join us you're going to have a great time and then again last year, specifically, there was 1.9 billion contributions, so that'll be new issues commits pull requests those kinds of things that were made on the platform um again talking community, the you don't have to always um sort of host your own stuff. So, yes, hosting your own stuff on the platform, is a great way for you to keep a backup of your source, get used to using the technology.

D

um Often these days, when you go into job interviews like well, have you do you have any experience with um cr and cd? What source control do you use um for you to be able to point someone to your public github profile um where they'll be able to see what you've interacted with what you host yourself there like what that looks like that's a huge benefit um from a career standpoint um for people that are looking to hire you, um but then away from having just your own um stuff.

D

On the platform, as I mentioned, you could go to something like net. So if you do work with netscore or now.net synth.net five, you can go to that repo um and you can look for the issues.

D

So if we go to asp.net core specifically, you can see that there's a whole bunch of issues that get logged there and if you look specifically for a tag in most repos saying a good first issue, you'll find things that the the maintainers of that repo, so the guys that work with the reaper every single day have looked at and have deemed um a good issue for someone who's new to that code base to look at and to contribute to.

D

So what that'll basically mean is you're going to go, fix the bug or add some small little feature to the code base once that gets accepted into the pull request?

D

um Millions of customers, in this case for asp.net core millions of customers around the world, will be using code that you wrote and it's all, because you came to something as simple as a an issue in github saw that it looked like something that you could do you made a pr it got accepted um and that exposure and contributing to all those open source projects will help you as a developer, be one a lot more attractive for being hired as well as your experience and exposure to things will be, will be great doing things like that, and then I mentioned your profile.

D

So when you on this on social platforms um or like with your cv, have a link to your profile. You see at the top there you get to. If you create a repository with your same username, um your readme file will be shown at the top, so you can put a little bit of information about you.

D

You can then go and pin some of some repos that you contributing on as sort of pins for people to like go dig into those and say like these are the ones that you, I guess most proud of or that you want to highlight as part of your profile and at the bottom. You have a um well my brain just lost the words, but it's your commit graph of which days you've committed code or it's actually now. It's which days you've interacted on the server.

D

So there's issues commits, um as you can see, there's specifics, there's contributions. Now it's commits issues, pull requests, everything on the platform and the darker, the green, the more you contributed on that specific day, which is quite nice um for you to go and be able to see and use, as obviously your your personal portfolio and that's a quick overview of issues.

D

Obviously I didn't demo anything 15 minutes is very quick but you'll reach out to me on twitter or linkedin. um The link to my personal portfolio, where that links out to every other social platform that I'm on is also mentioned at the top of the page there. I'm always willing to help out wherever I can thanks.

B

Hey garden, can you hear me.

D

Yeah, I can hear you.

B

Oh cool thanks man. uh Thank you so much for for that. That was quite um less less intense than.

B

D

B

Yeah yeah, you kept it really light and- and I think version, control and learning how to do it properly is one of the most fundamental skills in tech, uh especially as a soft engineer you you really don't want to get in in the workspace sure you can now use pinaka. You can now do um you know everything else, but once you have missed the mark of you've missed the the importance of version control, then you might just have a problem with a particularly larger teams, uh but.

D

B

I don't see any question um I think mine would have just been to highlight the you know the importance of of what you've been talking about and thanks again for taking the time. Thank you for for sharing. You know your knowledge um to everyone. You can reach out to garden on twitter at garden, biming and linkedin, and we will make these slides for all our speakers available, as well as the recording will, I believe, will stay up on youtube, um but we will bring vt back up. I know these uh there's a question earlier from.

B

From henry from henry henry, um so henry's question is: is he replacing kid flow? Is it both on top of get.

C

I have to trade carefully here. I don't want people to stump my twitter and.

C

I don't want people to stop.

B

Myself and tell me.

C

That I said I I said you know kid flow was cancelled. Look I! I don't think it's a matter of something replacing the other. uh Like I said in the beginning, you know my disclaimer, I think uh programming is a is a game of trade-offs right, um so they certain considerations where, uh like you know, you need to look at what you're doing in order to decide which one works for you. uh For me.

C

I have five of these uh things that I look at so team composition, the product type, uh the authoring process, uh the deployment, as well as the release frequency.

C

So, for example, if you have, um if you don't, if you lack seniority in your team, so you have like a team full of juniors and or you're working with like uh vendors or third parties, then I would opt for uh kid floor. um You know because it kind of like lends itself to a bit more control and where you might want to keep it keen eye on things.

C

If you are, you know a well-composed and experienced team uh or you're, you know um augmenting a team so you're all working together as as opposed to like a third party contributing. Then trunk based development might be something that that works. When you look at product type, uh if you're working with like a complex, mature or monolithic product or a brownfields, uh you know product, something that already exists is in flow. uh Git flow might be.

C

You know something very good to use there where else, if you're working with like micro services um or you're, building like pros of concepts or prototypes or uh distributed system components, uh trunk based development might help, like imagine like the onerous process for like 100 micro services and wanting to like use git flow for each one of them. uh The authoring process as well. Look if you have something governed normally like where you have a team that has um like a release, trained engineer or like a release manager.

C

So, like super kevin thing, you might wanna use uh git flow, but if the authoring is like team driven, then trunk based development might be a thing for you to use there. If you look at deployment, uh you might have like again like various um models where you have like a release manager, and you know they want to deploy on a specific day um and they wanna. You know like decide what that person might decide what goes in and what doesn't go in um that kind of control might require you to use git flow.

C

Where else, if you want, you know a little more towards like continuous deployment practices, things like feature toggles soft self-service automation, so you know things like uh git ops and chat. Ups, then trunk based development might be what you want to go for and lastly, uh you know: uh git flow lends itself to like a slower release. Cadence and please don't matter me it does because it's it's normally. uh You know a bit more controlled and uh the schedule is usually predetermined.

C

So you know we're releasing on on the third of december and if you're not down, it's not going in need to make sure that what goes in is done. So uh you know slower release skaters, you might want to go with git flow, but if you're trying to be like amazon and deploying every second right and teams want to iterate very quickly and independently, then uh trump-based development might be the thing for you. So look it's a it's not like uh one. One size fits all kind of solution.

C

uh It has to work for your team and there are a lot of things to consider and obviously like it might be a mix and match so short answer. No trunk based development is not replacing git flow, cool.

B

uh Derek you want a weekend on that. One.

D

I was just going to highlight the the comment there by the github accounts of it depends um so.

A

D

Great a great video for from that was released with universe which, like gets into all of these things, I mean often I mean it's been way too many years um now in software, but everything becomes like your whole team will decide like this is definitely the way to work and then a new guy will join you'll, be like actually maybe we're doing it wrong. Like you, you question how you work, based on the the the dynamic of your team and like it was mentioned already like.

D

If your machine, your team, is very mature, then trunk based dev works very well. um If your team's, not mature or you don't, have quality and security based into your pipeline, then that's potentially a time where trunk base is also not ideal for you.

D

But if you want to start moving faster and with more quality like trunk based, dev is one of the things that you're going to turn to to enable that.

B

Cool make sense there anything.

A

um I don't know twitter, so I'm gonna say trunk face for the win um yeah, I think um yeah. I think it just makes you release faster. Things are easier um yeah if you're working with a more mature team and more like intermediate convenience, it's just easier like there's, no need to add extra layers and extra processes, um especially like if you're in a startup, where you need to release like sometimes every day. um You want to get the code out there as soon as possible and keep your clients so yeah. I prefer trying fish.

B

Cool um unless there's anything, I think we have exhausted our time. But gentlemen thanks thanks again for for joining us. Thank you for sharing your knowledge and taking the time um we will make everyone's talks available um thanks to the community as well for for joining in. I know it's a friday um friday evening, depending on where you're joining from, but uh thanks thanks again everyone.

B

The talk will be available.

D

B

Well, you can follow the github community on twitter uh for more updates on community events and all of that, uh but until then we will be pleased again, please, uh if you're interested in being a speaker, we will be posting links, uh do follow uh the github account on meetup to make sure that that you, you notified of updates events and and all of that we do have an event coming up in november. If you're interested to speak, please do just uh hit us up uh connect with us, but until then thank you.

B

Everyone until next time, thanks for having us and thanks for everyone who attended.

C

D

Thanks a lot, that's great thanks.