Continuous delivery: value proposition

In the past decade, an epoch change was the impact of web-based business models on traditional enterprise business models. Amazon is one of the longest and most obvious examples in history. More and more companies (from aviation to financial services) are relying on software to create their competitive advantages.

The business that relies on software has two key components: one is how you want to change the vision of the world, and the other is to collect user feedback as soon as possible. The lean entrepreneurship Movement emphasizes the importance of feedback, not only in startup companies. Companies like Amazon, Netflix, and Facebook continue to make small improvements to their websites to increase revenue and improve the user experience.

What is continuous delivery?

To establish a close feedback loop between users and the project team (including customers or product owners), depending on whether you have the ability to: by continuously delivering new software versions, validate new ideas and software changes and measure their impact on revenue.

For many companies that need a few months to release a new version, it may seem like a fantasy to release it several times in a day. However, following the principles and practices in "continuous delivery", some companies that have been able to release new versions several times a year can also be released several times or more frequently within a month. This is a huge competitive advantage, and it means that it reduces a lot of waste of time and energy.

In fact, continuous delivery has two crucial business benefits:

• First, it allows you to verify the results of the new business solution faster and make adjustments based on actual user feedback. Especially when there are fundamental flaws in your business solutions, you must discover the problems as early as possible, instead of spending months or years with a large amount of money to implement the plan.
• Second, compared with the one-time major version release after the project end, it provides a delivery process that significantly reduces delivery risks, and the cost investment is more predictable.

In addition, it provides two benefits for IT management:

• First, the project managers can see the real progress of the project, because "finished" means that the software running in the real production environment has brought value to users.
• Second, the risk of each release is greatly reduced through regular incremental release.

Achieve continuous delivery

In order to successfully implement continuous delivery, two foundations are required: one is the technical foundation and the other is the organizational foundation. These two foundations have three pillars: (1) Comprehensive Configuration Management; (2) agile testing; (3) Deployment pipeline.

Configuration Management:

For configuration management, there are four key points to achieve continuous delivery:

• First, you must be able to build, test, and deploy your applications in a fully automated manner. To achieve this, source code, test scripts, build and deployment scripts, and database migration scripts must all be included in version management.
• Second, the configuration items during application deployment and runtime must be managed in a unified and centralized manner.
• Third, you must use a fully automated process to create or change configurations in each environment.
• Fourth, all the development work must be completed on the backbone, and incremental implementation can be performed on large features or refactoring, so that the application remains ready to work. If necessary, you can use the configuration switch to prevent users from using the feature through the interface or public interface.

At the same time, effective configuration and release management also relies on close cooperation between the development team and the O & M team (including dBA) throughout the delivery process. To ensure that the O & M requirements are included in the project's consideration, and that applications can be deployed in a class production environment for a single function or cross-function testing at the initial stage of development, O & M personnel should be a member of the delivery team at the beginning of the project. This collaboration is also one of the important cultural transformations advocated by the devops movement.

Agile Testing

The second pillar of continuous delivery dependency isAgile Testing. Of course, it also includes two aspects: technology and organization. From the engineering point of view, automated testing at all levels is essential, including the unit level, component level, and system level (functional and non-functional testing ). Make sure that: if all the automated composite kits are successfully passed, the software itself achieves the release quality, that is, there is no regression defect in the production environment, meet business needs-including capacity and availability requirements.

Agile testing requires quality embedding throughout the delivery process. That is to say, testing is no longer a "phase", but a continuous activity throughout the delivery process. Similarly, the quality of software is not only the responsibility of the tester or QA, but the responsibility of the entire delivery team. Testers and analysts should work together to create testable acceptance conditions. As part of the development process, testers and developers should work together to create automated acceptance tests to verify that the developed content meets verification standards, this is called Acceptance Test-driven development ). Developers are responsible for maintaining Acceptance Tests and ensuring they can always pass successfully.

Deployment Pipeline

The third pillar of continuous delivery is the deployment pipeline. In essence, the deployment pipeline is a model of the existing delivery process and a part of the entire value stream, that is, the value stream from submission to release. You can use a tool like go to model it. Any modifications (including configurations) to the application must be implemented from start to end through the deployment pipeline, that is, the system should be built first, and automatic testing should be run based on the building product, and then put somewhere, to facilitate subsequent deployment to the test and production environments. The deployment pipeline can be seen as an extension of continuous integration, that is, it extends continuous integration from the development team to the test and O & M team.

The tool used to model and manage the deployment pipeline records every build history. It records the version numbers in the version control library corresponding to each build and the environment in which it is deployed, when will the deployment result be "successful" or "failed ". This deployment pipeline should force your deployment workflow (including authentication and authorization) and audit the entire delivery process. Because this pipeline is used to model your development and deployment processes, it provides rich data support for identifying process bottlenecks and continuously improving the delivery process.

Manage projects through continuous delivery

