top of page
  • Lukas Oberhänsli

Continuous Integration and Continuous Delivery (CI/CD)

The days of manual, time-consuming and error-prone software installations are over!


Continuous Integration (CI) ensures that a software product always is up to date. Every change is continuously integrated into the existing software and checked for quality.


With Continuous Delivery (CD) we focus on the efficient delivery of this software. Thanks to automated and repeatable processes, the software can be published easily at any time.


In this blog post, we will explore the CI/CD best practices that make a real difference in software development. We also give tips on what to pay attention to when implementing an efficient integration and delivery pipeline.


Continuous Integration (CI)

Continuous integration aims to incorporate changes into the software as frequently and quickly as possible. This approach should also be taken into account in the planning phase of the features to be developed: Ideally, features are designed so that they can be developed and integrated within one day. During this integration process, various steps are executed to ensure the quality of the software.


Branching strategy

"Branching" is the creation of new version branches within a software. Every branch represents an independent version of the software. During integration, the changes to these branches flow into the main branch, sometimes called "master" branch. A well-thought-out and simple branching strategy is the foundation of successful continuous integration.


The most direct approach is to commit every change directly to the main branch. This approach is known as Trunk Based Development (TBD). This means that the main branch always remains up to date. Additional branches can be created if necessary, for example for releases.

Trunk Based Development (TBD)

Another proven branching strategy is the Github-Flow. Separate branches – called feature branches – are created for each new feature. After the feature is completed, this branch will be integrated into the main branch.

Github-Flow

The more complex the branching strategy, the longer the integration process can take, increasing the risk of merge conflicts. Therefore, it is advisable to avoid complex branching strategies such as Git-Flow.


Quality assurance

To ensure the quality of the main branch, quality standards are set and checked with every integration. Some essential quality standards for integration are:

  • Code compilation: With each integration, the code is recompiled to avoid syntactic errors.

  • Automated testing: The code should be comprehensively and automatically checked using various testing methods, be it unit tests, integration tests or other methods.

  • Code coverage: This ensures that the code is sufficiently covered by test cases.

  • Static code analysis: Various tools can scan the code for patterns that often cause errors or reduce quality.

There are numerous other quality standards that can be added. However, it is important that these standards can be automated in order to make the integration process as efficient as possible.


Code reviews through pull requests

A pull request (PR) or merge request offers the opportunity to integrate suggested code changes from a feature branch into the main branch. These changes are typically reviewed by another team member before being pushed to the main branch.


Although this approach has many advantages, there are some challenges associated with CI:

  1. Delay in the integration process: Using an additional feature branch and the pull request can slow down the integration process. It is not uncommon for PRs to remain open for several days, which contradicts the basic idea of continuous integration.

  2. False feeling of security: The impression often arises that the review process serves as the final check. However, in practice the reviewer usually only has limited insight into the changes and would need significantly more time for a thorough examination.

While pull requests are great for sharing knowledge and maintaining quality standards, regular code reviews and pair programming can be more effective methods for making the integration process efficient.


Automated tests

A key element for continuous quality in software development is automated testing. These can be carried out in the form of unit tests, integration tests or other testing procedures. Each test is designed to check specific aspects of the code or functionality, allowing errors to be identified and resolved early. You can find out more details about the various testing procedures and their areas of application in our blog post on the topic "Software Testing".


Continuous Delivery (CD)

With CI frequently integrating code, the next logical step is to verify and deliver these changes to the customer. Continuous Delivery ensures that the software can be delivered at any time.


Customer feedback

Continuous Delivery makes it possible to receive faster feedback from customers. With CD, software updates are released more regularly and in shorter cycles, meaning customers get access to new features and improvements more quickly. This makes it possible to collect direct feedback and make adjustments or optimizations.


Troubleshooting

By continuously and automatically delivering software updates, CD enables errors to be identified early and resolved quickly. Unlike traditional methods where bugs may only be discovered after a major release, CD allows bugs to be identified in smaller updates. This not only reduces the complexity of troubleshooting, but also reduces the time from discovery to resolution of the problem.


Automated CI/CD pipelines

Pipelines orchestrate and automate Continuous Integration and Continuous Delivery. They are designed to reduce manual intervention as much as possible.

CI/CD Pipeline

In the example shown above, every code change automatically starts a new build in the main branch. This build includes not only the code changes, but also the associated tests, which are then executed automatically. If all steps of the CI pipeline have been completed successfully, the software version is ready for delivery.


The CD pipeline begins with the creation of a specific release branch. The release branch can either use the last existing build or trigger a new build. The software is then subjected to further testing, including regression testing and manual user acceptance testing. Once these tests have been successfully completed, the software package will be prepared for delivery.


Continuous Deployment

While Continuous Delivery ensures that a deliverable software product is available, it does not automatically mean that every change is immediately deployed to the production environment. This is where Continuous Deployment comes into play and ensures that changes are rolled out automatically and directly to the production environment, without manual intervention.


However, such a high frequency of releases is not suitable for every software product or every business need. Companies must consider which approach best suits their goals, their product and their target group.


Conclusion

Together, Continuous Integration and Continuous Delivery form a powerful duo that optimizes the software development process. CI ensures that code changes meet the highest quality standards through constant integration and testing. This minimizes the risk of errors and ensures that, if they occur, they can be identified and corrected immediately. CD enables software to be delivered in a stable, automated process. This accelerates the path from code change to production while ensuring delivery is smooth and consistent.

bottom of page