Release Dimension to Support Devops and Continuous Delivery
In the last post in the cloud computing series for beginners, we deepen the issues surrounding cloud computing security and encryption. In this post, we will cover the integration practices between development, infrastructure and testing teams, concepts that make up the so-called "DevOps pipeline".
Continuous Integration (CI) is a software development practice where programmers integrate the code created by them several times a day from a shared repository. First suggested in 1991 by an American software engineer named Grady Booch, the term "Continuous Integration" provides for the integration of code from automated tests and build checks. Automated testing is not a mandatory part of CI, but generally its use is implicit and highly recommended.
The practice of continuous code integration for software development in an Agile context is important because it improves quality, reduces the risk of bugs and establishes an accelerated, reliable and sustainable development pace. Let's say that with CI, the "system always works", which means that it is possible to deploy it even during development.
It is also important to mention that continuous integration embraces the DevOps culture, based on a set of operational principles and practices that allow application development teams to perform code changes more frequently and reliably.
There is a consensus in the industry regarding 4 indicators that really make a difference to analyze the maturity of the Digital Products development process:
- Deployment Frequency: The frequency with which the Product/Application is updated in the Production environment, for the final customer;
- Change Failure Rate: The percentage of changes deployed in Production that need to be reversed or corrected on an emergency basis (hotfix);
- Average Lead-Time: The average time that each new version of the application takes between the team to complete the development and the application to be made available to the final customer in Production;
- Time to Restore Service: Calculated by summing all periods of unavailability within a time window and dividing this sum by the number of incidents within the window;
These four indicators have a strong correlation with the maturity of the Continuous Integration process. Measuring and improving them will help to refine the Digital Product in critical aspects of quality, safety and reliability.
The deployment is also known as the CI/CD pipeline, and introduces us to the next related subject: Continuous Delivery (CD).
Continuous Delivery (CD)
Continuous Delivery (CD) is a development approach where teams produce software in short cycles, ensuring that it is released reliably, manually, at any time. Note that the word "manually" was not accidentally highlighted. In continuous delivery, frequent sending of code to a given environment (such as testing or production) is done through manual release, and aims to build, test and deliver software with greater speed and frequency. The approach helps to reduce the cost, time and risk of delivering changes during development by enabling incremental updates for applications still in production.
Here comes an important point: do not confuse the concepts of Continuous Delivery and Continuous Deployment: while in continuous delivery the release of code is manual, in continuous deployment this release of code is automated, and for an environment production – in other words, it is available in real time to its users. Therefore, they are similar concepts, but it is important to understand that they are quite different in approach. Roughly speaking, Continuous Deployment can naturally be associated with the DevOps approach to software development, the most "mature" of all, with Continuous Delivery x Continuous Integration being part of the process to get there in a continuous and successful way.
The concept of continuous delivery is important for the Agile movement because being able to release the development code at any time means being able to close faster feedback cycles. For example, if a software has good built-in metrics (hint: it needs to have it), it will be able to get information from its customers quickly about what they value most in the developed software. The combination of Continuous Integration and Continuous Delivery (CI/CD) practices ends up creating a fast and effective process to put a product on the market before even the competition, in addition to releasing new features and bug fixes to keep satisfied customers already conquered.
The CI/CD approach features continuous automation and continuous monitoring throughout the application lifecycle, from integration and test phases to delivery and deployment. The goal of the DevOps culture is to merge the Dev (developer) and Ops (operational) roles, as well as the processes they manage, to achieve business goals more quickly, automatically and fluidly; however, it is often confused with the Continuous Delivery approach. Instead, as a Gartner analyst points out, "DevOps is not a market, but a tool-centric philosophy that supports a continuous delivery value chain".
In other words, it is as if continuous delivery were contained in the DevOps culture and not the other way around. All of this is driven by digital business strategies that stimulate the demand for faster and more efficient software delivery. However, both methodologies also share characteristics in common, such as Agile and Lean Thinking to deliver small and rapid changes in collaboration with IT teams.
Continuous Deployment (CD)
While in Continuous Delivery, as we saw above, the deployment follows a manual model according to the demand, in Continuous Deployment the deployment is done automatically every time. Continuous deployment means that each code change made by the developer goes through a pipeline and, if it passes all tests, is automatically deployed in production, therefore, executing changes that end up being visible to all users of the software. That is why Continuous Deployment can only work on highly mature DevOps teams, as the quality of the final product release depends completely on the quality of the test suite – created by the DevOps teams – since everything is automated.
Before starting a Continuous Deployment approach, with changes automatically sent into production, it is first recommended to start and foster a good culture of Continuous Integration (CI) among the development teams, combined with Continuous Delivery (DC) practices, as described above. In other words, you may have noticed that everything is related here: Continuous Integration x Continuous Delivery x Continuous Deployment.
If you are looking for tools for Continuous Deployment and happened to fall in this post, we highlight the most popular at the moment: AWS CodeDeploy, Octopus Deploy, Jenkins, Github, GitLab and CircleCI. Some of the benefits of the continuous deployment approach in application development include smaller versions and, therefore, easier to understand. Since everything is automated, no one has to worry about making a deployment. As new features and improvements go straight into production when they are ready, the feedback cycle with customers is much faster.
—
If you liked the post, subscribe to our newsletter and receive blog updates, such as the 7th post in the cloud series for beginners, which we will cover A/B and Canary tests releases and the Kayenta project from Netflix.
In the last post in the cloud computing series for beginners, we deepen the issues surrounding cloud computing security and encryption. In this post, we will cover the integration practices between development, infrastructure and testing teams, concepts that make up the so-called "DevOps pipeline".
Continuous Integration (CI) is a software development practice where programmers integrate the code created by them several times a day from a shared repository. First suggested in 1991 by an American software engineer named Grady Booch, the term "Continuous Integration" provides for the integration of code from automated tests and build checks. Automated testing is not a mandatory part of CI, but generally its use is implicit and highly recommended.
The practice of continuous code integration for software development in an Agile context is important because it improves quality, reduces the risk of bugs and establishes an accelerated, reliable and sustainable development pace. Let's say that with CI, the "system always works", which means that it is possible to deploy it even during development.
It is also important to mention that continuous integration embraces the DevOps culture, based on a set of operational principles and practices that allow application development teams to perform code changes more frequently and reliably.
There is a consensus in the industry regarding 4 indicators that really make a difference to analyze the maturity of the Digital Products development process:
- Deployment Frequency: The frequency with which the Product/Application is updated in the Production environment, for the final customer;
- Change Failure Rate: The percentage of changes deployed in Production that need to be reversed or corrected on an emergency basis (hotfix);
- Average Lead-Time: The average time that each new version of the application takes between the team to complete the development and the application to be made available to the final customer in Production;
- Time to Restore Service: Calculated by summing all periods of unavailability within a time window and dividing this sum by the number of incidents within the window;
These four indicators have a strong correlation with the maturity of the Continuous Integration process. Measuring and improving them will help to refine the Digital Product in critical aspects of quality, safety and reliability.
The deployment is also known as the CI/CD pipeline, and introduces us to the next related subject: Continuous Delivery (CD).
Continuous Delivery (CD)
Continuous Delivery (CD) is a development approach where teams produce software in short cycles, ensuring that it is released reliably, manually, at any time. Note that the word "manually" was not accidentally highlighted. In continuous delivery, frequent sending of code to a given environment (such as testing or production) is done through manual release, and aims to build, test and deliver software with greater speed and frequency. The approach helps to reduce the cost, time and risk of delivering changes during development by enabling incremental updates for applications still in production.
Here comes an important point: do not confuse the concepts of Continuous Delivery and Continuous Deployment: while in continuous delivery the release of code is manual, in continuous deployment this release of code is automated, and for an environment production – in other words, it is available in real time to its users. Therefore, they are similar concepts, but it is important to understand that they are quite different in approach. Roughly speaking, Continuous Deployment can naturally be associated with the DevOps approach to software development, the most "mature" of all, with Continuous Delivery x Continuous Integration being part of the process to get there in a continuous and successful way.
The concept of continuous delivery is important for the Agile movement because being able to release the development code at any time means being able to close faster feedback cycles. For example, if a software has good built-in metrics (hint: it needs to have it), it will be able to get information from its customers quickly about what they value most in the developed software. The combination of Continuous Integration and Continuous Delivery (CI/CD) practices ends up creating a fast and effective process to put a product on the market before even the competition, in addition to releasing new features and bug fixes to keep satisfied customers already conquered.
The CI/CD approach features continuous automation and continuous monitoring throughout the application lifecycle, from integration and test phases to delivery and deployment. The goal of the DevOps culture is to merge the Dev (developer) and Ops (operational) roles, as well as the processes they manage, to achieve business goals more quickly, automatically and fluidly; however, it is often confused with the Continuous Delivery approach. Instead, as a Gartner analyst points out, "DevOps is not a market, but a tool-centric philosophy that supports a continuous delivery value chain".
In other words, it is as if continuous delivery were contained in the DevOps culture and not the other way around. All of this is driven by digital business strategies that stimulate the demand for faster and more efficient software delivery. However, both methodologies also share characteristics in common, such as Agile and Lean Thinking to deliver small and rapid changes in collaboration with IT teams.
Continuous Deployment (CD)
While in Continuous Delivery, as we saw above, the deployment follows a manual model according to the demand, in Continuous Deployment the deployment is done automatically every time. Continuous deployment means that each code change made by the developer goes through a pipeline and, if it passes all tests, is automatically deployed in production, therefore, executing changes that end up being visible to all users of the software. That is why Continuous Deployment can only work on highly mature DevOps teams, as the quality of the final product release depends completely on the quality of the test suite – created by the DevOps teams – since everything is automated.
Before starting a Continuous Deployment approach, with changes automatically sent into production, it is first recommended to start and foster a good culture of Continuous Integration (CI) among the development teams, combined with Continuous Delivery (DC) practices, as described above. In other words, you may have noticed that everything is related here: Continuous Integration x Continuous Delivery x Continuous Deployment.
If you are looking for tools for Continuous Deployment and happened to fall in this post, we highlight the most popular at the moment: AWS CodeDeploy, Octopus Deploy, Jenkins, Github, GitLab and CircleCI. Some of the benefits of the continuous deployment approach in application development include smaller versions and, therefore, easier to understand. Since everything is automated, no one has to worry about making a deployment. As new features and improvements go straight into production when they are ready, the feedback cycle with customers is much faster.
—
If you liked the post, subscribe to our newsletter and receive blog updates, such as the 7th post in the cloud series for beginners, which we will cover A/B and Canary tests releases and the Kayenta project from Netflix.
Source: https://elven.works/en/continuous-integration-and-continuous-delivery-ci-cd-in-the-devops-pipeline/
0 Response to "Release Dimension to Support Devops and Continuous Delivery"
Post a Comment