Okay, so that is it; you now have these automations running with every PR. Let's see what a PR looks like.
Step Two: Using GitHub Branch Protection
First, we have to get GitHub into a place that "forces" a PR flow. Honestly, a team should have "trust" enough maybe not to do this but two things here. One it prevents accidents. We have all been on the wrong branch before and pushed up without seeing. Second it can help with management to know there are guardrails.<img src="/images/branches.png" width="1200" class="center">
We set the rule to match our trunk branch
We make sure that all Pull Requests require someone to create a PR beforehand and have one approver. Finally, we add this one Status check to pass before we can merge this into trunk.
Below is an example.<img src="/images/pr_ui.png" width="1200" class="center">
What we get here is a Pull Request interface to see the critical aspects of this workflow.
The upper right corner will be a Green "Review Pr" button if another team member was looking at this PR.
The middle section shows the running state of the Actions we made above and if they pass or fail. If they fail, then no matter what, we can not merge this easily.
Lastly is the "break glass" button to merge the PR if you are an admin. This will be Green if your PR is approved and the Actions are all passing.
That is it really for the PR. Review, comment, or approve, and your team is ready to have a high-speed flow to ensure quality is in from the start.
Take time to automate and place tools from the start of the chain in place to make sure quality is baked in. As your deploy code to production multiple times a day (coming in part two of this), you will see how important this is to speed and stability. And Actions let you do this easily.
Developers should be empowered to do ops, and this is a great place to start.
I mention this above and just want to take a moment to say that even a solution this simple is better than nothing. Developers should be empowered to do ops, and this is a great place to start. Actions do not require different teams to approve or implement. It can streamline the work it takes to innovate, and innovation at this level will work its way up to the business as the data in Accelerate shows over and over again.
[^sod]: State of DevOps Report 2019
[^sem]: Semantic Verision
- I will work on using CodeClimate as a code check action since this works with so many languages and seems to plugin easily using docker