[GO] continuous integration and continuous delivery memo

url:http://blog.csdn.net/hunterno4/article/details/22525667

A good book makes you change. It will change your mind, the angle and the way you look at the problem, and ultimately, it will change your behavior. However, all important changes will not happen overnight, and if you believe that this change is going to happen, try to do it in that direction, change it a little at a time.

--"Continuous integration: the way of software quality improvement and risk reduction"

The value of CI:

Reduce risk: the detection and repair of defects is faster; through continuous testing and continuous review, the health of the software can be measured, and false assumptions can be reduced.

Reduce the repetition process

Generate deployable software at any time, any location

Enhanced visibility of projects

Build stronger product confidence in the development team's software products

CI obstruction:

Increased maintenance overhead

The team has changed too much.

Too many failed builds

Additional hardware and software costs

7 Good CI practices in the team:

Submit code frequently

Do not submit code that cannot be built

Fix a build that can't be integrated now

Write an automated developer test

Must pass all the tests and reviews

Perform a private build

Avoid checking out code that cannot be built

Continuous Build:

Automated build every time the code changes

To control the build process under a single-line command

Detach the build script from the IDE to avoid coupling with the IDE

Centrally placed software assets

Create a consistent directory structure

Let the build fail quickly

Build for all environments

Build a computer with specialized integrations

Using the CI server

Perform a quick build: detach a slower build to build less than 10 minutes of integration

Phased construction

Continuous Database Integration:

Integration of database Automation

Using the local database sandbox

Putting database assets into the version control library

Enables developers to modify the database

Let developers be part of the development team

Continuous testing:

The reliability of a linear system is the product of the reliability of each system component, so it is particularly necessary to ensure the reliability of the underlying components

Automate unit testing, component testing, system testing, functional testing, and high-speed test execution

Write Tests for defects

Allow test components to be duplicated

Try to limit the test to an assertion

Continuous review of code, complexity, coupling, and repeatability of code (SONARQUBE)

Continuous deployment:

Label each build

Perform tests

Create a Build Feedback report

Process capability for rollback builds

Continuous Feedback:

Don't let your team get used to ignoring messages from the CI build process

Need feedback as quickly as possible: the core of continuous integration is to reduce the time interval for defect ingestion, discovery, and repair

"Continuous Delivery: a systematic approach to releasing reliable software"

Software Delivery:

Each modification should trigger the feedback process

Feedback must be received as soon as possible

Interaction teams must receive feedback and respond

Use the same deployment method regardless of the target environment you deploy to

Principles of software Delivery:

Create a repeatable and reliable process for the release of software

Automate almost everything: configuration management Automation, acceptance test automation, database lift-level automation, hardware virtualization technology and tools like Puppet to support Automation

Put everything into version control

Do the things that make you feel miserable in advance and frequently

Built-in quality: Once a defect is found, fix it immediately, and everyone in the delivery team should be responsible for the quality of the application

Done means that the published

The delivery process is the responsibility of each member

Continuous improvement: The team should hold regular meetings to reflect on the past period of time to do well, which needs improvement.

Configuration management:

Version control of all content, including software, hardware, and infrastructure of the application, everything related to the project is in the version control repository (but it is not recommended to include the source code compiled binaries in version control).

Frequently commit code to the trunk, minimizing branching

Use a meaningful commit comment

Treat your system configuration in a way that treats your code so that it can be properly managed and tested

Store the actual configuration specific to the test environment or production environment in a separate code base that is separate from the source code

Production environment should be strictly controlled and change process management should be carried out.

Efficient configuration Management policy: Separates binary files from configuration information, and saves all configuration information in one place.

Infrastructure should be self-governing and easily re-built

Ensure that the configuration management is declarative and idempotent, that is, regardless of the initial state of the infrastructure, after performing the configuration operation, the state of the infrastructure or system must be the state you expect.

If the version control system allows, try to choose an optimistic lock (editing a file for a local working copy does not prevent other members from modifying it)

The law of Conway: The organization of the design system inevitably produces the same design as the communication structure of the Organization, that is, the products developed by the small teams that sit together tend to be tightly coupled, non-modular.

Continuous Integration:

First, good practice:

Do not submit new code after build fails

Run all the commit tests locally before committing, or let the continuous integration server do this

Wait until the submission test passes and then continue working

Build must be in a successful state before going home

Always ready to roll back to the previous version

Specify a repair time before rolling back

Do not comment out the failed test

Be responsible for the problems you cause

Test-driven development

Second, the recommended practice:

Extreme Programming Development Practice

If you violate architectural principles, let build fail

If the test run slows down, let the build fail

If there is a compile warning or code style issue, let the test fail

Test strategy:

Once the same test has been repeated several times manually and is sure that it will not take much time to maintain it, it should be automated

Unit tests should not access databases, use file systems, interact with external systems

Demonstrate functionality to customers as frequently as possible

Establish some basic non-functional tests, such as capacity testing and security testing.

Submitting tests should avoid complex data preparation, but use as few test data as possible to assert that the unit being tested correctly accomplishes the desired function.

Use the application's public API whenever possible to create the correct initial state for the test

Deployment Pipeline:

Only one binary package is generated and the resulting binary package is stored in the product library, and subsequent tests and deployments are based on this binary package

Adopt the same deployment approach for different environments

Smoke test the deployment, and the smoke test should also check that the services that the application depends on are all started

Deploy to a copy of a production environment, i.e., first to a class production environment

Every change is immediately delivered in the pipeline

As long as there is a link failure, stop the entire assembly line

To expedite the feedback process as soon as possible, increase the testing in the submission phase

Typically, you should use incremental methods to implement the deployment pipeline: Build, deploy, unit test, code review, acceptance testing, release, and so on, the deployment pipeline should be constantly changing, continuous improvement and reconstruction

Make overall optimization, shortening cycle time, i.e. modifying a line of code to the final deployment to the online and effective time

Make sure to use relative paths as much as possible when building

Minimize the number of builds that need to be managed

Acceptance Test:

When writing application acceptance criteria, you must think about how to automate them and follow the Invest principle (independentnegotiable valuable estimable small testable)

Try to decouple from the GUI

Try to make the test atomic, which is independent of the order of execution of the test

In a single test range, you should avoid all asynchronous situations and avoid crossing test boundary conditions

Early repair of failed acceptance tests

When acceptance testing takes a long time, consider using virtualization technology for multi-environment parallel testing

Capacity testing, but before a solution needs to be measured, the root of the problem must be found, and premature optimization is the root of all evil.

For a capacity test environment you can take a scaled class production environment instead of the entire cluster

Automated capacity testing as a complete standalone phase in the deployment pipeline

Deploy and publish:

People who really perform deployment operations should be involved in the creation of the deployment process

Documenting deployment activities

Do not delete old files, but move to other locations

Deployment is the responsibility of the entire team

Server applications should not have a GUI

Warm-up period for new deployments

Fast failure

Do not modify the production environment directly

Top

1

Step

0

[GO] continuous integration and continuous delivery memo