GitHub Universe 2017 - From the GitHub Team, 29 Nov 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Fine Tuning Your GitHub Flow: A Deeper Dive Into GitHub Workflows - GitHub Universe 2017

Description

Presented by Stefan Stölzle and Grace Park, GitHub, GitHub

Workflows come in all shapes and sizes. Teams developing web apps have slightly different needs than those working with embedded software, and you have probably heard more than one recommendation on the "best" workflow. In working with hundreds of customers, we have learned that the best workflow is the simplest workflow. It is easier to teach and easier to follow -- both of which result in more consistent application. In this session, we will break out the markers and learn how you can trim the fluff from your workflows.

About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.

For more information on GitHub Universe, check the website:
https://githubuniverse.com

A

A

Just wanted to thank everybody for coming out to github universe, I'll.

B

A

Everyone, maybe a couple more minutes- are they struggling in yeah I just want to thank everybody coming to our talk, fine-tuning your github flow.

A

We did a similar version of this yesterday, a workshop, so I just want to let everybody know if you went to our workshop yesterday will be giving a similar talk, so you might want to go to another talk right now. We won't that no hurt hurt feelings. If you decide to go to another talk.

A

Alright, so I think we'll get started, so my name is Grace Park I am a services solutions engineer on the github professional services team, and so that essentially means we help github customers and github enterprise customers get onto the github platform and one of the ways that we do, that is through educating end-user developers, and we also helps this admins get onto the platform. We help them set up their organizations and sort of transform their workflows and so you're getting a quick preview of what we do in a typical workflow consultation and I'll.

A

Let Stefan do his own intro.

B

Oh there we go so hi everyone. My name is Stefan I'm on the services team as well. I usually work out of Germany. So that's. Why had a funny name with the funny dots on the elf I'm, a services engineer and help our customers move on to get up Enterprise migrate from other platforms that they might have used in the past, but then also help them define a workflow. They find something that will make them a more successful team, a more successful software organization.

B

So this is where this talk is also, then, in the later part, is looking into into some real-life examples that we've seen with some of our customers, but before we get there grace please yeah.

A

So, just a quick agenda for what we're gonna talk about we're going to talk about some of the challenges that we face and then we'll go into a couple of workflows that have been pretty popular I just to get a raise of hands who's familiar with the get flow and who uses the get flow wow. That's quite a bit and who's familiar with the github flow and uses that in their workflow awesome, ok, cool, ok, so I know that we're gonna be doing a high-level overview of these workflows.

A

Give you some examples since we're on the professional services team I think you might have seen the ask Services booth out there feel free. If you have any specific questions about your workflow meet us back. There we'll be here around all day today, all day tomorrow, and we can go through more in-depth questions that you may have because I know this is sort of a large space and I'm sure. Most of you have very specific questions to your specific workflows. So so, let's get right into it.

A

So some of the challenges that we face I would say that probably everyone on the professional services team would actually agree with me and that, while the technical challenges are key when designing a workflow and we actually the most difficult challenges around culture transformations, and so it's when we talk about culture, we're really talking about the idea of communication and specifically communication amongst teams, and so if we look at something like this, this is fairly standard right. We know exactly who's accountable for what you have one manager.

A

You have these people, and so really all the people get the attention that they deserve and it's pretty satisfying just on a human level, because we know who's accountable for what, but they think is even in a model of that size. It's actually not without its challenges, because, while sharing the vision is fairly straightforward from the top down from the bottom up, once we get into the weeds of a project that vision can start to deteriorate fairly quickly, and so, if we think about it from a software perspective, developers I would say in general.

A

I'm sure you all know depend on the work of other developers and many times they can be geographically distributed in different places, and so, as we see here, we're already starting to see more managers get involved, we need more people to help manage others, and so we find ourselves many times creating structures based on responsibility.

A

It could be around business units, geography, functional areas and when that happens, I think you've, probably all seen this in your organization's silos, start to break off right, and so the thing that happens many times when we do workflow consultations, which you're seeing a quick preview of today there becomes lost development time. An example of this is that we were doing a workflow consultation with a team and many times we like to have leads of development teams that actually haven't worked with one another. That often and the reason we do.

A

That is because we want to know the different types of workflows in the company, and we know that in an organization there can be multiple workflows, and so we were talking to two teams. We were doing an instance, consolidation where we consolidated code and we realized doing a search that those two exact teams had created the same exact JavaScript framework, and so what ended up happening is not only is that lost development time, you're sort of in this really uncomfortable position.

