Prerequisites
To begin down the continuous path, aside from a willingness to adapt and try new practices, you need a version control system (VCS) for any other system to access your codebase, and you need solid test coverage. We won’t cover these in detail in this post, but you can find many tutorials online for getting them both set up with your team.
Continuous Integration
Most teams doing “continuous anything” are using some form of Continuous Integration (CI). Exact implementation details vary from team to team but typically involve building a version of your codebase and deploying it to a testing environment and running specific tests against it. You may decide to run specific tests on all code pushes, across all branches, or only specific tests on specific branches. What constitutes a “test,” and a pass or fail depends on your application and strategy. In short, instead of relying on team members to run them manually, a CI tool runs them automatically.
After a reasonable amount of initial setup, what are the benefits to your team of CI? Primarily, it encourages your team to test their code extensively and solidly. They should be already, but introducing CI forces them to. More tests should equal more stable code and fewer bugs. Automated testing also reduces the amount of context switching developers make between tasks and the amount of time they spend waiting for code to build. Your testing and QA teams can spend less time running repetitive tests, and instead focus on more significant improvements to code and applications.
Technical teams are not renowned for their skills at communication, and automated processes mean they can reduce those pain points through a streamlined process flow instead of waiting for responses to internal tickets, or missing requests for review.
CI Implementation Steps
The first steps to getting CI running with your application is automating your build steps, and writing tests. While tests are something that every development team knows they should have, not all do, and maybe not to the extent that makes a CI process useful and reliable. The tests need to check every new feature, improvement or bug fix you add, and the effect they have on the application as a whole.
Your development team should push and merge changes as regularly as possible, and in as many small discrete chunks as possible. This is one of the harder steps to get right, as you can’t split everything up this way, but over time teams start to think and plan in more appropriate ways.
You need a CI service or server to monitor for changes to the branches you specify and to build and run tests. There are many options, but below are some of the most popular. Deciding which suits you best is a difficult decision, as most platforms share similar features and the decision is more of a pricing and approach question:
Continuous Delivery
Continuous delivery (CD) extends CI. If your tests pass in CI, then during the CD step, you take the built artifacts from the CI step and deploy them automatically to other development environments (staging, for example), and manually to production when you’re ready. Depending on your application and the programming language(s) it uses, delivery might be a short and straightforward process or a long and complex one. A popular concept in CD is “reproducible builds,” which are builds that result in identical output artifacts. Identical builds give increased confidence that code that works on a developer machine, also works on production. However, we all know that developers rarely all use the same setup as each other or as machines that run production code. This is where containerization comes into play. Using containers such as Docker or Rkt, you can replicate the production environment on any machine and reduce the chances of differences in environments that used to be common sources of problems.
As with other continuous practices, the main advantages for automating delivery is speed, and saving your team time wasted on repetitive tasks by passing them off to an automated system, that happily repeats itself consistently as much as you ask it.
CD Implementation Steps
Before you start down the CD path, you should already have a solid setup and experience with CI. The difference between continuous delivery and deployment (covered next) is a little confusing. With CD (continuous delivery), you should automate the delivery of your deployments to production, and require no manual interaction, but triggering the deployment is still manual when you adopt just CI and CD (continuous delivery).
You need a service that can handle CD and CI. There are many options, and specifically, what you use can depend on the programming language(s) you use. Still, the most popular can support a wide variety of build systems.
Many teams that use CD find themselves adding “feature flags” to enable and disable features for particular user segments. This does introduce added complexity (and tests) into your code but also gives you the potential to toggle features without rebuilding and delivering code.
Continuous Deployment
Continuous deployment (CD, yes, this gets confusing) is an extension of delivery. In this step, you take the artifacts automatically deployed from CI and continuous delivery, and now also automatically deploy them to production. This could be anything from deploying to a website to releasing a multitude of binaries to different package managers and build systems. If you use CI + CD + CD, then this means that one commit that passes tests is deployed to production automatically, potentially within seconds.
This step is the hardest to implement as it requires a large amount of trust in your processes up until this point, and that you can roll back deployments if problems arise. To put you at ease, out of all three of the practices mentioned in this article, it’s the one that least people adopt, at least until they are very sure about their processes.
The most significant benefit for CD is encouraging constant smaller, simpler releases. While it may sound counter-intuitive that releasing more often is more reliable, it also means you reduce the risk of large problematic releases that are hard to roll back. It also makes it easier to A/B test smaller features with particular users and get feedback on individual discrete features.
CD Implementation Steps
CD systems again overlap with CI and CD (continuous delivery) systems, or possibly your deployment process is custom, or the default tools for your programming language make more sense. Deployment tools are also not new, and in many cases, you can use those pre-existing tools in a continuous way instead.
You also need to factor in what else production deployments affect that need updating. For example, documentation, marketing copy, or support resources. You could factor some of these into your continuous processes, depending on how you create the resources.
Continually Improve
There are a lot of decisions and preparations to make before becoming a fully continuous delivery team. Still, thankfully it’s a process you can iteratively add to as you gain time and experience. Our advice is to start with ensuring you have a comprehensive test suite, add that to a CI system, and add steps from there.
Humanitec helps you on your continuous development path. All you need is the first stage, an existing CI pipeline. We take that pipeline and deploy your build artifacts to any of the development environments you spin up on demand. You can host these environments with us, with AWS, or GCP. With a few clicks, your code is live and running on your Kubernetes cluster. Our DevOps experts are happy to support you during a free webinar.
