Con­tin­u­ous delivery is an in­no­v­a­tive concept in software de­vel­op­ment that is becoming in­creas­ing­ly popular. With con­tin­u­ous delivery, the pro­duc­tion steps of de­vel­op­ment, quality assurance, and delivery are not final, but are repeated au­to­mat­i­cal­ly in a loop during the de­vel­op­ment process using the con­tin­u­ous delivery pipeline. This has the advantage that you can subject software products to a quality check piece by piece and at short intervals and deliver them while you’re still working on the product. You receive constant feedback in the pipeline, allowing you to improve the software im­me­di­ate­ly after each change to the source code.

De­f­i­n­i­tion

Con­tin­u­ous delivery is a model that is used in software de­vel­op­ment to run de­vel­op­ment, delivery, feedback, and quality man­age­ment in parallel at short intervals in a con­tin­u­ous loop. This makes de­vel­op­ment more efficient and the customer receives the product earlier, even if it is not yet finished. Con­tin­u­ous delivery provides the developer with feedback through automated tests, which usually check the build after every change to the source code.

Con­tin­u­ous delivery describes a rec­i­p­ro­cal process that combines and automates de­vel­op­ment, delivery, feedback, and quality man­age­ment. This minimizes lengthy and time-consuming work steps.

The benefits of con­tin­u­ous delivery

In classical software de­vel­op­ment, the end product is only delivered if it contains all the planned features, runs smoothly, and has no serious defects in the quality check. The developer then usually supplies the software with patches and updates at regular intervals. With con­tin­u­ous delivery, the product is delivered to the customer at a much earlier stage of de­vel­op­ment, while work on it continues. The pre-release version often only contains the core functions of the software, which are then tested by the customer in a real en­vi­ron­ment. The customer (or the software tester) therefore plays an important role in quality assurance.

The feedback gained in this way helps the developer to improve the existing features during de­vel­op­ment. He may also get valuable hints as to which feature should be developed next. Without con­tin­u­ous delivery, this process is tedious and can lead to both sides being unhappy: The customer usually expects a finished product that meets their re­quire­ments and wishes, but the developer does not yet know exactly what these are. If com­mu­ni­ca­tion about the product's de­vel­op­ment status begins at an earlier point in time, customer wishes can be taken into account more easily and errors can be avoided. The principle can be il­lus­trat­ed as a cycle:

Image: Cycle development, quality management, production
Con­tin­u­ous delivery automates the process cycle from de­vel­op­ment, quality man­age­ment, and pro­duc­tion.

The three areas of de­vel­op­ment, quality assurance, and pro­duc­tion do not replace each other in a single process, but interlock con­tin­u­ous­ly. This means that the product passes through the in­di­vid­ual phases again and again and is con­tin­u­ous­ly improved. When there are many customers, this cannot be achieved without au­toma­tion. This is where con­tin­u­ous delivery comes in by au­tomat­ing the entire process.

Thanks to con­tin­u­ous delivery, you can test every edit and en­hance­ment made to the software (i.e. every change to the source code) in real time in order to collect feedback. Unwanted side effects are quickly visible, allowing you to intervene at an early stage of de­vel­op­ment. This is es­pe­cial­ly handy because it makes it easier for you to determine which part of the code causes a bug, for example. Without con­tin­u­ous delivery, finding a problem is often very tedious.

When it’s on its way to the customer, the software is in an in­ter­me­di­ate stage: the con­tin­u­ous delivery pipeline. Both manual and automated tests are carried out in this pipeline. Each test phase entails a new software version (usually referred to as a "beta version," sometimes also as a "nightly build," i.e. a version created au­to­mat­i­cal­ly “overnight”), which in turn enters the pipeline. Only if all tests are suc­cess­ful and give sat­is­fac­to­ry feedback, can a “stable” version be created and the product of­fi­cial­ly released (this process as well as the published ap­pli­ca­tion itself is called a “release”). The prob­a­bil­i­ty that the customer will receive a bug-free product is much higher.

Image: Continuous delivery pipeline when changing code
The con­tin­u­ous delivery pipeline is triggered every time you make changes to the code.

This is the biggest advantage of con­tin­u­ous delivery: the automated process benefits both the customer and the developer. For the customer, the product is available faster and is usually error-free. For de­vel­op­ers, “field testing” is far more effective than in-house beta testing, because it provides more valuable data and guidance. The entire de­vel­op­ment process becomes much more flexible and the risk of releasing buggy software is minimized.

Overview: the ad­van­tages and dis­ad­van­tages of con­tin­u­ous delivery