A

Where now you have to decide which one is better than the other, and so if we take it back to our chart right here so say, for example, the yellow dev means to talk to the green or blue or they're trying to solve the same exact problem, and so, as the orgs get more complex, you really, if you're one of the devs, don't really know who to go to for the information right. And so, if that can go a couple ways you can either just act without knowing or since you don't have the you need.

A

You don't really act at all, and so naturally, what happens in this state is that you go to your managers right and hopefully your manager will do a call-out to other managers. Hopefully they would have heard they'll ask their teams, hopefully you'd, have heard and then they'll relay the information back right and I think this is fairly common. So what happens?

A

Is it's essentially an enterprise-grade of telephone, and so actually this is probably more similar to what you know we're all used to and if we look at this chart, there's only one thousand two hundred forty eight people on this chart, and so now, if we're trying to look for the yellow, green and purple devs, who need to somehow find each other, it can become a game of Where's Waldo right, and so how are they going to find each other in an org chart that looks like this, and so unfortunately, when we have, you know doves that are working on the same thing, while that's also lost development time, there's also a real cost here, right and it'll lend itself to more bugs delays and then outages or even security events, and so unfortunately, on top of that, what happens?

A

Is that we've seen in our experience that, rather than getting to the more well fleshed out solution and trying to figure out what was the real problem at hand, we all resort to sort of these good enough solutions or hacky workarounds and that's very natural and we've seen that many times is working with our customers, and so, when we think about it, we want to acknowledge that the tools can impact our workflow, whether we intend for it or not, whether it's easy or hard it's going to affect our workflow and, for example, if you think about something like subversion, I think it's fairly common to say that with subversion with subversion, branching can be a rather heavy operation right, and so what is the natural?

A

You know thing when something's hard, you don't do it right, and so, if you don't branch as much by extension, the branches will become longer lived right, and so this will essentially move us a from a more feature: branching workflow into a more sprint or release based, workflow, right and so another example of that would be merging branches, especially when branches are long-lived.

A

What naturally happens is that we've seen in customers is that they have merged teams right if it's hard to merge, we're gonna messes, we're gonna need more people to help with that, and so what naturally happens is we have doves that are working on their code and then they sort of throw that over the wall, mentality to the release team or the merge team, and so what happens is we have these risky islands of domain type workflow in these types of companies, and so the get flow, I think actually I.

A

Think most of the people in this room we're using the get flow as opposed to the github flow, and so the github flow. The get flow was published back in 2011 and it's been pretty viral since and I think a lot of the companies that we work with actually work with the git flow, and so the git flow was really what we've seen was a workflow that matches environments.

A

For example, it emerged when they were mimicking their already existing infrastructure and they were trying to move more towards that infrastructure, and so what we try to think about is well. It's not mutually exclusive is how much of your workflow is based on the infrastructure, that's already existing versus what makes the most sense for contribution, and so you know the git flow has been around and it's very well tested it's flexible and it's been working quite well for a lot of customers, and so, as I mentioned before, this is fairly common right.

A

We have a production environment, staging testing and the individual devvra environments, and so, if we actually look at the get flow, it almost matches it identically right.

A

And so we like to think that while the workflow is comprehensive, it was built for more of a pre DevOps worldõs published back in 2011 and so many times it's optimized for a more man, we'll review in execution and as opposed to what we believe is more modern-day best practices with automation and testing.

A

And so, when we work with our customers, we find that typically in larger organizations, while the rules of get flow, if they're enforced well, it can work very well, but with the larger organizations we find that those rules tend to break down, and so Stefan is going to give a quick overview of the github flow.

B

So talking about the github flow, so the next couple of slides are pretty straightforward. Take them with a grain of salt they're, pretty much straightforward so where we come from what the github flow is really a master branch. This is our main line. This is our deployable software. This is our clean version of code, so everything that is a master is stable.

B

This does not mean there's no bugs, but what happens if we create a new feature, we branch off. We develop our new feature through a pull request. We discuss the code, we merge it back in and it's in our streamlined software, its deployable, its might be life right away. If it's a website, if it's embedded software, you create your artifacts out of it, your installation files and you name it and there you go. That's all you need. So what do you do when you need to hotfix something?

B

