In the process of
implementing DevOps, continuous integration and continuous deployment are important cornerstones that DevOps needs to pay attention to when it is launched. In the end, to ensure the successful implementation of
DevOps requires more and more detailed details to be implemented, such as version management. In this article, we will combine the seven scenarios that often appear in the implementation of version management in enterprises to understand why version management is complicated. On this basis, we propose the "seven questions of version management" to help companies to version their own The management ability is quickly positioned, and on the basis of this, the best practice suitable for oneself is explored.
Seven scenes
We list some typical scenarios that are often encountered in actual project combat, and these cross-project "anti-patterns" are so familiar that they have really achieved widespread popularity in our actual software development.
It needs to be emphasized that version management must be considered in complex situations in advance, in order to truly come up with best practices suitable for yourself, a single-function program with tens of thousands of lines of code developed by a small team of several people Generally speaking, there are not many problems encountered, but at the same time when considering multiple teams collaboration, multi-version parallel development, multi-feature parallel development, emergency response frequently, many routine deployments, differential deployment and rollback control, etc. You will find that version management, which seemed so simple, is suddenly strange and complicated.
Scenario 1: It is easy to use on my local machine
There is a problem in the production environment. After confirmation, no problem can be found, because the developer's local environment can run normally, and it can not be reproduced in the public test environment, so this type of problem was initially determined as "only" Strange problems that only arise in the production environment ".
There is indeed such a problem, especially for the large systems that used to have millions and millions of lines in their early days, and no one dares to touch them at will. However, there are many such problems that are only caused by version inconsistency during the final cause analysis: the inconsistency between the production environment and the test environment, and this inconsistency is not well managed, so this has occurred The problem. Specific examples:
The production environment uses the RAC environment of the database, and because of the license, the test environment basically uses ordinary Database instances
The storage used in the production environment, while the test environment uses the local disk
After the installation of
the database and other software in the production environment, there are many settings, it is difficult to ensure that all settings are consistent
Large-scale systems may have complicated situations where thousands of files need to be deployed. The test environment shared by many people lacks a mechanism to ensure that these files are consistent with a certain baseline of version management. Even for an individual-exclusive environment, thousands of files in this environment This file is exactly the same as the production environment, no more, no more, and it is not an easy task.
…
Summarize this scenario: there needs to be such a baseline in version management, which can be kept consistent with the code used in the production environment at any time. Note the following points here:
Anytime:
DevOps emphasizes the realization of corporate goals. No matter what the company is, the maintenance of business continuity is very important. If you cannot achieve consistency at all times in this part of version management, at least the positioning will be much slower when the problem occurs.
Code: The code here is broad, not only those compiled source files or code files that can be executed without compilation, setting files, and some setting operations also need to be versioned from the perspective of Infrastructure As Code. Everything that can be included in version management needs to be included.
Scenario 2: This is not the correct release version
Most of the projects except for the initial release of a new version are from zero to existing process, the remaining cases are from the "old" to "new" process, while maintaining the existing functions and new functions Increase.
From Agile to
DevOps, it is not just the wall that is broken, but the last mile of value flow. But there is no good control of version management. Imagine that it only needs the following scenarios to become very complicated:
Repair of general defects
Emergency repair
Multi-team multi-feature parallel development
As the value that can be delivered, the repaired content can only provide value to customers only when it is actually operated in the production environment, so that the results of Agile's development and delivery have meaning. These fixes often depend on complexity. Because of these dependencies, we have to adjust the order of release. Otherwise, the lighter ones will make the content that needs to be released fail to be released, and the heavy ones will cause the defects that have been fixed to appear again.
To sum up this scenario, a baseline can always guarantee that the newly
developed content can be released at any time, which is also very important.
Scenario three: all the disasters caused by emergency
Everything in the project management is carried out in an orderly manner until a continuous emergency response occurs. After the emergency response, I suddenly found that everything was messed up. The content of the routine test only needs to be merged into the Trunk. Now it is necessary to merge the emergency release part and test it. So many rework, emergency response One merger, one additional test, and one mess, the most frightening thing is that if the merger misses a quality, it will go backwards. The emergency response that has obviously been online has not been used after this routine release. Incident. It becomes more complicated when multiple teams are dependent.
To sum up this scenario: Temporary emergency online corrections may have a lot of impact on the team that develops concurrently at the same time. At the same time, the regular release can also be adjusted accordingly. It is necessary to consider the proper development and release process as a whole.
Scene four: all influenced by their team
When the project scale is small, the members are familiar with each other, and the run-in is better. When the modified module may affect, they will prompt each other, even if not prompted, through continuous integration practice, you can It is guaranteed that the continuous integration of this pipeline will work most of the time, and basically will not cause too much impact. All this until the scale of the project increases, and after adding three small and large teams, everything started to become chaotic.
Each project is continuously integrated towards that line, but I do n’t know that the submitted code will have a lot of impact on others, especially the part of the common module, it is simply messed up, and eventually it becomes the first person to fix it. According to who's thinking, sometimes conflicts occur, and they simply manage the common copy, and they no longer have an influence with others. The only price is that the code is more repetitive, but what is the solution, and Not every project can have an ideal structure and ideal process, and all of these are influenced by their newly added team. In the past, when we were only our team, it was obviously so good.
To sum up this scenario: The size of the team will have a very positive superposition effect on the complexity of the version. Large-scale development will make the original simple things very complicated, and these will introduce more communication and Communication consumes the team ’s already strained energy.
Scene 5: Routine release cannot be implemented normally
Routine releases are performed once or twice a month, and features or bug fixes that are planned according to the plan are released to the production environment. However, the expansion of the project scale and the instability of the application have caused many problems. The instability of the application has led to the emergence of many defects, some of which are very urgent and need to be repaired immediately. It is certainly too late to solve them in the routine release. These urgent correspondences often have a dependency relationship with the following routine releases, and sometimes even the same file. These will inevitably cause routine releases to be reordered or merged and appended to test operations.
In the case where there are many routine releases, and there are many emergency correspondences, there are errors in the busy, and one or two missed management is also occasionally happening, such as forgetting to merge the content of the emergency release into the next routine release The failure that caused the corresponding completion to reappear, also led to a regression in quality.
Summarize this scenario: taking into account routine and emergency releases and ensuring quality during large-scale development, such a standardized process is very important for version management.
Scene 6: All of this tools are not easy to use
The current version management tools are diverse, open source, closed source, fee-based, free, and even many companies have developed some tools suitable for their own use to improve efficiency. Use this today, use that tomorrow, and change to another one if you are not familiar with it. A lot of time is spent learning the use of these tools. Under the development schedule that was not too generous, it will occasionally appear that the use of the tools is not familiar enough. Various problems: What is not submitted to the warehouse, do you want to push after git commit, is it the same as svn commit, I am using svn without problems. The message prompted during Merge was not clear, which led to overwriting other people's amendments to the same file. This is mainly a strange tool. I did not have this problem when I used a familiar tool. Problems like these often happen to novices or just use some new version management tools without enough time to train beforehand.
To sum up this scenario: tools are very important, but it is only one of the helping forces for us to achieve our goals. It is important for the team to be familiar with version management tools and can effectively use the overall development efficiency, while greatly reducing the problems of version management.
Scene 7: I did not carefully look at the difference between the versions before going online
In the last link of continuous deployment, many companies could have changed the fully-automatic process to semi-automatically, and will add some process practices for inspection, such as the principle of who will modify and submit, for the purpose of going online. A talisman often confirms a lot of information:
Is the number of files published enough?
Is the version of the published file correct?
Is the modified content of the published file the content that you modified, and whether the content submitted by others is mixed in
…
This is not to do an anti-pattern, manual operation is specifically recommended. When
implementing DevOps, it cannot be dogmatic. Fully automatic is good, but fully automatic requires a "safety belt", and this safety belt is often too expensive. The belief in execution is not strong enough and it is often false. Only need to be urgent for the project, this seat belt will not exist, and the project is urgent, the cost is not enough, this is the status quo. Therefore, these standardized processes must be strictly implemented before continuous improvement is achieved. Otherwise, the content of others who have not been fully tested or the debug mode is not closed, etc. will appear, and these can be greatly reduced or even avoided by routine confirmation operations such as version differential confirmation before going online. Simple question.
Summarize this scenario: Version management requires a standardized and perfect process, but also requires strict and faithful execution.
