GitLab defines Continuous Integration (CI)/Continuous Deployment (CD) as “an essential part of DevOps and any modern software development practice.” I prefer to describe it as one of the coolest and niftiest parts of application development. CI/CD pipelines allow you to automate processes that ensure the quality of your code and deployments.
You can perform static code analysis to verify your code doesn’t include major vulnerabilities. You can run a linter if you’re nitpicky like I am and want to ensure new changes are formatted correctly. You can run unit tests to be sure the new code you wrote did not introduce regressions. You can deploy your web app to the cloud. You can create an installer for your desktop app. I could go on but will instead just repeat: the coolest and niftiest parts of app dev.
I should briefly note that the full definition of CI/CD (like Wikipedia notes here) defines that it can be considered more of an execution style: where CI is the frequent merging of several small changes into a main branch, and CD is the production of software in short, efficient cycles so that it can be continuously delivered.
While frequent integration of code into the main branch and the delivery of new features are very important, any references to CI/CD in the remainder of this blog will refer to the concepts of automated code validation and automated code deployment (via CI/CD pipelines).
Into the Nitty Gritty
Here’s some clarifying information before I rave further about CI/CD pipelines:
Continuous Integration (CI) — focused on building and testing code as it is committed to the remote repository.
Continuous Deployment (CD) — focused on deploying and releasing software.
Why Should You Care?
CI/CD pipelines are super nifty but do require time to set up. Someone needs to write the code that can run automatically, right? If you’re on a project with a tight timeline, it can be tough to justify devoting extra time to configuring your web app so it can deploy automatically (especially when you could just deploy it using the Azure CLI yourself).
But what happens when you have multiple developers working on the project who also need to deploy their changes to the web app? What if you get pulled to another project and can’t manually deploy? What if you forget to run the unit tests before deploying and you deploy broken code to your site?
Writing a CI/CD pipeline is an investment into the long-term health and maintainability of your code base. Continuous integration can verify that new code is up to par (via static analysis, automated unit test execution, code coverage, and linting). If a developer commits code that can’t build or doesn’t pass unit tests, your pipeline will flag that there’s an issue.
Continuous deployment reduces the overhead of deploying your code base. It ensures that each deployment step is executed when new code is deployed (none are forgotten through human error) and that a single person doesn’t have the overhead of manually deploying the app each time code needs to be pushed.
Environments
Setting up a CI/CD pipeline can also make it much easier to support multiple environments for your application. In the past, I’ve set up ‘development’, ‘staging’, and ‘production’ branches in addition to ‘main’. I’ve then configured my pipeline to deploy to the appropriate environment when code is merged into its matching branch.
This makes it easy to determine which code is live for each branch or to generate diffs between environments. It also means that you can push code after performing a pull request to the appropriate environment: giving you the opportunity to review the code before it goes live.
An important note regarding production: be sure to configure appropriate permissions or gates for triggering your pipeline to production. Those gates could be rules on the pull requests that merge to a production branch or restricting permissions of the users who can trigger a branch that deploys to production.
A fun note: you can also use IaC to deploy the resources that host your application based on each environment, but that’s a topic for another time.
How to Configure CI/CD
Most source code repositories (i.e. GitLab, Azure DevOps, GitHub, Bitbucket) offer their own flavor of the yaml file required to configure a CI/CD pipeline. Their documentation will be the most helpful resource on the specific syntax required to make their yaml files run.
Overview
Writing a CI/CD pipeline is most likely worth your time if:
- You have multiple developers working on your code base.
- You want to automatically test code quality whenever a developer pushes to the remote.
- You want increased repeatability and reliability of your deployment processes.
- You want to reduce developer overhead when new code needs to be deployed.
- You want to support multiple environments.
(It’s also just super cool and nifty).
Learn more about DMC's Application Development services and contact us for your next project.