What is continuous integration (CI) and continuous deployment (CD)? Why has this method for delivering updates to software become the hallmark of advanced, modern software development methods using the DevOps method? In this article, Travis CI is going to tell you.
To understand CI/CD, it is useful to think firstly about DevOps – the development methodology with which it is closely linked and associated. In fact, to a large extent, it can be said that CI/CD underpins the whole methodology upon which DevOps is based.
DevOps is a software development methodology that aims to bridge the traditional divide between development (dev) and IT operations (ops) sides of the development process.
Historically, these two vital parts of the software delivery process worked as silos with “dev” writing new code and “ops” provisioning it onto customer-facing (production) infrastructure. Even where software engineers and network managers sat in the same room, this stop-start methodology inevitably resulted in feature release lags because one process had to end before the other could begin.
Increasingly, this problem became a serious one for organizations whose businesses depended upon the timely release and development of code-based products – like SaaS companies whose attractiveness to users often depends upon what features they have availability. A laggy release cycle could lead to customer attrition and cost the business bottom line.
Security also began to present itself as a pressing concern. As hackers became more organized and efficient at discovering and exploiting vulnerabilities, the work of security – patching these exploits – had to be done quickly, almost immediately. Waiting for dev to roll out fixes only for them to be implemented months later was no longer viable.
If ‘dev’ and ‘ops’ are two ends of a bridge, then CI/CD connects the two sides. Or rather, it is the technology and workflows that allow for the seamless and continuous passage of information — development releases — between its two ends.
With CI/CD, rather than waiting for an intermittent release cycle slowed down by pauses, code updates are continuously pushed from software developers where they can be parsed and then integrated leveraging as much automation as possible.
CI/CD pipelines enforce a rigid series of checks intended to standardize the vital QA process — although humans oversee the process and can get involved manually at any time. Finally, code is continuously released onto production services thereby becoming available to end-users. In more advanced pipelines, the deployment of infrastructure to accommodate new code iterations can even be part of the pipeline management tool itself.
If we return to the metaphor of CI/CD being the bridge that allows ‘dev’ and ‘ops’ to connect, then continuous integration and continuous development are its two endpoints.
Continuing with our analogy, continuous integration refers to the ‘start’ of the bridge.
Developers work in teams in order to produce code that will later be compiled and delivered in the form of staged releases to end-users.
This code needs to be continuously integrated into the CI/CD pipeline. CI is therefore, ultimately, a form of automation in development workflows. Not only does it intake code through, typically, a repository management system. It then moves it through an orderly series of quality control checks to make sure that it is in good enough condition to actually send out to end-users.
On the other end of our proverbial bridge we have continuous delivery. The CD in CI/CD, however, can also stand for continuous deployment.
What’s the difference between continuous delivery and continuous deployment? There’s one critical difference: in continuous deployment, releases to end users — the final stage in the development pipeline — happens automatically. Continuous delivery stops the process one step short of that, carrying the automation all the way through to the final stage before deployment (hence the name).
Continuous delivery involves guiding code through a series of stages which are undertaken after the integration part of the pipeline (which typically consists of building and initial testing) are completed. These are:|
● Acceptance testing: designed to ensure that at a high level the update accords with the specs of the system or software being developed
● Deployment to staging: here, code is moved (“deployed”) from development servers and onto staging servers. If this process is successfully completed, the pipeline moves to
● Deployment to production: It is here that continuous delivery and continuous deployment differ. In continuous delivery this final process requires human (manual) intervention.
The CI/CD pipeline refers to the series of steps that are undertaken as code is produced by developers and then made to pass through a series of automated tests on its way to ultimately being delivered to users. We have covered many of those — especially in the CD phase of the process — above.
To fill in the missing pieces:
As we have seen, the continuous integration part of the pipeline is concerned with integrating source code, building packages, and then beginning to test them.
Specifically, the following steps are essential:
| Trigger | Firstly, there needs to be an automation in place that “tells” the CI/CD pipeline that new code has been committed. In practice, this is achieved by using a repository manager such as Assembla, Bitbucket or GitHub. These tools allow multiple developers to work on the same codebase without creating conflicts with one another’s code. Once an update is committed, the pipeline is notified. This aspect of the pipeline is fully automated. As soon as it receives a commit, it begins processing the code further. At this stage, the pipeline manager will also check the code out from the repository. |
| Compiling | Next, the program has to be compiled from the source code. In modern workflows, Docker containers are often used to manage the process of running tests against code on easily transportable environments that replicate real runtimes. |
| Unit Testing | At this stage, the QA process gets underway. The codebase is put through a series of tests. In most pipeline managers, users can choose to either use standardized tests, write custom tests, or (very commonly) choose to run their code through a mixture of both. The repository manager and those following the CI/CD pipeline are notified whether the tests pass or fail. If they fail, the pipeline is automatically halted so that developers can review the test results and then remediate those in their next code update. |
And finally the pipeline transitions towards the deployment phase with the push onto the staging server and finally onto production.
Like most revolutions in technology, CI/CD can be a fantastic productivity-enhancer. Alternatively, it can cause confusion and frustration. The key to whether you have a successful outcome or the opposite when deploying a CI/CD pipeline manager and moving towards a Dev-Ops approach lies in whether you follow best practices or not.
Here are some of them to keep in mind:
In traditional development approaches, developers may be encouraged by team leaders to sit on their code as long as possible. Ideally ironing out preliminary bugs before passing it on any further.
CI/CD calls for a radically different approach and this needs to be communicated to all team members. Because the testing phase is automated, it encourages developers to work as quickly as possible on what they do best – development.
Because QA is carried out automatically — but that process can only be initiated once the pipeline is triggered — it makes sense for developers to be encouraged to commit as frequently as possible.
Some integrated development environments (IDEs) even have a feature for automatic periodic committing. But even if your tech stack doesn’t have such a tool, developers can be encouraged to commit code to the repository as often as it makes sense for them to do so. The more frequently code can be integrated into the pipeline, the more quickly the iterative cycle can self-improve, leading to faster product releases.
If hurdles stand between the code developers and putting out the production environment, team members may inevitably be tempted to seek out the path of least resistance.
Don’t underestimate the possibility that developers may seek to develop their own techniques intended to circumvent the CI/CD pipeline. This might take the form of deploying shadow technology or finding ways to skip parts of the testing process.
It’s essential, therefore, that you make sure that your CI/CD pipeline is a watertight gatekeeper and the only viable path for code to travel from the developer’s workstation to the product that your customers touch.
A lot of work goes into developing a successful and productive CI/CD pipeline: ensuring that the series of tests followed reflect those that are going to help take a codebase from its raw format into peak and (ideally) bug-free condition ready for users to fawn over.
Unfortunately “set it and forget it” isn’t the best approach. Given the extensive amount of automation that your typical CI/CD pipeline leverages, it’s important to also pay attention to analytics (most have this functionality).
What tests are tripping up the most failures? What teams are ignoring best practices the most frequently? This kind of information can be an invaluable source of information to mine in order to iteratively improve the development process.
A vital part of the QA process is emulating the performance of packaged code on the type of system that it is expected to be run aboard.
Given that many development teams are tasked with developing products for several different operating systems and architectures simultaneously, this can quickly result in “VM-sprawl” — having to deploy a large number of resource-intensive systems solely in order to perform basic system testing.
A compelling alternative to this bloat-by-testing is using container programs such as Docker instead. These compress operating systems into barebones packages, therefore also making them highly transportable between teams not physically co-located. Using this kind of technology can make it much more effective to quickly spin up new testing environments as the pipeline requires it.
CI/CD pipeline management tools have become entrenched as fundamental building blocks of DevOps-based development approaches, greatly increasing the efficiency of code delivery and reducing annoying internal silos (thereby also cutting down on frustration within the development team).
A CI/CD tool such as Travis CI can allow you to:
● Quickly gain user-friendly analytics presenting complicated test data in easy to read format, allowing developers to quickly move into remediation
● Organize and automatically prioritize test results for fixing, assigning them unique IDs and automatically routing them towards the best-placed resource on your team
● Integrate the CI/CD pipeline seamlessly with parts of your stack that your team already uses and loves, such as GitHub, Hooray, and Heroku. There’s even a Slack integration allowing your pipeline to push out updates to those monitoring it on the team’s central communications hub.
Transitioning from a traditional development approach to one centered around DevOps can also:
● Allow you to greatly improve the speed of your feature pipeline rollout – giving your product an edge over those of competitors.
● Allow your development resources to spend more time on developing code and planning features and spend less time on ironing out bugs and kinks. CI/CD tools are great ways to begin the transition towards more segmented development workflows, allowing QA resources to focus on what they do best.
● Present your team and organization as a more attractive employer for future talent. These days, DevOps-based workflows are standard in the development world. In-demand talent will be most attracted to organizations that are already leveraging modern development and release approaches, such as those built around Travis and CI CI/CD pipeline.
| Consider Travis CI for your Enterprise CI/CD needs. Get a Travis CI free trial today. |