Well, actually, our first off call it feature branch call it development branch, it just looks exactly the same. It's just a different color and same thing with a hotfix, you branch off your software that is currently booked. You fix fix that feature, you merge it back in, and everything is fine.

B

Then this is where why I'm saying take it with a grain of salt, they all look the same. They just changed the color. This is how you do your release. Maybe you have to do a little bit of clean up a little bit of advanced changes. You do that on your branch, you merge into master and you're done and whose merged into master straightaway right away so yeah, but so you know same old joke. It works every single time. You don't just simply merge into master. Why do I say that?

B

Because we all know we need more control in our workflows. We need some gates to be enabled there, so we want to protect our master branch from accidentally changing without as knowing ahead of time if the software or the code that we're merging in actually is not breaking everything. So what github allows you to do there is it allows you to protect your master branch, and this protection first and foremost enables this protection with that protection enablement.

B

What it does it disables force pushes to that branch, this force pushes can be really really bad and who has forced post push to master and who has broken software with that force? Push so I'm, not alone, that's great, but then also. It also helps us not accidentally deleting that branch and we're talking about master right now, but this could be applied to any other branch and why that is important, we'll get to later so protecting our master branch from these accidental things is one of the first steps that we can apply.

B

So what we do when we create a new feature or a hotfix or you know, we create a branch off of that protected branch, and then we do our development. We create our branch, we create our commits on our local machines, we check them into github and then we create first. First we do need feedback. We need to feedback what's happening. Maybe this is where you do test-driven development.

B

So your first commit is your test suite your test cases that you check in and then you run circle CI. You run Jenkins you're on Travis CI, or you run any of these other continuous integration tools or a selenium testing neuron. So no cube for code quality and things like that, and they report back right away to your developer. How they're doing on code? Is it really good enough? Is it well tested? Is it buildable? Can I merge with confidence at the end?

B

So when we do that, we get these statuses back and we require these statuses to be green to be checked. Otherwise, our merge at the end won't be happening, so we're not allowed to do that merge. So when we're on our pull request, what we do here, then, subsequently, we also enable a discussion around our code, and this is not just the discussion around okay. Is this good, or do we put in a couple of really funny gifs or gifts I'm, not saying you have to use one or the other, but yeah?

B

This is where we just get into play, but, more importantly, we can require a review from our peers from our QA team or QA team, to look into our software to the code that we changed, that we added that it is peer reviewed that is pair up on. Then we can enable that feature in our protection of the branch as well. So we require this review from our peers from our teams by checking box and there's also a box that now says- or that is not checked here, but that says require review from code owners.

B

Maybe you have a repository that is not just one piece of code, but maybe there's several different sub projects in there. So one sub project is done by this. One team and the other sub project is done by another team with a code owners file that you can pull it onto github as well. You can define if a certain team automatically is required to review that piece of code that was changed if it's in a subfolder or a certain file ending, or something like that.

B

So when we have that enabled we enforce this review before our merge can actually happen.

B

What we do next is we're getting into that ready stage for our merges, and here we have now these different check boxes in our protection set and another one is really this up-to-date check for our branch, because we all been in that situation, where we try to merge our branch into master, and it said oh you're, out of date, there's a merge conflict. You have to resolve. First, with that button, github will show you there's code changes from your other development teams from your colleagues that happen to master.

B

While you were developing that feature so update your branch, so that CI testing and all that can run again and it checks that everything works cleanly and you don't end up with that conflict master, but rather on your branch, where it can easily fix it in an isolated stage, and so you have confidence to merge at the end. So at this stage we know all our review is done. Our CI has all passed in our our branches, up-to-date to merge. So when we finally merge, we could even be more restrictive here and say: hey.

B

We don't just want anyone to merge into master, because you just don't simply do that. We have a couple of things here in play already, but what we can do on top of that we can say, there's a release team. There are certain merge managers. This is all optional, so you can include this as single individuals or as teams to be able to merge this pull request, and this is now all setting the stage for our merges.

B

But this is all one branch, one pull request, or one master branch, one feature branch, one hotfix branch, this from real life examples that will worked in these work for consultations. That grace was mentioning. We realized. This is often way too simple, because the world out there is complicated. The enterprise world is even more complicated. So what are actual real github flows flows, workflows that we will look into that are used.

B

