Extreme GitHub Flow

0:00 - intro

0:00:32 - What is Extreme Github Flow?

0:01:26 - "What Github Flow is NOT"

0:03:46 - Pull request in Extreme Github Flow is production ready.

0:04:44 - Is Extreme Github Flow Simpler than Gitflow?

0:06:30 - Overview of code review

0:07:18 - importance of code review to Extreme Github Flow

0:09:13 - How does one set up a code review process?

0:10:28 - Code review levels; L1: Static Code Analysis, L2: Code Reviewing, L3: Feedback

0:11:47 - Challenges of using Extreme Github Flow and code reviews

0:13:59 - The real challenge is CHANGE

0:16:09 - Best practices for using Github Flow and code reviews

Hi, welcome back to the Goodfrontend Show. And today we're gonna be talking about Extreme GitHub Flow and Code Reviews. Onto our first question, what is Extreme GitHub Flow?

Extreme GitHub Flow is something that we are trying to implement hard actually in our teams
here at GFED. It probably is helpful to understand the GitHub Flow first before we move to
Extreme GitHub Flow. GitHub Flow is a very straightforward branching model that is proposed by GitHub. It's rather straightforward. It is basically the pull request model. The idea is you have a main code base, you create a pull request, and once the pull request is approved, it gets merged into your main codebase, and then there you have it, your code is part of the main code base. So, GitHub Flow is very simple. What GitHub Flow is NOT... is GitFlow.

So in the enterprise world, a lot of organizations would be used to a model called GitFlow. And GitFlow is a more complex model built for enterprise. Well, usually for GitFlow, you have feature branches, you have a dev branch, you have a master branch, and then you have release branches. Okay. So just by virtue of mentioning those types of branches, you can see how complex the process is. GitHub Flow on the other hand, is there are, are simply just two
branches. Your pull request branch or your feature branch and your main branch. So that's why it's a lot simpler as a model. The advantage of GitHub Flow is simplicity. It's a simple model.

Extreme GitHub Flow is a lot like GitHub Flow with superpowers. Extreme GitHub Flow is doing everything that needs to be done on the pull request, and then it gets merged into the main branch. Mm-hmm. <affirmative>, and that's what we are referring to as Extreme GitHub Flow. So GitHub Flow, actually, they don't have any rules around. Okay. What gets merged into main? So for many organizations, what they tend to do is that they create a pull request. They might code review that, that pull request, and then it gets merged to the main branch. And then the testers will then deploy this main branch and then they will test it in an environment. Mm-hmm. <affirmative>.

Extreme GitHub Flow... the difference is that you do everything in the pull request. So you do your code reviews in the pull request, you do your quality assurance in the pull request, you run your end-to-end testing in the pull request. You do all the various different automation testing that needs to be done on the pull request. And when that pull request is merged into the main branch, it's deployable. So that's the key difference. The pull request readiness in Extreme GitHub Flow is production ready. It's only ready to be merged into the main branch when the pull request is production ready.

Mm-hmm. <affirmative>. Okay. So let me just try to understand it. So GitHub flow is different from the GitFlow?

Yes.

And GitHub Flow is designed by GitHub.

Yes.

And then we have Extreme GitHub Flow.

Yes.

Which is a much more robust way of making sure that that branch has been tested or all the
processes that you could add into a maybe like a GitFlow from an enterprise company that uses all the goodies like in the pipelines and stuff like that.

Yeah. Extreme GitHub Flow is making sure that the pull request branch is production ready
before it gets merged into the main branch.

And how is this simpler to set up compared to say, a GitFlow where you have all the different
checks in one branch? So let's say I have a test branch, a staging branch. So you first push to a test branch, and then if everything is okay in the test branch, it goes through all the different tests, then it gets sent to a staging branch. How is Extreme GitHub Flow easier to set up compared to that kind of setup?

