Continuous integration is the first half of the acronym CI/CD, with Continuous Delivery completing the second half. In this three-part article, we look at the two halves of CI/CD to define and understand them, and then, in part three, we talk about how Uptrends fits into your CI/CD processes. Let’s get started at the beginning with continuous integration.
So, what is continuous integration?
Continuous Integration (CI) is a process used by software developers to build software quickly and efficiently. The software developers break the needed functionality down into small logical pieces in the planning phase. Once planned, the code is written and tested on the developer’s computer during the coding phase. When satisfied, the developer checks the code into a version control system. The code check-in triggers automated processes that incorporate the changes into a new build and continuously test the software. Once incorporated, the cycle starts again with the planning phase of the process.
Why use continuous integration?
The main reason to use a continuous integration process is that CI reduces the time between the planning and delivery of new software. Previous software implementation processes required developers to work in isolation for extended periods. The developers worked from design specs, and their code was often untested in conjunction with the work done by other developers until much later in the process. After what was sometimes months or even years of work, the integration of the code commences followed by sometimes an even longer period of bug fixes, code revisions, and corrections to the functionality. Afterward, all of that rework required further regression testing, and the customer hasn’t even seen and approved the product yet. Do you see where we are going here? No place—not quickly anyway.
So why use CI? CI results in better code delivered to end users quickly by revealing errors in code design, issues with code and system integration, and performance problems in a super quick feedback loop.
How does continuous integration speed up the development process?
As described above, when developers write code in isolation over long periods, it becomes difficult to integrate the new code into the base application without significant problems. Finding the bugs in the code is time-consuming and frequently leads to the inclusion of more code conflicts and more bugs in often unexpected areas of functionality. The integration process often takes longer than the time it took to code the feature, so the process is expensive and significantly delays the delivery of the product.
Using CI, many developers or teams of developers work from use cases or user stories. A use case or user story describes one unit of functionality, such as the adding of a product to a shopping cart. Once the developers code and test the new feature on the localized copy of the development environment, they check their code into a version control system like Git. The action of checking in code triggers an automated process that integrates the code into the application. An automated process does further testing on the new functionality while the developer moves on to a new use case, and others can continue to build on the new code.
With CI, you spend more time developing features and less time fixing your code. The short development iterations result in earlier delivery dates and a more robust product.
A continuous integration example
To illustrate the CI process, let’s take a look at a calendar application used for scheduling appointments. Currently, in the hypothetical application, a user can reserve an appointment date and time, but they can’t cancel or reschedule the appointment using the application. So the goal is to add the functionality to the application. Your lead decided that you write the cancellation portion of the functionality while a coworker takes on the rescheduling of an appointment portion. Here is your process:
- You replicate the current application from the versioning platform onto your computer.
- You write the code. This small amount of functionality includes a new button or link in the application that the user clicks to cancel the appointment. Once the user confirms their decision to cancel the appointment, a simple function you’ve written sends a request to the database to remove the appointment from the calendar.
- You thoroughly test the code in your copy of the application.
- You commit your changes to the versioning software. The changes kick off an automated build and testing process.
- You check the build results for issues. If none, you move to the next step, otherwise it’s time to revise your code. For example, you’ve checked in code for canceling the appointment, but while you were working on your local copy of the application, your coworker checked her user interface changes. You’ve both added a button in the same place on the page. The build fails due to the conflict, and you’ve got to move your button and check the code back in.
- You move on to another use case or continue building on the same one.
You’ve added some badly needed functionality to the product, and it isn’t even time for lunch. The new code is part of the product now—well, in the development environment’s current version of the code.
Your lead tasked Mia, your coworker, with the other part of the new functionality. She needs to cancel the current appointment and update the database with the new date and time. Mia made changes to the user interface that makes rescheduling possible, but, behind the scenes, Mia’s new functionality uses your function to cancel an appointment and reuses the calendar’s old functionality to make the new appointment.
Your new code was ready for Mia to reuse in record time. Between the two of you, in one morning, you’ve added value to the application.
Automation is key
The agile development environment is dynamic. Changes happen quickly, and continuous integration is an important part of the development process. At the center of the CI process is the automation of building and testing the software. In the case of websites, web applications, and APIs that testing requires checking for functionality, performance, and availability.
You can take Uptrends behind your firewall to monitor your development environment. Because Uptrends’ Private Checkpoints reside on your servers behind your firewall, your Private Checkpoint can monitor your development environment in the same way regular Uptrends checkpoints monitor your web-facing infrastructure. You can develop your API monitors and Web Application Monitoring scripts right alongside your evolving application code. When you’re ready to deploy your development environment, you can automate the porting of your new or modified monitors directly to your acceptance or production environment (more on that later).
Next up: Continuous delivery
