Say you have a new feature you want to put in front of your users. Maybe you've created it to respond to their feedback or a new opportunity in the market, and you want to deploy it as quickly as possible. Do you know what needs to be checked before you take your change to production? How do you know the change you've made isn’t going to break existing functionality?
To answer these questions, you need a deployment pipeline. Before an aircraft is allowed to take off, the captain and crew need to perform a series of checks on their preflight checklist. Does the plane have enough fuel? Is the right wing flap free and secure?
Think of every change to your code base as an aircraft ready to take off at an airport. Everything you need to verify before your change can go live makes up your very own preflight checklist.
It’s your deployment pipeline’s job to make sure only changes ready for production are allowed to take to the skies. Here are three key steps you should follow.
1. Set up a build server
Build servers are also called continuous integration (CI) servers. Ten years ago, you would likely have needed to install and host your own server, but nowadays there are lots of cloud-based SaaS CI options available to get you up and running fast. Each comes with advantages and disadvantages, but it doesn't matter where you start. They all share the same basic functionality, and it's usually not too difficult to migrate from one to another later.
If you’re using a hosted version control service such as GitHub or GitLab, you might already have their CI offering included in your package. If using a cloud-based CI server isn’t an option, install Jenkins—it’s free and open source.
Once you've got a build server set up (and they all have guides to help you do that) you can set up your first build. Most CI servers these days support describing your build with code. You check a file into the root of your project with a description of the build steps you want to run. The configuration required should be minimal—they should have sensible defaults.
Start simply—just compile or package your application. Think about what needs to happen to your code for it to run in production and work backwards from there. Maybe you need to build a Docker image; maybe you need to bundle some JavaScript with wepback. The goal is to have a build process that consistently creates the artifacts you need to deploy to production.
Make sure it’s set up to run every time a change is checked into source control. This way, every change to your code base will go through your preflight checks.
2. Set up your checks
Automated checking gives a deployment pipeline its value. Your checks will likely include some tests and some static analysis. Set up a separate build step for each of your preflight checks. Separating them allows you to put faster steps first so you don’t have to wait long for feedback on failures.
A great first build step is to run a linter such as eslint to ensure the code complies with your team’s coding standards.
Next are your automated tests. You might have one build step for your unit or acceptance tests, another for your end-to-end test suite, and another for contract tests that check how third-party services behave.
This approach works best when you have good test coverage, but you can start even when you don't. Even if there's still manual testing to do once all the automated tests pass, you've managed to set up an early-detection mechanism that will help you catch some bad changes before you bother with manual testing.
Set up those test builds, even if you only have a couple of unit tests. You'll be surprised at how motivating it can be to write more tests once you can see the existing tests running and proving their worth.
Automated tests are designed to catch known bugs. They cover scenarios that you already know will need to be tested. The job of these tests is to prove that a change isn't ready for production, and passing still doesn't mean that the app is ready for production. It's up to your team to figure out what else goes into the decision about whether a change is ready to go live. That said, the better your test suite, the more automated this decision-making process becomes.
It’s also a good idea to include some security checks in your pipeline. You could check your list of dependencies with an external service to ensure there are no known security vulnerabilities. You could run some static analysis to check for any common coding mistakes that lead to security issues, such as checking in passwords. Dynamic analysis tools can be included to check that your application can’t be hacked with certain kinds of inputs.
If new code causes any of your checks to fail, the change doesn't go any further. When your change passes one set of checks, it moves on to the next. If it gets past all your checks, you know you’re ready to fly.
3. Add a deployment step
The real power of a deployment pipeline lies in its ability to link your automated checks to your deployment. Imagine a button at the end of your deployment pipeline. When the app has passed all the tests, the button is enabled. At that point all you need to do is push the button to deploy your changes to production.
For some teams, automating production deployment is complicated. In such situations, it's useful to start with deployment to a test environment. On your CI server, add a build that will run a script to deploy your application to a test environment. Link it to your test builds so that it only runs if all the tests pass.
If your deployment process doesn't cause too much downtime, you can make this step run automatically so your test environment is always up to date. Once you've gone through this process, you'll have a better idea of what's required to automate the path all the way to production.
Don't worry if your whole deployment process isn't automated yet. The first step in automating anything is understanding what all the current manual steps are, so that you can automate them one at a time. Start simple: At first your deployment build might only email someone who does your deployments manually. That's okay for a start.
Ready for takeoff
Follow these three steps, and you'll have the makings of a deployment pipeline that will serve you well. You'll have all the steps to production clearly laid out, and the visibility the pipeline creates will enable your whole team to see the path to production and identify and discuss potential improvements.
Having a series of checks that show the health of your application is invaluable. Anyone in the team can look at the CI server and see whether the build is red, green, or running. And when something goes wrong, your team will know about it faster and will work together to clear the road to production. The fuel pump is off, the doors are locked—time to take to the skies.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