Yeah, that's a great question. In the past, Extreme GitHub Flow would be impossible and it
would've been very expensive. And that's the reason why we would've created a test
environment, an SIT environment, QA environment because it's a lot easier to set up mm-hmm. <affirmative>. But today because technology has moved on and we use cloud native
technologies, deploying branches and creating environments is just like that. Okay. So when you deploy a branch, you can create the environment on the spot just like that because the creation of environments can be automated in a cloud environment and it can also be cheaper because once that branch is merged, you can kill off that environment. Right. And it's gone.

Okay. As opposed to like the old way of doing things where the environment is always up and
running, right?

Correct. Yes. In the cloud world, you only pay per request. Mm-hmm. <affirmative>, that's why you can spawn the environment if you need it and you can tear it down when you don't need it anymore.

Okay. What about code review, maybe for the benefits of the viewers, maybe just give us an
overview of what the code review is.

Yeah. Code review in simple terms is giving feedback. Code review is effectively giving another engineer feedback on the work that they have done. Code review is really an essential process, I would say as part of Extreme GitHub Flow. And the reason why we call this out is because I noticed that in some organizations they have the concepts of pull requests, but they don't have the concept of code reviews. Code review is not happening if there is no feedback. So code review is another person giving feedback to another person's work. And it's important in Extreme GitHub Flow because what you're trying to achieve when introducing code review is a culture of feedback. You want feedback to happen fast and specific, and at the time that feedback is given. Of course, there are also other forms of feedback like the automation tests and so on. But the one that often gets missed is the simple forms of feedback, which is the code review. Mm-hmm. <affirmative>. And usually if you get that level right, then automation testing is a lot easier.

And I guess if I'm the one, let's say doing the code review, it benefits me as well. It benefits the one who's doing the review, 'cause you get to see different types of techniques of solving a problem. Right.

Yes.

And talking about benefits, are there any other benefits in doing code review apart from what I mentioned there?

Yeah. Ultimately the ultimate benefit of code review is as I mentioned feedback. And when you have a culture of feedback, you reduce the number of bugs, you have a healthier code base, you have happier people. You know there is this view that developers are not social. That's absolutely not true. They're just not interested in the things that you're interested in <laugh>. But, if they, you are talking about code and technology, then their eyes light up, right? Mm-hmm. <affirmative>. So, creating conversations in the area of their interest such as code review is really good, for the health of the code base, which ultimately benefits the organization that uses that code. Mm-hmm. <affirmative>.

Okay. So how does one set up a code review process?

The code review process is really straightforward, right? So most people would be familiar already with creating pull requests, right? And actually with modern tooling such as GitHub, GitLab, and Bitbucket, you can introduce what we call code review templates. And code review templates, in there you can set out guidelines or you can create checklists to say that, okay, for those who are reviewing, these are the tasks that you need to do as part of your code review. So when you're setting up a code review process, the important thing is to set something that is simple and realistic. Once the team starts to achieve that, then you add more onto it. Once the team starts to achieve that, you add more onto it. Let's give a very, very rudimentary example. It could be that the code review process is the level one, let's say, which I call level one, which is static code analysis.

You know, you, you check the code, you look and feel it if it looks good to you, and then you
provide your feedback to the person who writes it. And then you might want to take it to a level two, level of code reviewing, which is you look at the code and you also look at the acceptance criteria or the specifications or the description of what this code is meant to achieve. And then you're having to look at the solution, and seeing if it actually meets the specification that is given. You know? And then of course there is level three feedback where people are now no longer just talking about, um, you know, a Q&A so to speak. But more, it's more, a culture of feedback as I call it. It's more collaborative where conversations are happening in the tickets themselves. And this really is something that you will notice more for those people who are involved in the open source communities. You know, we tend to have conversations in the pull requests themselves.

What about the challenges? What are some of the challenges of using Extreme GitHub Flow and code reviews?

