kentoh - Fotolia
What the CI process can and can't do for software delivery
Continuous integration, software delivery and deployment are distinct software lifecycle stages, but they are far more complementary than competitive in modern dev methodologies.
Continuous integration can seem antithetical to continuous delivery and deployment, but in reality, the CI process and ensuing deployment tasks are a one-two punch for rapid time to market.
CI refers to the build and test stages of software development. While nothing gets deployed by the CI process, it provides significant upshots for the software staging and deployment steps.
When first envisioned by IBM's Grady Booch in 1991, CI referred to a continuous software compile. This idea made sense when the majority of software was built by compiling source files into a single executable file. If the files were consistent by themselves but out of sync with each other, the compile into a sole encoded sequence would fail. Yet, things are different today. The CI process is more than a continuous build.
Modern CI steps
Modern architectures often do not have a server that generates webpages. This is true of service-oriented, front-end architecture -- commonly called SOFEA -- like the kind that powers Gmail. Instead, the server sends individual files with JavaScript that calls web APIs. Mobile applications frequently have a small GUI shell that calls APIs.
If applied to this environment, the CI process typically:
- builds and runs the mobile application;
- builds and installs the APIs in a test environment; and
- exercises the code to see if it works from the front end to the API and, possibly, all the way down to the database and back with a result.
The CI process compiles the code and runs unit tests over each piece in isolation. It can go farther with continuous delivery (CD) steps that create the test environment and fill it with data, deploy functionality within the test environment and run integration tests to hit various subsystems to see if they respond properly. CD tools can even act like a user when they open up a browser and interact with the entire system.
Tools can also identify if there is a problem and send notifications to the relevant team lead or the person who maintains the build process.
CI, along with CD, does everything short of deploy to production.
What follows the CI process
Where CI automates all the pieces before deploying to staging, continuous deployment -- not to be confused with CD -- automates all the pieces after it. With continuous deployment, tools automatically build, test and deploy every change that is pushed into Version control, as long as the CI process runs with no errors.
The simplest way to implement continuous deployment is to take some files and copy them over to a production server, perhaps over FTP. Yet, that approach neither considers uptime nor what happens if the deploy process fails. Also, this approach doesn't monitor production, and there is no autorollback if something goes wrong.
Back in 2009, IMVU became one of the first organizations to publicly claim to use continuous deployment. Author and consultant Michael Bolton, one of several vocal critics of the approach, wrote that testing without a human element might not be able to deliver quality software. When he tested this assertion, his concerns seemed valid.
An IMVU executive, in response to Bolton's post, clarified that the company did have human team members involved in all steps of the process, including testing. Additionally, the company said it rolled out changes gradually with A/B split testing. The case of IMVU showed that continuous deployment can work in tandem with a variety of different app dev approaches.
To sustain software uptime with continuous deployment, some organizations build blue/green production environments that are identical. Live workloads run on the green environment, while new code deploys to the blue one. When the new system is complete, the traffic flips to hit the blue setup, which becomes the new green environment. If something goes wrong, the traffic can revert to the trusted previous version still configured on the blue infrastructure.
Additionally, an organization can have testers sit with programmers and switch roles between development and test stages. This strategy reduces risk and ensures the code is production-ready by the time it is pushed into version control for automated deployment.
The aforementioned practice of split testing can also implement continuous deployment by enabling rolling changes. You might, for example, have categories of users, such as testers, beta users and power users. Using if statements and configuration flags, programmers can deploy a feature change and limit access to these testers or another defined group.
While programmers might bungle the setup of the configuration flags and roll the changes out to all users, teams can generally identify these types of errors and recover quickly.
How CI enables rapid deployment
In modern app dev processes, automated application integration and deployment techniques often occur together, although not necessarily in perfect sync. For example, the CI process can occur multiple times an hour, while deployment -- even automated deployment -- takes place less frequently.
CI generally runs on a loop a few times an hour, while continuous deployment pushes changes to production between a few times a day and every couple of days. The better and faster that a CI loop delivers production-ready code builds, the more easily an organization can deploy to live users.
In order to even have a continuous deployment loop, organizations need a CI process that runs reasonably quickly. After the CI tools and workflows are in place, find and remove barriers to high-quality deployments. CI impairments might include manual steps, approvals, change controls and monolithic architectures.