There is no doubt that for teams that have just been engaged in CD, they will be surprised by the discipline they require. Many intuitive ways to manage projects (including interactions between team members) need to change. For the team, the most important thing when implementing continuous delivery is to review what they are doing, just like all agile methods, it also makes incremental changes to work methods and processes and constantly improves them.

Adjust your intuition

Every project has a natural rhythm and style. Traditional delivery projects always have a beautiful and decent progress report at the beginning and middle of the project. However, at a certain point in time, customers and management often find some unpleasant discoveries: although most of the content is "developed", in the integration stage, applications deployed in a production environment with actual loads cannot always work well.

At this point, this project is called a "Dilemma", or "Death marching". People work overtime under great pressure and try to repair the entire system. This makes everyone very dissatisfied, but in fact,
In some fields, this out-of-control model has become a common practice.

In those projects that practice continuous delivery, the start may be slow. Because the project needs to establish infrastructure at the beginning, automate the construction, testing and deployment, and perform the acceptance test in the production environment. This makes team members, especially managers who are new to it, feel uncomfortable. However, this shows that it works. The impact of continuous delivery is that it advances the pain, making the delivery process more stable, authentic, and measurable.

What you realized is that "Development is complete", which is different from "real completion. In reality, the true "completion" refers to the release to the user, or at least strictly perform acceptance and regression tests in the integrated environment, and then demonstrate it to the customer in the production environment. After the development of new functions, there is actually a lot of work to do: This part of the delivery process is called the last mile. Continuous delivery insist that: "Only after this mile", the work is completed, and there is no "50% completed" statement. Therefore, this makes the entire delivery Progress look slow.

However, with continuous delivery, you can achieve sustainability. First, because continuous delivery means that the software is always in the publishable state, the original test and integration phase can be removed, which greatly reduces project risks. In these two phases, we often find serious problems, or even defects in the entire architecture. However, it is difficult to predict the time to fix these problems. Through continuous delivery, these problems will be discovered early in the delivery process, and some repair costs are often relatively low.

Secondly, for new features, customers and users can get feedback faster. Through incremental development and continuous release to users, you can get early feedback and make constant adjustments in the feature creation process. In this way, the evolution of software can quickly meet user needs.

Try incremental development

During incremental development on the backbone, In order to split large features into small, valuable, testable, and relatively independent user stories, close cooperation between analysts, testers, and development teams is required. There are several advantages to doing so.

Perhaps the most important benefit is that it allows the team to differentiate the key and non-key parts of a function, allowing customers to make decisions at a smaller granularity. Break down a "must-do" feature into multiple small and incremental development requirements, which are the core of the function and the peripheral requirements more effectively.

Then, you can test the core feature (the most direct implementation at the beginning) and find out what the user wants to do next. In this way, you can give the customer specific data so that they can better sort the remaining work of this function by priority. Of course, it is also very likely that, after they have seen it, the customer wants to spend the subsequent time on other functions. In addition, we assume that the customer has read it. If you think this feature has no value, you can immediately stop and stop wasting your energy on it.

Incremental development depends on the daily submission of each person, so that the application can be continuously integrated. This seems impossible for teams that are used to developing new features on Long-lifecycle branches or each branch corresponds to a category of customers. The good news is that development on the backbone is feasible, and it is also feasible for a large team. Bad news is that it requires applications to be composed of loosely coupled components and have a good architecture. It also requires that you can control feature enabling and disabling through configuration items on the UI, so that you can flexibly control the feature. When the function is ready, turn on the switch. Even if some new features are only half developed, You can continuously release your software.

However, the benefits of doing so are also great: You can continuously deliver the functions you have already done to customers without worrying about the value of the function. Frequent release of valuable new functions increases revenue
The best way.

How do I know if I am actually delivering continuously?

Does continuous delivery require a checklist like the Nokia test? In fact, there is no need, because there is a very simple method to verify whether you are actually delivering continuously: whether your software is always in the product release status. You only need to press the Enter key to publish it to the user. If your release process is painful and not frequent, and there is a risky integration phase before the release, you are not doing continuous delivery.

The most important measurement of continuous delivery is cycle time: the length of time from deciding to implement an idea to releasing it to the user. There are several reasons for making it an important metric:

• First, this is a global metric used to measure the effectiveness of the entire process.
• Second, this is a team metric, not a one-person metric. Only when the entire team focuses on improving the delivery process can the cycle time be changed.

The deployment pipeline provides some answers: The implementation of the deployment pipeline will provide you with some data you need, mainly from submission to release. Then, as long as you have a way to associate the submission with the feature, you can see the cycle time of a feature. If the current tool does not allow you to collect the data, find one.

In this way, you can develop a continuous improvement process, apply constraints, or use dashboards to locate bottlenecks in the delivery process and find a way to remove them. Continuous delivery can also be achieved through incremental means of continuous improvement to reduce costs and increase revenue.

For more information about the "continuous delivery" principles, practices, and cases, visit the continuous delivery Chinese site.

The original Article is published in infoit.