I would say the key challenge that I notice when it comes to Extreme GitHub Flow when I
introduce this process to teams that I'm working on is people struggle with new processes. People want to stick to the things that they are used to. Mm-hmm. <affirmative> because it worked in the past, why should we change it? But often it's important for people to remember that things are a lot more dynamic. What I mean by that is, you know, development and technology is a lot like playing chess. When you play chess, when you move a piece, your opponent moves another piece. When you move your knight, your opponent will move something else. It's a dynamic game. But what people often mistakenly do is that they think that they can stay static even though technology is changing. So when technology changes, for example, in the world of composable where we are now looking more at cloud native technologies, where we're looking more for, at micro architectures, the process cannot be static.

It has to go hand in hand with the the technology that came along with it. So for example, with cloud native technologies, why would you use rigid environments when you have cloud native technologies, you can just spin one up and tear things down. It would be cheaper. Why would you still continue to use GitFlow, which is such a rigid process when you no longer have monolithic architectures when you can do a continuous delivery program whereby you just merge things into the main branch providing that it's production ready and then it goes straight to production and its live. So the real challenge really that I find when introducing such processes is not so much that the people don't understand the benefits. Maybe that's part of it, but the real challenge is that people don't really want to change what they are used to.

And I think that stems to that very nature that we have, this false belief that things can remain
static, but it can't, you know, when the technology changes, the process also has to adjust. The people also has to adjust. It cannot remain static because it's a lot like playing chess. As you move a piece, as technology moves a piece, the process also has to move a piece. The people also has to move a piece. Mm-hmm. <affirmative>. So it's a dynamic environment, which requires that when these technological changes come, then the process and the people also has to adjust to the changes.

How do you overcome this?

Yeah, good question. The simplest way is patience and education. Not all of our projects that we work on actually is using Extreme GitHub Flow practices, but almost all of them are moving towards that goal. We educate the people in the team on the benefits of using Extreme GitHub Flow on the things that they can do now that they could not do before.

And then we implement things little by little. Some projects are able to implement it very quickly because the people are a lot more humble and open to change and things like this. But some projects are a lot harder to embrace new processes and new techniques because they are used to certain process or they have grown complacent and so on. So yeah, it just requires a lot more patience and a lot more ability to teach and educate. Um, but um, yeah, there, there is no simple way to overcome it unless of course that you do it top down, which in newer projects it's a lot easier to do. But in existing projects, in mixed teams and so on, it's a lot harder to introduce.

What about the best practices? What are some of the best practices for using GitHub Flow?
Extreme GitHub Flow and code reviews.

For best practices, what I would say is all the tools that are necessary for you to implement an Extreme GitHub Flow process is available. And all of them are free actually, unless of course you decide to, let's say sign up to a security pentesting tool, you know. So the number one best practice that I would suggest to people is that, automate as much as you can. If you're using GitHub, for example, it's so simple now, just to add GitHub actions, and you can add in there lighthouse reporting so easily. If you are using end-to-end test tooling, you can easily integrate that, performance testing automation you can easily integrate that, visual regression with Percy, for example. You can easily integrate that. So automation is so simple now. So as a best practice, I would say is just automate as as much as you can, right?

That would be the key thing I would say. Otherwise, you know, then you're not really gaining the benefits of a moving forward technology. The more you automate, then the more confident you are that when this pull request is merged, that it is production ready. Another best practice I would say is, which I mentioned earlier, is using code review templates so that you have a standard guideline and a standard way of doing code reviews where everyone abides to, and you just keep it simple, keep it simple and achievable. And the reason why templates are helpful is because you can upgrade the template. You can add more and more and more as people get used to the process and get better at it. Another best practice that's, I would say when it comes to Extreme GitHub Flow, again, is to keep it simple. We might be tempted to make it more complex than how it is, but keeping it simple really is when you have a pull request and you have a main branch, you know, there is only two things that you're having to think about. You have to stick to that. You have to stick to only those two types of branches. A pull request branch and a main branch, nothing else. So yeah, best practice, just keep it simple.

So just to sum up, first one is to automate as much as you can. Second one, code review
template. Yep. And the third one, keep it simple. That's it. KISS.

Yeah. Keep it Simple. Yeah, keep it simple. Keep a pull request branch and a main branch.