One of the ongoing deliveries-software delivery issues

Other continuous delivery related articles: "Continuous delivery" series of articles Directory

Chapter One problem of software delivery 1. Introduction

The core model of the book is 部署流水线 that 持续集成 theory is the cornerstone of its theory

Deployment pipeline has three targets

• Let software build, deploy, test, and publish processes visible to everyone, facilitating collaboration
• Improve feedback to find and solve problems earlier in the process (doing one thing, having problems happen is certain, it is important to quickly locate and solve problems)
• Enables the deployment and release of any version of an application in any environment to become an automated process that increases efficiency

A simple and simple部署流水线

Submission phase ==> Automated Acceptance Testing ==> automated capacity Testing ==> manual testing ==> Release

2. Some common anti-pattern 2.1. Anti-pattern: manually deploy software

This anti-pattern generally has the following characteristics

• There is a detailed documentation that describes the many things that need to be
• Manual test program is running correctly
• There are always customers to ask, the deployment of why the problem
• If it is a clustered environment, the configuration of the environment often has a discrepancy
• The publishing process takes a long time
• Published results unpredictable (with luck)
• Always working overtime, and I don't have problems.

The ideal deployment process should be

1. Pick the version and environment you want to deploy
2. Click the Deploy button

Why you need to deploy automation

• To make the deployment process repeatable
• Eliminate the maintenance of deployment documentation, where one deployment script is all documents
• The deployment process can be audited and tracked
• Get rid of the excessive reliance on people

2.2. Anti-pattern: deployment to the production environment only after development is complete

A situation that often occurs

• OPS has never been exposed to applications before.
• Program-related configurations, database scripts, deployment documents, etc. are not tested in a formal environment
• There is too little collaboration between the development team and the OPS team

caused by various problems

• First-time deployment was a nightmare.
• The larger the gap between the development environment and the deployment environment, the more problems
• Collaboration between teams

Solution Solutions

Incorporate testing, deployment, and release activities into the development process, making them part of the normal development process and testing the deployment process as well

2.3. Anti-pattern: manual configuration of production environment

This anti-pattern often has the following characteristics

• Well, I'm local.
• Each node in the cluster behaves differently
• Each time you prepare for an environmental event long
• Cannot roll back
• Unknowingly, the server in the cluster, the operating system configuration has become different

How to solve these problems?

With configuration management, you can repeatedly create every infrastructure you need to develop your application

The information in each environment should be fully controlled, and all environment generation, configuration modification should be implemented by Automation program, prohibit manual modification

2.4. How to change this situation

Use deployment lines to turn software publishing into a low-risk, frequent, inexpensive, fast, and predictable process

The final goal is to achieve a one-click Software release by combining automated testing and deployment with comprehensive configuration management

3. How to achieve your goals

frequent automated release software is required to ensure continuous delivery of our software at high quality

For frequent automated release software, feedback is critical and should be up to three standards for feedback

• Any modification should trigger the feedback process
• Feedback should be issued as soon as possible
• The delivery team must receive feedback and respond to it based on it

Here is a detailed description of these three standards

3.1. No matter what kind of modification should trigger the feedback process

These modifications include modifications to the following items

1. Source code (continuous integration)
2. Configuration information (configuration management)
3. Operating environment (infrastructure and environmental management)
4. Data (data management)

Feedback process

Fully automated way to test every change as much as possible

Test content includes, but is not limited to,

• The process of creating executable code must work. This is used to verify that the source code conforms to the syntax
• The unit test of the software must be successful. This checks to see if the application behaves the same as expected
• The software should meet certain quality standards, such as test coverage and other technology-related metrics
• The functional acceptance test of the software must be successful. This checks to see if the application meets the business acceptance criteria and delivers the desired business value
• The software's non-functional testing must be successful. This checks to see if the application meets the user's requirements for performance, effectiveness, security, etc.
• The software must pass exploratory testing and demonstrate to the customer and some of the users. These are usually done in a manual test environment. At this point, the product owner may think that the software function is missing, we may also find the defects that need to be repaired, but also write automated tests to avoid regression testing

3.2. Feedback should be issued as soon as possible

The key is automation, mainly through the deployment pipeline to achieve, the following chapters will be described in detail

3.3. The delivery team must receive feedback and respond to it based on it

No response, what is the feedback?

3.4. Can this process be promoted?

Many ideas come from lean manufacturing, with the goal of delivering high-quality products quickly, focusing on eliminating waste and reducing costs

The idea has been proven by multiple industries, and the authors have experienced many projects that have been more consistently delivered.

4. Results 4.1. Authorized Team

Let the whole team work together

4.2. Fewer errors

Avoid most errors by reducing manual repetitive tasks

4.3. Relieve stress

Make publishing tasks easy to control, lest each release be formidable enemy

4.4. Flexibility in Deployment

Always find a previous deployment version, view deployment any version

4.5. Practice to make it perfect

The goal is to use the same deployment method regardless of the environment you deploy to

5. Candidate Release version

Each commit code produces a published version

But in real development, to verify a published version, it is necessary to do an integration, usually this process is difficult to control, so it will be postponed, the lower the frequency of integration, the more painful, but the more painful things, the more often to do, or it will be more painful

This book will make integration painless by continuing to integrate this practice

6. Principles of software Delivery

To ensure high quality continuous delivery, the following can be used as a code of conduct

6.1. Create a repeatable and reliable process for the release of the software

In the final analysis, software deployment includes three things

• Provide and manage the operating environment required for the software, including hardware configuration, dependent software, infrastructure, and external services required
• Install the correct version of the application on it
• Configure the application, including any data and status required

6.2. Automate almost everything

Don't do it yourself if you can get the machine to do it.

6.3. Include everything in version control

Make each version relevant to the information quickly found

6.4. Do things that make you feel miserable in advance and frequently

This is a very useful heuristic principle.

6.5. Built-in quality

Everyone is responsible for the quality, the problem is solved immediately

6.6. "Done" means "published"

We think that a feature can only be done when it's in the hands of the user, not when it's finished.

6.7. The delivery process is the responsibility of each member

From recriminations to mutual cooperation

6.8. Continuous improvement

Deming Cycle (Plan->do->check->act)

7. Summary

The goal of this book is to make the release process painless

One of the ongoing deliveries-software delivery issues