Start with hello world and CI/CD

May 1st, 2019

When I decide to make a web app I start with the skeleton the framework generates and get it running through a CI/CD pipeline so it’s deployed and running in production straight from day one.

Why

This stops me from diving into writing application code straight away and provides a good point to pause and reflect if I think this app is worthwhile enough for the effort.

Once CI/CD has been setup it usually just works and means frequent releases happen without too much thought or ceremony required. As the app progresses it usually becomes more complicated and requires more setup. Having already got tests running remotely and automatic deployment happening each of these setup changes happens naturally in the flow of development. This means the first official release is just a point in time. Without this it’s usually a mini project to remember all the configuration needed and get it up and working.

Pre alpha workflow

If I’ve done a spike app as part of a learning project I will start with a fresh new repo rather than try and retrofit the spike code as I’ve never seen that work well. Once CI/CD is setup I’ll evaluate the code in the spike app and bring over any parts that are good enough quality in coherent commits with tests and documentation.

To start with I’ll work on the master branch and so deploy all the time. After some kind of first “official” release e.g. an alpha version I’ll setup a staging environment and a develop branch and make that the default branch on Github.

Post alpha workflow

Every commit to the develop branch gets continually released to staging as before. If it’s possible I’ll setup the staging environment to have a recent restore of the production DB. This depends on the size of the data and also PII/GDRP concerns. The big advantages here are that I know backups and restores are working, and I can sanity check code or UX with recent data before going to production.

When I want to do a release to production that’s just a PR so it’s easy to do and also easy to review what’s going to be going out. I’ll do that often so un-deployed code doesn’t build up on the staging branch.

Even if I’m working in my own I’ll use PRs and branches for development so I can self review the code and also be able to look back at the chunks of work at a later date rather than having to do code archeology on a single branch. I still prefer

Alternatives

Another choice I haven’t tried yet is starting with feature flags on master and not having staging / develop. I haven’t done this because it feels a bit riskier to me in the early days. Once there are more team members and bigger features it’s a great way to keep commits small and incremental and still be able to deploy them. It also helps build discipline around forward and backward compatibility and database migrations.

Tools

My default initial infrastructure is CircleCI for the CI part and Heroku hooked up to GitHub for CD. I setup Heroku’s GitHub integration so it doesn’t deploy until the tests have passed on CircleCI so no code goes out until tests are green.

Conclusion

I can’t imagine not having a CI/CD pipeline that’s able to deliver code to production almost as it’s written on any project I work on now. I’ve done it for so long I sometime forget that not everyone works this way. I know there are circumstances where this style of releasing is not appropriate, for example if the software needs to go through some kind of approval process. In my opinion every project that can use this style of deployment should.