Let’s talk about Continuous Delivery and its relationship with ITIL.
Continuous Delivery occurs through the continuous integration of completed software by Development, using executables and automated tests to detect problems.
Therefore, the goal is to ensure that the software is always available for release throughout its life cycle, in any environment.
Thus, it is understood that Continuous Delivery supports Agile and DevOps practices, accelerating deployments.
In other words, this reduces risk, demonstrates progress, and provides frequent feedback.
About Continuous Delivery
A company that adopts Continuous Delivery works with:
- Software deployment and the entire life cycle;
- Teams that prioritize deployable software over new features;
- Obtaining fast and automated feedback on the production readiness of the system when something is changed;
- The ability to push-button deployment of any software version to any environment on demand.
By the way, Continuous Delivery is not the same thing as continuous deployment. Continuous Delivery enables frequent deployments to be made if the organization desires.
The software may be ready in a test environment but not deployed.
Tests can function similarly to production, ensuring that the code works and is always in a deployable state. Deployment is the installation of a software version in a specific environment.
Therefore, for Continuous Delivery to be successful, it is necessary to monitor the deployment pipeline.
This should be done in an automated manner, including all environments.
Continuous Delivery as a Management Practice
Analyzing how Continuous Delivery works, we can think that it is more suitable for organizations that:
- Want to maximize the results of Agile, DevOps, Lean, or Shift Left;
- Wish to minimize the risks associated with testing and catch errors before they become too costly to fix;
- Want to minimize delays related to testing;
- Want to manage volatile services and applications more efficiently;
- Currently have many developers or work with geographically separated Development teams.
Of course, this practice may not be positive in some cases.
When is Continuous Delivery not beneficial for companies?
Continuous Delivery is not beneficial for companies that:
- Lack integration of tools in the life cycle management or lack automation resources;
- Have poor quality assurance and testing practices;
- Have small development efforts where Continuous Delivery would mean overhead;
- Have a weak or declining pace of business changes.
Therefore, it is worth noting: before adopting Continuous Delivery as a practice, consider whether it is really necessary.
Benefits of Continuous Delivery
Many benefits of Continuous Delivery also support other progressive practices. Here are the main advantages:
- Support for progressive practice principles, performing Shift Left on testing and deployment activities;
- Faster development lifecycle for releases;
- Support for independent development teams, maximizing time and efforts on important activities in this phase, instead of focusing on integration and testing;
- Detection of integration errors early in development, making it easier and more cost-effective to fix;
- Support for Agile development with small increments, addressing how they will be efficiently tested and deployed.
Challenges of Continuous Delivery
Although it has these benefits, Continuous Delivery presents some challenges for its operation:
- Lack of funding or management commitment to acquire the necessary tools and automation for testing and deployment;
- Integration and automation of development activities with testing and deployment activities;
- Focus on tests and deployment that can benefit the most first;
- Recognition of an iterative approach to building Continuous Delivery resources, as this works better than implementing everything at once;
- Convincing the organization that continuous deployment is not the same as Continuous Delivery;
- Commitment to building Continuous Delivery skills and facing resistance from those who believe that effort could be better spent building more applications.
In addition, another challenge is finding the balance between the frequency of code commits and the loads on testing and deployment to eliminate bottlenecks and delays.
Continuous Delivery and Service Management
Continuous Delivery has an impact on several activities of the VeriSM model, including activities in the “Define” stage and the Change Control process itself.
In fact, when adopting Continuous Delivery, the company will need to consider how the Change Control process operates, including the automation and integration of a set of tests and deployments.
That is, Change Control will still be recorded, but meetings and impact analyses of changes will be reduced due to automation in Continuous Delivery, meaning that failures will be identified without intervention.
Testing and deployment will also be affected in that tests will always be active and automated.
Meanwhile, Release Management will be transformed. Traditional software release practices will be automated.
Continuous integration supports the introduction of code into continuous testing and delivery installations.
On the other hand, in the “Define” stage of the VeriSM model, we integrate activities with Continuous Delivery.
While development focuses on code, other services will be available to support availability management and capacity management.
In addition, it will also be possible to support Business Continuity.
Therefore, if you have any questions about Continuous Delivery, leave them in the comments so we can help you! Read the other posts on the blog to stay updated.
English 
