The 5W's of Implementing CI/CD Pipelines

Why should CI/CD be used?

Continuous Integration / Continuous Delivery (CI/CD) has been widely accepted as an integral part of software development for some time now. It can greatly increase the velocity, quality, and consistency of software development within and across teams. CI/CD is, at a high level, automating the process of building, testing and deploying software. The “continuous” part of CI/CD is integrating Git or another version control system so that changes are tested and integrated early and often. It is available for free in many cases and is inexpensive to operate for the benefits that it provides.

When should I setup CI/CD?

Spending time early in a project’s life to get a deployment strategy and pipeline in place can easily be overlooked or put aside in favor of shiny new features or something higher profile, but it shouldn't be. The return on investment of time spent getting a CI/CD pipeline setup is one that will continue to pay off for the life of a project. Having an automated verification and deployment pipeline enables you to focus on software development and reduces the overhead of manually managing and auditing coding standards, test coverage, and deployments.

​Where can I setup CI/CD?

There are a tons of hosted CI/CD services available that make getting started easy. Each of the leading Git hosting providers (GitHub Actions, Bitbucket Pipelines, GitLab CI), top cloud providers (AWS CodePipeline, Azure Pipelines, Google Cloud CI/CD), and even the popular provider agnostic serverless.com framework have hosted CI/CD services. With an abundance of services available, there is no longer a need to manually setup and maintain build servers. If you’re already using AWS for infrastructure, AWS CodePipeline is an obvious choice and it also works well if you have a GitHub or Bitbucket repository. When you combine the convenience and consistency of a CI/CD pipeline with CodePipeline and use CloudFormation templates to define your resources and manage changes, it’s hard to not get spoiled by the ease and efficiency of it all.

What are the benefits of CI/CD?

One benefit to automating deployments is having multiple environments for testing new features and changes before releasing code to production. It’s pretty common nowadays for projects to involve multiple teams and for codebases to have multiple integrations and testing environments, through which code progresses to production. Things can get complicated when multiple teams and projects share these environments and resources. Having a dependable, automated deployment for each environment allows you to trigger testing and deployments by committing or merging code. Your pipeline handles the rest, helping to ensure the quality and stability of your environments.

​Who should use CI/CD?

You don’t have to have an enterprise-sized microservice architecture to see the immediate benefits of automated deployments and pre-production environments to test your applications. These same benefits are quickly realized on smaller projects as well. Depending on your development workflow you likely have a Git branching and merging process or some variation of the common Git Flow or simpler GitHub Workflow. Having your CI/CD pipeline closely follow your branching and testing process makes testing and moving code through environments a breeze. When creating a feature branch for dev work, a pipeline for testing and deployment can automatically be created in the background. Every time you commit code, your CI/CD will automatically verify unit and integration tests pass and deploy or activate your code in a particular environment. Pipeline triggers are customizable, allowing you to create rules to match your desired workflow and environments.

​Conclusion

Without a CI/CD pipeline on a project, a lot of time and effort can get lost in managing deployments and fixing one-off issues that could have been easily avoided by automating the process. These issues can add up to death by a thousand paper cuts quickly and a lot of times end up being caused by something small like an outdated config file value or maybe a forgotten deploy step. These issues can mostly be automated away and make life a lot easier. Or it might be spending time on a one-off request to deploy a feature branch for an early demo or testing before it’s ready to pull into a more stable branch, and depending on how you go about setting up your workflow and pipeline, that feature branch could already be deployed accessible for testing with your last push of changes. With the ease of setup and variety of hosted services making it simple to get up and running, there is little reason any project big or small should not have CI/CD setup from the beginning.