Continuous delivery of product managers and devops practices

If you are in the following situations, then this article is for you:

You are currently in the technology industry, you are a product manager, and you understand what a feature branch is, what a CD stands for, and what a devops culture looks like.

Or, you're already implementing agile, and the team meets with your product staff every week to discuss stories and iterations. They work well together and they feel better at this time than ever before. But your customers still can't get these features faster, and you'll still have to wait until the release is available. You've probably heard of companies like Etsy,flickr and Google that deliver 100 times a day, but how do they do that?

Or, your development team wants to implement CI/CD, and you've heard about some good things, and you still care about the variables of the period. So what exactly is a CD?

Let's start with some definitions and examples.

Continuous integration (CI), continuous integration

In the traditional software development process, the integration process usually takes place at the end of the project after each person completes the work. Consolidation usually takes weeks or months and is likely to be very painful. Continuous integration is a way of advancing the consolidation phase to the development cycle so that the build, test, and integration code occurs more often.

Continuous integration means that different team members write software for the same product in different environments and integrate their changes in a place called the repository of repositories. Each piece of code that is written by the needles is built into a whole software and works the way they want.

Developers often work with a tool called Continuous integration Server to build and integrate them. Continuous integration requires that team members have code that can be self-rated, which verifies that the code works as expected, and that these tests are called unit tests. When the code is integrated and all the code unit tests pass, the team will get a successful build result. This shows that they have verified that their changes have been successfully integrated, and that the code works as expected during the test. Although the integrated code succeeds in working together, it is not ready for the production environment because it has not been tested and validated in a simulated production environment. You can read more about what happens after continuous integration in the Continuous delivery section below.

Figure 1

To maintain proper continuous integration practices, code changes for team members must often be submitted to the main source code repository and frequently integrated and tested with their code. Usually one hour at a time, but at least once a day. The benefit of CI is to make integration an unnecessary event. The software is always coded and integrated. Prior to CI, consolidation occurred at the end of the creation process and took place only once, and took an indeterminate amount of time; Now with CI, it happens every day and takes only a few minutes.

Continuous Delivery (CD), continuous delivery

We go back to our development team, where continuous delivery means that every time a change is made to the code, the code is integrated and built to automatically test the code in an environment that is very similar to production. Typically, a deployment pipeline environment has a development environment, a test environment, and a simulated production environment, but these phases vary by team, product, and organization. For example, our mingle team has a stage called "Cupcake", which is a simulated production environment, and Etsy's simulation environment is called "Princess".

Figure 2

In each of the different environments, the coded code test results are different. This process is very powerful for the business. This means that if the unit tests pass all of the environment validation, then you know that the code is likely to work correctly in the production environment as well. Once the test is passed in all environments, you can immediately determine whether your end users are getting the latest functionality. And once your developers are done building, they can always provide new, fully tested work software for their customers.

Continuous Deployment (CD), continuous deployment

Figure 3

As can be seen clearly from the above diagram, continuous delivery is required first in order to achieve continuous deployment. The premise of continuous delivery is based on CI, but ultimately whether it is applied to a production environment or is done manually, continuous deployment truly enables fully automatic deployment of update releases.

DevOps

The term "DevOps" comes from a combination of the words "development" and "action". DevOps is a culture that fosters collaboration between developers and other technical professionals, specifically communication and collaboration in software delivery and deployment, with the goal of delivering better quality software faster and more reliably. The common characteristics of organizations with so-called DevOps culture are: Autonomous multi-talented technical teams, high-level testing and release automation (continuous delivery) and common goal generalists.

The traditional way of software delivery process is as follows:

Figure 4

After using the continuous delivery deployment route, the following figure is shown below.

Figure 5

DevOps cultures are often associated with continuous delivery because they are designed to increase collaboration between developers and operations teams, and use automated processes to build, test, and publish software more quickly, frequently, and reliably.

Digression: This article is Suzie Prince published on the Mindtheproduct website, the first attempt to translate it, so that we can first know agile development, continuous deployment and the way of DevOps, the first translation inevitably have omissions, but also hope you see cool, click the original English original article.

Spring Boot + Elasticsearch for accurate Chinese matching in large volumes of data sets

Spring Boot + Elasticsearch for indexed bulk writes

Spring Boot + Elasticsearch for routine maintenance of indexes

Savage growth of the front, from the Basterds to the regular army

How to build a service quickly under the micro-service system

Introduction of several commonly used online API management tools

You have to know a few Internet ID generator scenarios

Springcloud-based MicroServices architecture practical case-Preface

Programmers to protect your curiosity and thirst for knowledge