Continuous Integration, Delivery

CI

CI is the part where the workflow has to validate each developer commit automatically.

The automatic unit and functional tests are validated by the integration machine e.g. GitLab CI or CircleCi. Once the tests are passed a build/artefact is produced and will be deployed in the TEST environment.

To arrive at a build/artefact

• The code is built at each commit
• The code is automatically unit tested at each commit
• Everyone has access to the build and test report
• Tests are run on a scaled down version of the production environment
• Deliverables are stored in a version-controlled artefact repository
• Deliverables are automatically deployed to a test environment after a successful build

If any of the steps fail then the developer responsible for the commit receives a notification to correct as soon as possible.

The implementation of a CI and all the processes to be integrated

The different types of tests

• Unit tests are used to test methods or functions in the same way as for the development of a product.
• Integration tests are to ensure that several components behave correctly together, they are for functional regressions
• Acceptance tests similar to integration but focused on the business
• User interface tests are for ensuring that from the user’s point of view the interface actions work

To adopt continuous integration, you will need to run your tests on every branch you push.

To do this some simple questions:

• where is the code hosted? Restriction…
• what operating system and resources do we need for the application? Dependencies…
• how many resources do we need for your tests?
• is the application monolithic or microservice?
• do you use containers? Docker…

Test coverage & complexity

It’s good to aim for over 80% coverage but be careful not to confuse a high coverage percentage with a good test suite. A code coverage tool helps us find untested code. The quality of your tests will make the difference at the end of the day.
A tool like SonarQube is there to help make decisions when the code is complex and untested.

Duplication and dead code

Duplicated code will be the future dead code or the future double-fixed bug! It is very important to check your code and reduce duplication to a maximum of 5% duplicated code on a large or legacy project is acceptable but try to be under 2% for any project starting with quality code metrics.

Refactoring

If you are about to make significant changes to your application that do not have sufficient test coverage, you should start by writing acceptance tests around the features that might be impacted. This will provide a safety net to ensure that the original behaviour has not been affected after refactoring or adding new features.

The environment

The entire IT Dev/DevOps/Admin team should keep in mind to keep the same environment everywhere. The revision number of all components used by the application should be the same in Dev/Build/Test/Integration/Prod. This is where containers (Docker) and orchestrators (Kubernetes) are useful.

Mindset

If a developer breaks the CI workflow, fixing it becomes the top priority.

To write good tests, you’ll need to ensure that developers are involved and have access to a code analysis tool.

Whether you have an existing code base or are just starting out, it is certain that bugs will occur as part of your releases. Be sure to add tests when you resolve them to prevent them from recurring.

CD

The deployment of the application is managed by the code. The code describes exactly what the application needs to start and run. The artefact and environment will be the same between the Test/Integration/Production systems because the image is generated only once by the CI.

Continuous Delivery

After automating the creation and unit and integration testing in continuous integration, continuous delivery automates the publication of validated code in a registry/repository. Therefore, to ensure the effectiveness of the continuous delivery process, the continuous delivery process must first be introduced into the development pipeline. Continuous delivery ensures that the code base is always ready to be deployed in a production environment.

In continuous delivery, each step (from merging code changes to distributing production-ready versions) involves automating the code testing and release processes. At the end of this process, the operations team is able to easily and quickly deploy an application to a production environment.

Continuous Deployment

The final stage of a mature CI/CD pipeline is continuous deployment. In addition to the continuous delivery process, which automates the release of a production-ready version to a code repository, continuous deployment automates the launch of an application into a production environment. In the absence of a manual bridge between production and the previous stage of the pipeline, continuous deployment depends mainly on the design of the automation of the testing processes.

In practice, under continuous deployment, a change made by a developer to an application could be released within minutes of the code in question being written (assuming it passes the automated tests). This makes it much easier to receive and integrate user feedback on a continuous basis. Together, these three CI/CD practices reduce the risks associated with application deployment, since it is easier to release changes in small increments than in one block. However, this approach requires considerable upfront investment, as automated tests will need to be written to accommodate a wide range of testing and release stages in the CI/CD pipeline.