background
First, briefly explain the background, so as to lead to why we have to do this. When the project team is big, the problem we often encounter is the management of the git process, as well as the costs and problems caused by the use of a certain set of git management processes. For example: if you use the gitflow process, you will find that you need a high level of git operation for developers, which is not conducive to the collaboration of people at different levels. Second, you may be unstable in the production version and often need to fix bugs. It is too complicated to pull hotfix and go through a set of processes. In the middle, we omitted the release, or used the pr mode. In the end, we completely abandoned the so-called best practice with various problems, so I decided to go out of my own way, and finally found that my own way is the real best practice. .
Our process is very simple as follows
- master-feature
- Deploy master or tag versions from production to development environments.
- The feature always keeps the feature status and does not merge before it goes online.
- Feature rebase master every day, before going into production, merge your commit into a commit id to submit a merge request. There will be no conflict at this time. Whoever develops the feature and who is responsible for rebase will produce a very good virtuous circle, because the developers are very familiar with their own code, and the master code is absolutely required. Therefore, the possibility of rebase errors is greatly reduced, and there is no conflict in the merge request, so there is no error. And the minimalist operation can also be used by Xiaobai who does not use git.
But there is a problem with the above process. How to deal with the test environment when multiple requirements are developed in parallel? How to deal with the development environment? So the following scheme was derived. Because I may have hundreds of services, but my demand this time only involves 2 services.
According to the above picture, the solution I made is to bind the tester's ip to the version through a gray-scale strategy. And by rewriting the loadblance load rule to bind the version number of the tester's ip with the version number discovered by the service, users who are not bound will go to the original stable environment through the default rules. The same theory can be applied to the development environment.
So the support that needs to be provided here is as follows:
1. Provide a convenient nginx page to configure routing rules
2. The registry provides application-level version management
3. The load component between services provides the version obtained from the registry and provides the version strategy
The descriptions of the articles are very complicated. In fact, if you practice it, you will find it very simple. You can refer to my other article [ Dubbo Extension to Solve the Problem of Sharing Development Environments ]. I am currently working hard to build this system, and first post a theoretical basis. I also hope that some big cows can make this system better.