In general, we can divide the
devops system into three parts: code, configuration and deployment environment
Code
Good code management guidelines are: development branch, deployment tag
Ideally, our permanent branch has only one master, unless there is an LTS (long-term support for a certain version) requirement.
Feature
development uses feature- *, the test passes, and should be deleted immediately after being merged into the master branch
BUG repair uses hotfix- *, the test passes, and should be deleted immediately after being merged into the master branch
The extra branches are increasing the complexity of code management and deployment
Configuration
It should be emphasized that the configuration should not be part of the code
First define the following dimensions for the configuration:
Log level: DEBUG | INFO | ERORR
Data persistence (that is, whether it is a production database): true | false
Performance requirements (such as thread pool, connection pool): low | high
Network sensitivity (that is, the delay tolerance of calling external services): low | high
Key visibility (various services that require authentication): open | transparent
If the configuration of each environment is placed in the source code, the key will inevitably be exposed to all
developers, and the key confidentiality requirement cannot be met;
If the server computing and storage capabilities are not the same, then performance optimization cannot be performed;
At the same time, if a higher network delay is set, for a network with a smaller RTT, when some services are unavailable, it cannot be detected in time, and it will still cause more request failures.
Therefore, only the local development configuration required by developers should be kept in the code, and it has nothing to do with the local environment. This can be done through Docker.
Deployment environment
In addition to the local
development environment required by developers, at least a test environment and a production environment are required.
If there are resources, the test environment can be further divided into joint debugging environment, pseudo production environment and quasi-production environment.
The corresponding configuration is as follows:
Configuration item \ Environment Local development Joint debugging Pseudo production Quasi-production Production
Log level DEBUG DEBUG INFO INFO ERROR
Persistent Pseudo Pseudo Pseudo True True
Performance requirements Low Low Low High High
Network sensitive Low Low Low High High
Key visibility public transparent transparent transparent transparent
Among them, pseudo production can be used for acceptance test (alpha test), quasi-production can be used for gray scale test (beta test);
The configuration of quasi-production is basically the same as the production environment, and the configuration of the joint debugging environment is basically the same as the pseudo production environment;
If the resources are insufficient, the joint adjustment environment and quasi-production environment can be subtracted.
Incident and response process
Development of new functions:
Create a new local branch feature- [new feature] based on master
Local development and testing
After the development is complete, use git rebase master to avoid conflicts, then push to the remote branch, request to merge to the master and delete the remote branch
Merge the master and delete it, and publish it to the test environment
If the test fails, go back to step 1; if the test passes, it ends
Finally, after all the features in this iteration have been tested, then play TAG on the master and prepare to release a new version.
Fix online BUG:
Create a new branch hotfix- [BUG] based on the online version of TAG
Local development and testing
After the repair is complete, push to the remote branch
Publish the remote branch to the test environment
If the test fails, go back to step 2; if the test passes, join the master and delete the branch, hit TAG, and prepare to release the patch version
Version release / rollback:
Iterative development is completed, based on the new version of TAG, released to the production environment
When rolling back, the TAG based on the previous version is released to the production environment
During hot repair, the TAG based on the hot repair version is released to the production environment
Corresponding release method of code and deployment environment
Branch \ Environment Local Development Test Production
feature- * based on local file X X
hotfix- * based on local file based on branch X
master X based on branch based on TAG