So, let's look into something- and this is as an idea that you can take out into your teams and play with these ideas with these concepts to find that perfect flow. The perfect workflow that works for your team, together with the platform that is github. So one example- and this is something that came up- came up through the workshop that we did yesterday. A lot of people said well, master is fine and the future branches are great as well, but we want to have that a little bit more controlled.

B

So we protect our master branch, yes, but we don't want anyone to merge into master just on their own account.

B

We want sort of feature freeze before that, so what we allow our developers to do throughout their sprints throughout their development cycles, is we have that parallel development branch, where everyone can branch off apply their new features or code, their new fleet features and merge in with all these different gates in place old CI checks, code reviews, so if it's merged into develop, then we're there, but then once we're at the end of our sprint, a release manager would go ahead to a code freeze and create that pull request at that certain point in time on to master.

B

That is then in the future, holding our new software. At the same time, it's called a code freeze, every developer could still continue with the next sprint already on the development branch, while the code freeze is set up in this pull request against master. So this is one of the examples that actually was discussed. Yes in yesterday's work for so and I think this is one of the great examples how you can apply something as simple as the github flow, but take it to the next level and make it your workflow.

B

But then, if we talk about something more complex where we might have to support multiple versions of our software, just think about something where we support four different versions of our software, but then also have continual development into the future. So here we have a feature branch. So these are not real branches. They won't stick around for a long time, because what we do when we release this feature or at this version two point, eight point: zero.

B

We create a git tag, so we can always easily jump back on it, create a branch at that point in time and do something on that branch. So now, for example, a a bug fix a hotfix needs to happen on our current master. That was discovered that was reported. So we can just branch off once more, create that hotfix branch do our fix and when we're ready to merge, when that merge happens, we can go ahead and create that point in time for backwards versions and move that code. These check-ins these yeah.

B

These commits that we created on to that branch as well. Maybe we have to do some additional cleanup there or some additions, but then we can merge it and create that new tag, and we don't have to keep this long brown or running branch around, but we still have that point in time. We have that new version and we can apply that to all the other branches to all the other versions that we support as well.

B

So the magic in here is- and this is a question if you like. What do you think is the magic word here? What's the magic command I heard it? It's cherry pick? Yes, yes, so you come see me later. I got something for you. So yes, it's cherry picking and the thing is you can automate that process if you automate that process, you might have heard of previous talk about Probot or with the web hooks and the github api.

B

So you could really automate that maybe your web hook is triggered when you create that merge onto master and then that web hook with the API with github or with git, creates these different branches and creates these different pull requests on these tags.

B

That are there or maybe it's you apply a label to that branch before you merge it so that you create everything in parallel and have it all tested automatically, because as soon as you create that branch, you trigger your continuous integration system, your testing and all that that is in play and is in play with your protection of your branches. So you can, with confidence clean up these things, merge them and have your new version awesome.

B

But what is if I, don't even what happens if I have to fix something say in version 2.8 or maybe I have to fix it in version two point: nine, so this example and is not its visualizing it in a different way, but maybe I found this buck in a version that is not the current version, so I would try and find out.

B

Is it also a bug in all my other versions, but first and foremost, I would fix it in this version, where I discovered it, when I did once we've done that and created our attack, we could then create a new branch merge. These changes on top of it because two-point-nine has 2.8 as a subset, so we can merge these things in maybe do a some additional cleanup and then do these things subsequently on to the other versions as well. Do it on top of master and then continue with our development.

B

So this is really just one of the examples that came out of work for consultations, or these are a few of the examples that came out of the work for consultations we've done in the past, with different customers and different industries, and this is one we're done with someone in the automotive industry, where it's more about embedded software, whereas the previous one with where you do this with cherry picking, might be rather something that you do on top of a web service or a micro service where you support multiple versions or maybe a dependency, you develop internally, that you use I, don't know when you get that you supply or npm or the dependency management of your choice, so yeah.

B

Really. These are some of these examples. And honestly, it's not that complicated and our goal really is to give you an idea. How you can apply something simple as these workflows and apply them to your software development lifecycle, with the platform that you're already already using and make your development a charm and so with.

B

If there's questions we can take them here. As gray said we're here today and all day tomorrow, if you'd like to get into a little bit more extended discussion about how could our workflow look like with some of these tools that we introduced? Please come and find us over at the ask github booth. Otherwise, thank you. I'll! Give you all ten minutes back. It's been a long day for everyone, I'll be here thanks! So much.

B