It’s widely accepted that the CI/CD pipeline is the way to go for businesses looking to increase productivity, user, and employee satisfaction. Around 87 percent of respondents to the recent iOS Developer Community Survey said that they were either already practicing continuous delivery, or hoped to adopt it soon.
The promise of a stress-free release process is enough to get any developer excited, but jump in without preparation and you’ll risk sending bugs straight through to production.
Lay the following foundations when setting up your CI/CD process:
In a world of uncertainty and instability, precious few things remain consistent. The fact that developers don’t like testing is one of them. If you’re planning to adopt continuous delivery practices, though, you’ll need to build testing into your development culture.
They’ll have the help of a CI tool (more on that later), but developers will first need to create unit tests for the features they’re working on. Everything gets automated once that’s done, but it has to be done at the outset, or bugs will likely find their way into the finished build.
In order to combat this, you’ll want to encourage the use of version control branches (using a tool like GitFlow) and feature flags – that way, any changes will be isolated before finding their way into the main branch. Don’t forget to drill that final step into your team, though – as the team at Stackify put it:
‘Of all the…stages of CI, committing to master is the easiest technically, but hardest culturally.’
Make sure your team know where their code is supposed to end up before you kick off your delivery pipeline. For more on version control branching and feature flags, check out this helpful guide from InfoWorld.
You won’t get far on your CI/CD journey without a specialized continuous delivery tool. A good one will monitor your code repository for any changes, then automatically build those changes and put them through the unit tests created by your team.
If the change doesn’t break the feature or application, it’s automatically sent on to pre-production. If there’s an issue, it’s instantly relayed to the developer responsible.
Jenkins is the most popular choice, thanks in no small part to the fact that it’s open-source, it’s free, and it boasts around 1,600 plug-ins. The chances are pretty slim that there’s a combination of coding repositories, languages or cloud providers that it can’t integrate with and link together. It’s not the only option, though. Atlassian has their own CI/CD tool called Bamboo, and CircleCI is another popular choice.
Whether you do it in-house or go with an external QA team, you’ll need functional automated testing beyond the initial, code-specific unit tests. Full regression tests and performance testing will ideally take place in a dedicated QA stage that comes before production or beta distribution.
Any bugs that arise in the main code branch can be relayed back to development, kickstarting the CI process from the beginning to create a continuous feedback loop.
Continually pushing bug-free feature updates to production is the holy grail of DevOps, but it’s not much use if you don’t have a production environment that can support it. Make sure you're performing stress and performance tests before you release to production, and have a robust architecture in place with the right servers, load balancers, and databases to support both your features and your user base within a nicely polished application.
Forgetting to take these steps before kicking off a CI/CD pipeline is the testing equivalent of waiting until after you’ve cooked and eaten your (questionable) dinner to read the recipe. Build a culture of testing, adopt the right tools and ensure your resources are up to the task, and you’ll be cooking like an expert.