Ad­van­tages Dis­ad­van­tages
Software errors can be found and elim­i­nat­ed much more ef­fi­cient­ly in the de­vel­op­ment process. Cost factor: A strong and reliable in­te­gra­tion server for the automated tests is necessary for a good and secure delivery of the product.
There is less effort than with a classic software release. The de­vel­op­ers can fully con­cen­trate on the actual de­vel­op­ment. The automated tests must be written and function perfectly. Faulty tests can cause great damage during quality testing.
The con­tin­u­ous delivery pipeline makes it much easier for de­vel­op­ers to trou­bleshoot problems. Requires good team co­or­di­na­tion because code changes must be collected fre­quent­ly and ef­fi­cient­ly.
There are fewer costs that would arise from other test processes (e.g. alpha and beta tests). Requires good and con­tin­u­ous com­mu­ni­ca­tion with customers and their target systems.
Quality assurance can devote more resources to the con­cep­tu­al im­prove­ment than to the technical im­prove­ment of the software. The customer expects con­tin­u­ous updates and im­prove­ments. The software project can rarely be "paused."
Software de­vel­op­ment is generally faster, because the largely automated release process relieves de­vel­op­ers of the workload and reduces the number of breaks they have to take. New features, im­prove­ments, and changes to the product are still delivered manually. To automate this process, you need to move to con­tin­u­ous de­ploy­ment.
Faster and more frequent releases ac­cel­er­ate the loop of feedback and im­prove­ment. The customer must show will­ing­ness to use software that is still in de­vel­op­ment. They must also be motivated to provide important feedback.
Since errors are found quickly, there is less pressure on the de­vel­op­ers with every change in the source code. This leads to mo­ti­vat­ing and inspired work.  

The phases of the con­tin­u­ous delivery pipeline

If the code changes, the con­tin­u­ous delivery pipeline is triggered and the test process is executed. These are the phases the con­tin­u­ous delivery pipeline goes through:

Image: Phases of the continuous delivery pipeline
The con­tin­u­ous delivery pipeline follows certain phases and goes through them con­sis­tent­ly with every change in the code.
  1. Commit stage: In this first test phase, the software version is checked, the software com­po­nents are built or compiled, and necessary unit tests are performed. After suc­cess­ful testing, the phase is completed. Binary artefacts of the software com­po­nents are bundled and stored in the repos­i­to­ry. This package then de­ter­mines the func­tion­al­i­ty of the pipeline because it de­ter­mines the software status. Finally, the package includes the amount of data that will later be installed on the target system. The test results in the commit stage can then be assigned to the concrete changes in the source code, which is a sig­nif­i­cant advantage of con­tin­u­ous delivery.
  2. Ac­cep­tance test stage: In the second test phase, the ac­cep­tance tests take place. This includes in­te­gra­tion tests (does the in­ter­ac­tion of the com­po­nents work?) as well as the necessary system tests (does the software work on the user side?). There are also some optional tests that are in­te­grat­ed into the ac­cep­tance test stage, such as per­for­mance tests and other tests that check the software’s non-func­tion­al re­quire­ments. For the ac­cep­tance test stage, the bundle created in the previous phase is reused and installed in a suitable test en­vi­ron­ment.
  3. Any errors or com­pli­ca­tions in these phases will be doc­u­ment­ed and, if necessary, sent as feedback to the developer. This can be done via e-mail, messaging programs, or special tools (see below). Because the pipeline is triggered with every code change, error messages or re­gres­sions always refer to the last change here. This allows the developer to react quickly and ef­fi­cient­ly, and fix any bugs or buggy code.
  4. Manual tests are now performed as required. For these tests, too, the pipeline uses the bundle from the first phase and installs it in a suitable test en­vi­ron­ment.
  5. If all tests are completed with positive feedback, the package can be installed manually on the target system. This usually only requires a “push of a button.” If this step is automated, it is called con­tin­u­ous de­ploy­ment.

Con­tin­u­ous in­te­gra­tion vs. con­tin­u­ous delivery

Con­tin­u­ous delivery and con­tin­u­ous in­te­gra­tion are often mentioned together. However, there is one major dif­fer­ence, which lies in the scope. While con­tin­u­ous in­te­gra­tion refers to au­tomat­ing the test process and shares most of the pipeline with con­tin­u­ous delivery, con­tin­u­ous delivery extends the concept and also includes the release process of the software as an automated process. So, con­tin­u­ous delivery adds the end user to the con­tin­u­ous in­te­gra­tion model by si­mul­ta­ne­ous­ly de­liv­er­ing the product for testing.

Whether a developer simply uses con­tin­u­ous in­te­gra­tion or extends the de­vel­op­ment process to con­tin­u­ous delivery depends on de­vel­op­ment planning, the de­vel­op­ment team, and the customer base. In the following table, we compare both concepts:

Con­tin­u­ous in­te­gra­tion (CI) Con­tin­u­ous delivery (CD)
Automated testing process that crit­i­cal­ly reviews every change in source code. Extends the test process to include the delivery process. New features and changes to the code au­to­mat­i­cal­ly reach the end user.
The team must write automated tests for each new feature, each im­prove­ment, and each code change. The ef­fec­tive­ness of these tests is all the more important in the case of CD because the results are delivered to the end user directly.
Requires a dedicated and con­tin­u­ous in­te­gra­tion server that monitors and applies the automatic tests. The in­stal­la­tion on the target system must also be as automated as possible, which places higher demands on the server.
De­vel­op­ers need to merge their code changes con­tin­u­ous­ly and often. De­vel­op­ers must also maintain good customer contact and be as trans­par­ent as possible about the software.
Requires a rel­a­tive­ly high resource input to ensure product quality on delivery. More effort is involved with CD. But the product can be delivered much earlier and subjected to “real” tests.
The de­vel­op­ment itself is more efficient, but is paused more often by manual releases. It can be developed con­tin­u­ous­ly because the release process is also largely automated.

Popular tools for con­tin­u­ous delivery

Various programs make it easier for you to switch to con­tin­u­ous delivery. We present four of them.

Jenkins

Jenkins is a web ap­pli­ca­tion that enables the con­tin­u­ous in­te­gra­tion of software com­po­nents. Java-based Jenkins runs in any EJB container and contains various build tools (Apache Ant, Maven/Gradle, CVS, Sub­ver­sion, Git, etc.) as well as the automatic test pro­ce­dures important for con­tin­u­ous delivery (JUnit, Emma). Optional plugins ensure com­pat­i­bil­i­ty with other compilers. The REST-based pro­gram­ing interface also allows other programs to access Jenkins. Jenkins is a free open source program. It is rec­om­mend­ed es­pe­cial­ly for beginners because the interface and func­tion­al­i­ty are very beginner friendly.

Tip

Our Jenkins tutorial explains step by step how the ap­pli­ca­tion works.

CircleCI

CircleCI is also a web-based ap­pli­ca­tion for con­tin­u­ous in­te­gra­tion, delivery, and de­ploy­ment. CircleCI works prefer­ably with GitHub, GitHub En­ter­prise, and Bitbucket. In addition, the platform offers many practical features such as order man­age­ment, resource man­age­ment, docker support, support of all known pro­gram­ming languages, secure caching, data analysis with sta­tis­tics, and com­pre­hen­sive security concepts. CircleCI received the "Leader in Con­tin­u­ous In­te­gra­tion" award from Forrester in 2017. The first container is free of charge, the second one is $50 per container per month.

Microsoft Team Foun­da­tion Server

Microsoft Team Foun­da­tion Server (TFS) is a col­lab­o­ra­tion tool for software projects that are jointly planned, created, and then managed. TFS is the un­of­fi­cial successor of Mi­crosoft­'s Visual Source­Safe. To work together on a software project, TFS supports various de­vel­op­ment processes, including CMMI, agile software de­vel­op­ment, and Scrum. For the work, TFS links and in­te­grates familiar Office programs such as Word and Excel, so you don't have to switch from TFS to another program.

Various features are available for con­tin­u­ous in­te­gra­tion, delivery, and de­ploy­ment to help you build a pipeline. TFS basically separates the entire process into the version control, build, reports, and user ad­min­is­tra­tion sections.

Teams with a maximum of 5 people can use the free Express version; all larger teams have to use the com­mer­cial version, which costs about $6 per user per month. However, this usually requires you to purchase a server license. You can also purchase TFS without a monthly sub­scrip­tion, but you must contact a local reseller. The price seems to fluctuate between $570 and $800.

Codeship

Codeship is an SaaS platform for con­tin­u­ous in­te­gra­tion (and delivery) that adapts its scope to the needs of the user. Codeship supports GitHub and Bitbucket as well as GitLab. The available features depend on the re­spec­tive payment plan: In the free version, Codeship provides a preset CI en­vi­ron­ment and also takes care of the CI/CD workflow. In addition, the free version allows efficient caching and parallel testing of builds in shared and pre­con­fig­ured con­tain­ers. The free plan allows 100 builds per month with a con­tin­u­ous build and a test pipeline. There is, however, a missing upper limit for projects, users, and teams.

To get more out of Codeship you can purchase "Codeship Basic," which is available from $49/month and will be more expensive depending on the team size. Another paid version, "Codeship Pro," extends the feature list by one Docker support, the "complete control" over the build en­vi­ron­ment, local builds, and a better control over the workflow. It also provides multiple tools that make con­tin­u­ous in­te­gra­tion/delivery even more efficient and trans­par­ent. Depending on the number of parallel builds, Codeship Pro costs around $75 per month.

Go to Main Menu