Using GitHub Actions for CI (and building Penny U with the help of Penny U!)
JnBrymn
The Penny University community is growing, and as it does several of us are in the background building out a new software platform to support it. We are now at the point where we need automatic processes to deploy our application rather than the cumbersome manual processes we currently employ.
Fortunately, we are a community of experts! So we can reach back into Penny University for the advice we need to get to the next level faster.
Today that advice came from Scott Burns as he walked us through Stratasan's approach to continuous integration and deployment. Here's what I learned:
I told Scott that we were thinking about having a staging environment and a production environment. Scott said that a single staging environment often becomes a bottleneck and a frustration as developers inadvertently deploy over others' work. Instead, he recommended that we consider having "N+1" environments. The "1" is production, and the "N" is an independent environment for each developer. Since we are just running a Django app, this is actually an easy thing to do - everyone gets their own free Heroku instance.
Next, Scott showed me this gem. It's a cookie cutter implementing the Github Action workflow file used at Stratasan for their CI/CD. Some interesting things stand out:
- The action fires upon two different situations 1) A change in any pull request, 2) A push into the master branch.
- You can use the paths directive to only trigger an action if certain paths are updated. This will be particularly useful for us as our backend and frontend app are currently housed in the same repo, but are developed independently.
- The basic flow is to test the code, run linting, build the code, and ONLY if all that works, does the deployment run. Additionally, extra steps are run for production only.
- Within each one of the jobs you can use the needs directive to identify which jobs require which other jobs to be completed first. This makes it possible to run things in parallel if they don't affect one another, and it makes it possible to NOT run deployment if tests fail upstream!
- You can distinguish between master pushes or PR updates with lines like this if: github.event_name == 'push'. For Scott's flow that means that the PRs get the tests run, but only the master branch pushes get an actual deployment.
I could have read all the documents and learned this on my own. But it's a huge time saver to just see what others are doing and be able to ask them the important questions. Now, when I do go back to read the documentation I know where to start reading. This has saved me a ton of time.
Thanks for your time Scott!
(Also, nice to meet Ary Sharifian, a cloud engineer at Oracle. You have good taste in music. 😆)
JnBrymn
