Making the case for CI/CD

If you browse developer forums, continuous integration and continuous delivery will not be new concepts to you. We all love the utopian ideas of being able to open a pull request and commanding an army of robots to do your bidding and get the application tested and shipped.

Unfortunately, the reality of many businesses is different. Developer experience is an area seldom invested in; despite being such a huge opportunity for large productivity gains.

Perhaps already you have been pleading to tinker with github actions, switch to a PaaS or use a IaaC but to no avail.

So, how can you champion the move to a continuous integration and delivery?

First let's look at the reasons people may object.

Start with approval

It's utterly pointless starting any of this without some kind of green light. Although we love stories of people doing things under ground and against the odds, the fact is that you're not creating a cure for cancer. You should speak to your immediate team and get their feedback. Then create a formal proposal and, again, get more feedback. Then get the green light from the relevant stakeholder.

The proposal should outline the overall vision for the system, the advantages, the risks and the downsides. If you can't think of risks and disadvantages, then you haven't thought about this problem enough.

Throughout all this, make sure to not just push your vision on the team. Be collaborative. Keep an open mind. And don't pretend that it will be a breeze and nothing will go wrong (hint - it will!). The worst thing to do is to try and do it all yourself or with only a couple true believers. This is a sure fire way to make sure the initiative is abandoned.

Start with the data

Often times, stakeholders say they want a fancy dashboard with burndown rates, bug reports and the position of Saturn. In reality, an excel spreadsheet will work.

Create a spreadsheet with the following attributes:

Start measuring these metrics for at least 4 weeks before making any changes. And make sure the spreadsheet is shared, collaborative and documented well - both inside the team and to any stakeholders.

Start small

Now you have your numbers, you can start to look at improving them!

Using your original proposal as a guide, build up a step by step plan that can be implemented in a sprint (a 2 week period) or less. Be mindful of any steps that will create blockers for others and plan around this accordingly to mitigate their impact.

Unlike with code, we often can't rollback changes made to deployment and testing systems. So, think carefully about how those changes can be reversed if needs be. I've been burnt many times by not considering this carefully enough.

After each step, take a 1-2 week break before making other changes, continuing to record your data points. Verify that the numbers are heading in the right direction. And if they aren't, you can address this in a retrospective meeting.

A sample plan may look like this.

Goal: Be able to merge into the `staging` branch from a feature branch and have the code automatically tested and deployed to our staging environment.
Currently: FTP files onto a server manually once a week on Tuesday. No test suite.

Step 1: Create a testing suite for critical components of the application
Step 2: Create a github action (or other CI service) to run the test suite for all new pull requests
Step 3: Add a github action that FTP's files from the `staging` branch to the staging server

Obviously I have glossed over a number of details, but hopefully you get the idea. It's about making small changes and not just going for a "big bang" type change (which are always doomed to fail).

It can be tempting to prioritize big change first, but as a word of caution, try to focus on being iterative rather than catching the big fish.

As you go forward, and the metrics improve, the buy in from stakeholders and others will improve. Nothing makes a stakeholder happier than knowing that it's cheaper to do some work!

This can drive further change which follows a similar process as outlined above.

By the end of it, you may not be deploying to production 50 times a day, but doing something much more humble. Saving you and your colleagues, hours of mundane, repetitive and error prone work. And isn't that just as valuable?