What is 'Continuous Integration' and 'Continuous Delivery' ?


“Continuous Integration (CI)” and “Continuous Delivery (CD)” terms has become more popular over the last two years. Actually, these terms are older than you think. Especially “Continuous Integration” was first appeared in 1991. But these terms has become more meaningful after the software development lifecycle started to loop faster.

Nowadays, software development teams are getting more crowded and software is getting more complex. Whereas, development timetables are getting tighter.

With all these changes, a new term (or discipline) appeared that named “DevOps”. DevOps (Development Operations) concept aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably. At this point of view, -as a part of DevOps- the CI and the CD aim at the building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable building, testing and deployment process is important for CI and CD.

When I started to work in enterprise-level software projects, I have usually heard phrases like “we are releasing the new version of our software at first Sunday of every month” or “we are shutting down the whole system and releasing the new version”. In these days, these phrases sound like very old to me.

Sometimes we have to develop, test, build and deploy a piece of software more than one time in a single day. And in these process, the whole system couldn’t be interrupted somehow and must be up and running. Because of this, CI/CD concepts are getting more important for us.

Continuous integration is integrating one’s new or changed code with the existing code repository. This operation occurs with no interruption and commit, build, and test procedures perform without developers noticing. Every commit to the repo triggers a new build, rather than a periodically scheduled build. All of these operations obviously need a version control system that supports all these operations and CI concept. I’ll use Visual Studio Team Services (VSTS) on the next post for CI/CD operations.

Obviously, you need a version control system and automated build that runs after all commits. All of these builds must test automatically and all the members of the team aren’t interrupted during these operations. After all these steps finished with success, the build outputs (artifacts) may be delivered/released/deployed with CD operations.

Continuous Delivery is the natural extension of Continuous Integration. Teams ensure that every change to the repository is releasable, and they may release any version with the push of a button (not literally a button :relieved:).

Continuous delivery is enabled through the deployment pipelines. These pipelines might be connected with each other and every pipeline might aim different team or group of people and different environment. Typically a software project has testing and production environments. This means It has two CD pipelines.

When a new commit made to the repo, CI is triggered automatically. After CI is succeeded, CI outputs start to processing via first CD pipeline and so on. There might be pre-deployment and post-deployment approvers on pipelines and the process may be canceled or reversed by these approvals.

In summary, CI-CD lets an organization deliver the new software releases to customers more quickly. The developers, testers, QAs achieve significant time savings. The risks associated with a release significantly decreases, and the release process has become more reliable.


alatas.github.io    github pages, hyde theme, liquid, jekyll { paginate, gist, sitemap, seo-tag, feed, jemoji }