Tell the product manager what is continuous delivery and DevOps-Alibaba Cloud Developer Community

Click follow asynchronous books , set the top public number

I share IT with you every day, good books, technology, dry goods, workplace knowledge

this guide applies:

  • you are a product manager or MBA in the field of science and technology. Your team played A/B test and changed features. There is A dog in your office. Of course, you have understood what is a functional branch, what is a CD, and what the DevOps culture looks like. Right? Yes, of course.
  • You are on the way to agility, and the engineering team now meets with your product staff every week to discuss stories and iterations. They cooperate well and feel better about the things they build. But your customers still can't get these features faster. You still have to wait for the release train to leave the station. You have heard that companies like ued, Flickr, and Google can deliver 100 times a day. How do they do it?
  • Your development team wants to implement "CD" (Translator's note: Continuous delivery-Continuous delivery). You have heard some good things, but you are also worried that these changes have not been properly tested or cannot be properly marketed into the product. So, what on earth is CD?

Here I will unveil the mystery of these practices, tell you how important they are "in business" and let you participate. This is actually not complicated. We have diagrams and all the information.

Let's start with some conceptual definitions and examples.

in traditional software development, the integration process is usually carried out after everyone completes the work and at the end of the project. The integration process usually takes weeks or even months, which may be very painful. Continuous integration is a practice of integration in the early stages of the development cycle so that construction, testing, and integration of code can be carried out more often.

CI means a developer who writes code on a notebook at home (such as Steve) and another developer who writes code on an office desk (such as Annie) you can write software for the same product separately and merge their modifications into a place called source code library. They can then build the software from their own code that is written and merged together and test whether it works as they expect.

Developers usually use a tool called CI server to build and integrate it. CI requires Steve and Annie to have self-test code. These code tests themselves ensure that they run as expected. These tests are usually called unit tests. After integrating the code, Steve and Annie will obtain the green build version when all unit tests pass. This indicates that they have verified that their changes have been successfully integrated and that the code works as expected in the test.

However, although the integrated code can work successfully, it still cannot be put into production because it has not been tested and verified in similar production environments to show that it can work.

You can read more information after completing CI in the "Continuous Delivery" section below.

In order to practice CI,Steve and Annie must submit the code to the main source code repository to intensively and frequently integrate and test their code. Usually multiple times per hour, but at least once a day.

The advantage of CI is that the integrated code becomes "non-event. The software has been written and integrated. Before CI, code integration occurred after the creation process, all integration was completed at one time, and the time spent was unknown. With CI, code integration takes place every day and takes only a few minutes. It is only the way we work.

Your team is likely to be working on CI (or at least they believe they are making trouble). You can confirm it by asking them if they integrate the code every day. CI is the first practice required for continuous delivery. In fact, if you have checked in help text, documents, or pictures, you may have been continuously integrating.

let's return to the two developers Steve and Annie. Continuous delivery means that every time Steve or Annie changes, integrates, and builds the code, they also perform automatic code testing in a very similar state to the production environment. We call this series of "deployment-test" operations in different environments deployment pipeline. Generally, the deployment pipeline has a development environment, a test environment, and a quasi-production environment. However, these stages vary with teams, products, and organizations. For example, our Mingle team has a quasi-production environment called "cake", while Etsy's quasi-production environment is called "Princess". (Note: to eliminate the differences between the development environment and the production environment, see Docker technical system)

in each different environment, the code written by Annie or Steve is tested separately. This gives them more and more confidence. For you, it works when the code is deployed in the production environment. Most importantly, the code can only be upgraded to the next test environment after passing the previous test in the deployment pipeline. In this way, Annie and Steve can get new feedback from testing each environment. If errors occur, they can more easily understand where the problems are and fix them before the code enters the production environment.

this process is very helpful to our work. This means that if Annie's test passes in all environments, you can know that her code should also work as expected in the production environment. Once all environments pass the test, you can immediately decide whether your users can obtain it. Do we want this green build to be used in production? Of course! In addition, as your developers complete the construction, new, fully tested, and working software can be immediately provided to customers. Cool!

This is a practice, that is, every change made by Steve and Annie is automatically put into the production environment after passing all the testing stages. Tim Fitz first put forward a good explanation. Some companies do this while others do not. To implement continuous deployment, you must first implement continuous delivery. Therefore, it is not important to decide which one is more suitable for you before starting to practice CD. Either way, I think continuous delivery is something that contributes to the entire business capability, so you should at least be involved in deciding whether to use continuous deployment. After all, if you are reading this article, then you may be in "business".

the word "DevOps" originates from the vocabulary combination of "Development-Development" and "operation-Operations. DevOps is a culture that promotes cooperation between developers (such as Steve and Annie) and other professional technicians (such as 5-star O & M star Eddie)-commonly known as O & M. Specifically, it is communication and collaboration in the process of software delivery and deployment, aiming at releasing higher quality software faster and more reliably.

The common features of organizations with the so-called DevOps culture are: independent teams with multiple skills (Steve,Annie, Joy are all in the same team), high-level testing and release automation (continuous delivery) and team members with common goals and various skills.

You may find that one of the modes that can be used in your organization is that our developers Steve and Annie will cooperate with O & M personnel such as joy to deliver finished software, instead of just "giving" the code they just finished to Roy for release. Similarly, Steve,Annie and joy will all be members of the public product or service team. They are responsible for product support and maintenance together, instead of letting the operation and maintenance team take the responsibility of support alone.

You will also see that automated actions are becoming more and more important for organizations that execute CD and DevOps. This is because in order to achieve the repeatable, regular, and successful software release process that we expect from CD and DevOps, the organization must turn to automation. Manual processes are prone to errors and are inefficient.

DevOps cultures are often associated with continuous delivery because they are designed to increase collaboration between developers and O & M teams, and use automated processes to build faster, more frequently, and more reliably, test and release software. People like all these things we want.

Although the development team often sees the immediate benefits of process improvement, CI,CD and DevOps also have many benefits for the rest of us. In short, I believe that organizations practicing CD and embracing DevOps culture will deliver more valuable and reliable software to their customers more frequently. Isn't it great, right? Especially if you are in "business" (more customers trust, more orders).

Next time I will continue to discuss more about why you should care about these concepts. I will discuss its impact on your business and how to intervene. If you have any questions, please communicate with me in the comments. The main point of these contents is to inform you and give you technical practice information related to business. Great question, welcome to ask!

Checking in-check in

the process of pushing locally developed code changes to the generic code repository. (Note: also known as Commit, Commit)

CI Server-continuous Server integration

tools used to build and test source code. The CI server will tell developers whether their latest code is successfully built and whether they continue to pass the test.

Development environment-Development environment

where developers create, integrate, build, and test code.

Deployment pipeline-Deployment pipeline

this is a series of stages Steve and Annie went through before their code was completed and ready to be delivered to the production environment. Generally, these will be "build, unit test, function test, performance test, deployment". Different automated tests will run at different stages. Software can only be delivered to the production environment through the entire deployment pipeline.

Green build-Green build

green indicates success. A green version or build is a version at a specific stage of the development and delivery process through testing. In general, a build or version will not be upgraded to the next phase of the deployment pipeline unless it is green. The reverse side of the green build is the red build (see below)

Incremental development-Incremental development

do not confuse it with iterative development (see below). Incremental development is to build a small number of products at a time until all products are completed. A portion is added to each increment. These increments may be small or large. You can use CI through incremental development, but it may be difficult to implement continuous delivery or continuous deployment with incremental development, because you must wait until all incremental operations are completed before you can deliver value. A good example to explain the difference between incremental and iterative development is Jeff Paton Mona Lisa. (Translation note: see the illustration below, which means different ways to achieve the goal)

incremental development

iterative Development


all code written by individuals or teams needs to be merged. We call it integration. In continuous integration, we usually mean that software code from individuals needs to be merged regularly. In continuous delivery, we usually refer to the integration of software from different teams to create the entire product.

Iterative development-Iterative development

do not confuse incremental development (see above). Iterative development is to build products one by one from a little bit, and continuously improve them until they are completed. The product is developed iteratively, which means that the same part needs to be improved every iteration. Features vary in different iteration versions, and changes are planned and expected between them. You can use continuous integration, continuous delivery, or continuous deployment for iterative development. The differences between incremental and iterative development are shown in the preceding figure.

Master/trunk/mainline -(Note: the concept of branch in the source code management system. For details, see Git code management system.)

"Master/trunk/mainline" is the main branch of the source code warehouse, that is, the main line. Most people develop on the backbone, which means they have to always integrate their changes into the main line. Others carry out branch-based development when individual developers have their own branches, or the team will have branches with different characteristics.

Production environment-Production environment

this is where software is deployed or released. Customers using your product or website are most likely to use this environment. It can also be called "in production", "in products" and "online".

Red build-Red build

red indicates failure. A red version or build refers to a version that fails the test at a specific stage during the development and delivery process. Generally, if the software is built in red, it will not be promoted to the next stage of the deployment pipeline. The reverse side of the red build is the green build.

Source repository-Source code library

this is where the source code is located. Steve and Annie have their own local code versions that they are working on (that means the code is on their own machines), but after developers submit the modified code, the source code library will contain all the code.

Test automation-automated testing

continuous integration and continuous delivery require high quality automated testing. Testing is a method to check whether the software works as expected. Automated testing is a code writing test that can be automatically run after code is checked into the public source code library.

In the CI world, unit tests are run every time software is integrated and built. If the test fails, the software version will be determined to be unable to work, "Red" and "interrupted". When this happens, there will be "red light" or sad sounds in some workplaces (suggesting that the construction fails).

If the build fails, Steve and Annie (no matter who submits the error code) need to fix it to turn green and make it work. They can fix it by modifying the code or remove the previous changes that caused the interruption.

Unit tests-Unit testing

unit testing is an automated test in code. It tests low-level and monolithic code to ensure that they are available and work as expected. Unit testing is considered a prerequisite for implementing CI and CD. (Note: unit testing is well supported in many languages and frameworks)

continuous Delivery: reliable software release through automated construction, testing, and deployment

Martin Fowler easy-to-read guide on continuous integration

phoenix Project: A Legend story of IT O & M

this article comes from the asynchronous community, by winston, the article "to the product manager, what is continuous delivery and DevOps"

recommended reading

new book list in April 2018

the most complete Python book list for asynchronous books

an algorithm book required by programmers

the first Python neural network programming book

long press the QR code, you can follow us

I share IT with you every day.

Reply "follow" in the background of "asynchronous books", and you can get 2000 online video courses for free; Recommend friends to follow and get the link of gift books according to the prompts, and get a free asynchronous e-reading version book. Come and join us!

Click to read the original text to view the original text.

Read the original text

Selected, One-Stop Store for Enterprise Applications
Support various scenarios to meet companies' needs at different stages of development

Start Building Today with a Free Trial to 50+ Products

Learn and experience the power of Alibaba Cloud.

Sign Up Now