CI - GitHub Actions and Laravel (Part 1 of 3)

laravel 🚀

ci 🚀

cd 🚀

accelerate 🚀

devops 🚀

CI - GitHub Actions and Laravel (Part 1 of 3)

No Dusk tests? Right, so I might add Dusk for some End2End. The work I do day to day depends on Python Pytest for End2End testing. Since those projects have an embedded QA person, they tend to know Python. Dusk is fantastic and there are actions running selenium and what not, so it should plug in fine. Maybe I will come back later to this. If this app had a JavaScript framework like VueJS I would not use Dusk I would use Jest or some other well-known testing framework for JavaScript. Since this app is Livewire, I depend on its testing at the PHPUnit level, but I do see the value here of some e2e testing in Dusk.

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.

We set the rule to match our trunk branch main
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.

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.

Final Thoughts

tl;dr

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.

Enterprise

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.

References

[^sod]: State of DevOps Report 2019
[^cont]: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
[^accelerate]: Accelerate
[^sem]: Semantic Verision
[^bml]: https://www.mindtools.com/pages/article/build-measure-learn.htm
[^scheduling]: (https://www.linkedin.com/pulse/being-offense-when-comes-day-scheduling-alfred-nutile/?trackingId=o9EJPZ73zVJOR6MeQ1HN3w%3D%3D)

Follow Up