Good DevOps, Part 2: Continuous Integration
So you’ve got all of your code stored in GitHub or some other source control system. That’s a great first step! But now you have another problem: you and your team have to remember to kick off some other routines once new code is checked in. You may have to run tests on that code and launch a build process that compiles the code, creates an artifact, and performs other mandatory tasks to get the code to a deployable state.
That’s not an efficient way to do things, especially in this age of quick development. What you need is to automate the next phase of the software development lifecycle (SDLC). In other words, you need continuous integration (CI).
What is Continuous Integration?
CI is an automated workflow that’s automatically triggered by a source control code commit. That build process could be anything necessary to get the code into a deployable state, like compiling it, moving it to a specified location, and, typically, packaging it up.
The build process either creates some sort of artifact to be used later, or simply stores the code to be used later by the Continuous Deployment (CD) process.
CI is just the first step in the automation process of “continuous everything,” but some would argue it is the most important. Why? Without CI, you have no code to deploy in the first place! The CI process grabs the code from source control and packages it up so the deployment process knows what to deliver.
For example, let’s say you have a C# web application you want to deploy to an Azure App Service for a frontend serverless application. The C# web application needs to get to the Azure App Service somehow. It needs to be deployed. But the deployment can’t happen unless the C# web application runs through a build process to get it into a deployable state.
Testing with Continuous Integration
No one likes testing code manually, and forgetting to test or just being lazy can introduce bugs, security vulnerabilities, and more into your application.
Perhaps you’re working on a web application that your team is continually updating. You should ensure all changes to the code have been tested. That’s going to get old real quick if you must perform a set of tests for every code commit. Testing manually is not only cumbersome, but also prone to fail. We’re humans and we make mistakes. That’s where testing with CI comes into play.
Unit tests, which is a testing methodology that ensures code runs how you’d expect, is a common type of test suite to run. Unit tests are great to include in a CI process. Once a CI process is set up, unit tests will run automatically, alleviating the task of manually running them.
Testing in CI is called Continuous Testing (CT). CT is the key to building an overall, automated testing solution. CT eliminates several manual steps, including:
- Manual regression testing
- Manually building code to verify behavior
- Manual code inspections
Take a look at Figure 1, which shows a popular Microsoft CI tool called Azure DevOps. Perhaps you’re working on a project written in PowerShell. Pester is a great testing tool for PowerShell. Pester allows you to write many types of unit tests for the PowerShell language.
Figure 1 shows a task in Azure DevOps called Pester powershell unittests, which could be configured to run Pester tests automatically as part of the CI pipeline. You can specify the test file pattern, any testing parameters, and tags.
Figure 1. An Azure DevOps continuous integration tool, known as Pester Powershell unittests
This task in Azure DevOps is similar in concept to many other CI tools. It allows you to inject different tasks in an overall pipeline to run automatically.
A CI pipeline is important for automated builds and software testing, and there are quite a few options; here are three of the most popular.
Jenkins is the first tool on our list. Jenkins is an open-source CI/CD tool. Jenkins has been available for many years, and is one of the oldest CI tools out there. Jenkins is a plugin-based tool, which means a user can customize nearly every aspect of their platform using publicly-available plugins. The customization ability of Jenkins is one of its key advantages.
The second tool on the list, taking the world by storm, is GitHub Actions. GitHub Actions is popular because it’s free to use and embedded right into GitHub. GitHub is a hugely popular source control product—due to its popularity, it makes any CI product built directly on it a good CI option. GitHub Actions can build code, run tests, and deploy build artifacts if needed. It can do this on any platform right from GitHub. You might be at a disadvantage, though, if your and your team are using a competing source control product.
Azure DevOps is another great CI tool. Azure DevOps provides a complete CI solution. Azure DevOps, unlike GitHub Actions, can trigger a CI process from not only GitHub but also Azure’s own source control product, Azure Repos, and many other source control products. Azure DevOps has plenty of other tools built-in as well, including a Wiki, ticketing system, and testing mechanisms. Azure DevOps is free for up to five projects, and you can create an organization with an Azure account.
Start Automating Now
Performing code builds manually is not only time consuming but error-prone. How do you save time and prevent unwanted bugs from creeping into code? Build a CI process into your pipeline to save considerable time and money over the long run.
If you’re not currently automating code builds and testing, what are you waiting for? Pick a tool (either free or paid) and get started! You’ll be thankful you’ve automated away all of those mundane yet critical tasks in your SDLC.