The first part: http://leogao-java.iteye.com/blog/2155125
The former discussed various troublesome things in the actual project operation, and I believe that those with practical project experience will also feel it. I won't say more stories of torture here, because there are too many! The key is how we solve them!
The purpose of software development is very clear, it is to meet the needs of customers or end users, but if a software company needs to make money, it must control costs and increase its value. On the other hand, customers want to buy the best software and services at the least cost. , so ultimately the development team is required to deliver high-quality valuable software in an efficient, fast and reliable way!
In fact, many organizations have worked hard for this, but they have all failed, just like the torture stories mentioned by the former, but there are also many successful ones. After careful study of successful cases, it is found that the failed projects are basically based on beauty. The so-called XX methodology + PM's rule of man policy is carried out, and the successful cases are carried out under the legal system of the implementation mechanism of a certain project, and the role of PM is to focus on solving the aspects that need the rule of man!
What is this implementation mechanism? It's three o'clock:
1) Automation: If the build, test, deploy and release process is not automated, then it is difficult to repeat it, because it is done manually each time, and each time may produce differences in results, and it is not known which time it is. The most accurate! Doing it manually will introduce unpredictable errors more or less every time, and once a person leaves, the recipient has to do it in their own way (rule of man), and it is conceivable how chaotic and confusing this method will be. Uncontrollable! If this process is fully automated, there will be no mistakes, eliminating the human factor, and once a problem occurs, the automated pipeline will immediately report the problem, because we can execute the entire process with one click, no matter what the environment is.
2) Do it frequently: If you can do frequent releases, then the difference between each version will be small, which greatly reduces the risk of release, because once a problem occurs, you can quickly roll back to the previous one For a good version, every time the code is submitted, it will automatically stimulate the process of automatic construction, testing, deployment and release, and give feedback in time. The system will evolve in small steps. The transparency of the development status of the system is enhanced and the degree of visualization is high. The ability to control the development process is high, and the problem can be corrected in time.
The above methods are not easy to do. If it were that easy, all the organizations would be complete! This is because automation requires not only technical guarantees, but also institutional guarantees. The hardest and most difficult thing is that everyone in the team needs to understand its meaning and specific practices (technologies are easy to do, personnel are not easy to do). Automation is the basis of frequent work, and if it can be done frequently, the feedback report of the automation system will be produced quickly, and the feedback will be fast, and we will be able to fix the problem in time, then the progress will be under control!
3) Do a good job of test scripts and test-driven development, which can solve the problems of test coverage and rapid feedback, and find the problems of realizing business functions as soon as possible (the specific articles will be mentioned later)
Below I use a diagram to illustrate the meaning of automation. Because automation is misunderstood by many people, some misunderstandings must be dispelled first. The misunderstanding is that it is a technical means, but in fact it is a practical process!
To put it bluntly, it is to implement an automation of the whole process from source code submission to deployment. If automation can be realized, then anyone can simply
To implement deployment and testing, there is no need for a team to be responsible. In addition, the repetitive manual work in the past has been eliminated, and regression testing has become an unbelievably simple thing, so it can support frequent submissions and rapid feedback, such as getting rapid feedback If you can fix the problem in a short time, evolve the system step by step, and have full control over the system, then the confidence in the operation of the system will become stronger and stronger! And we define that the deployment configuration scripts for all environments are the same and consistent, because you have frequently submitted = "frequently executed automated deployment scripts during the development process, you can gradually optimize the deployment scripts, and when the real release, you It's been tested thousands of times, isn't it more revolutionary than the traditional way!
1) The entire automation process is divided into several stages (each stage corresponds to a server environment, which will be explained later):
Submission stage = "Acceptance stage = "Functional and non-functional testing stage (UAT + non-functional testing) = "Deployment stage
Why is it divided into stages? Because a software that needs to be developed must meet the requirements or interests of many stakeholders, the submission stage is
The verification technology is used to test the system. The verification stage is still verified from a technical perspective, but the focus is on the integration between components. The UAT stage is the verification
Whether the developed software fully meets the business needs, rather than the functional testing stage, mainly tests some implicit requirements (such as capacity, security and performance)
can, etc.), the production environment deployment stage, it focuses on verifying whether it is available on the production environment.
2) Each stage or several stages corresponds to an environment:
The submission phase corresponds to the development and testing environment
The acceptance stage corresponds to the Alpha test environment
UAT and non-functional testing phases correspond to Beta environments
The deployment phase corresponds to the production environment
For the best design, if conditions permit, the configuration of the development test environment, alpha test environment, and beta environment should preferably be similar to the production environment.
It is even better to be consistent, because only when it is close or consistent, can various hidden problems be discovered as much as possible in the development stage, such as
environment-related issues. Then more problems are discovered in the early stage, and the more we think about it in the later stage, the fewer problems there are!
3) Put everything (except binary packages) into a version control system, that's the basics! (The following documents will be discussed in detail gradually), separate the binary package formed in the submission stage from the specific environment configuration file, the binary package and the environment are independent, and the configuration information is placed in the version control system (why do this, later There will be a detailed discussion), and finally, it must be ensured that the binary package must be the same throughout the entire automation process! If these are made, the problems caused by configuration confusion can basically be eliminated (discussed in detail in the following chapters).
4) If the coverage of the test scripts is not enough, the potential problems are likely to be filtered out. When it comes to the deployment stage, if there is a problem, it will take a lot of time to correct it! There are two ways to ensure test coverage: coverage analysis tools or the use of test-driven development methods to ensure coverage.
5) Be disciplined! Without discipline, the automated processes 1-4 are useless, because if an automated integration tool finds a test failed and issues feedback, the developer would just leave it to the testing phase as was traditionally done To correct, because the time interval is longer, the modification cost is higher, which is almost the same as the traditional method. The more this is the case, the controllability of the project is getting worse and worse, until it is uncontrollable, so whoever has to build the bug will be Discipline to be corrected in time.
For 1-5, frequent submissions = "testing =" feedback and fixes, so that the project can move forward quickly, and everything is under control (it takes a lot of effort to get to this point, which will be discussed in later chapters), is it possible to do it in time? Where can the development tasks be completed within the interval? Quality, time and cost are all in the desired balance!
6) The development and testing environment requires Mock Server, because a system under development may depend on external systems, and these systems may also be under development. If the dependent systems are not available, how can we confirm that our own software has no problems, so we need Mock Server to simulate the services provided by the external dependent system, so that each system does not have to wait for the progress of each other, and each develops its own. (The topic about Mock Server will be discussed later), because the waiting time caused by the dependencies of each system is greatly reduced, and the cost is also greatly reduced!
7) The most important thing is to pull in customer representatives (Product Owner), testers, deployers, and operation and maintenance personnel at the very beginning of the project. They must be pulled in. It makes sense to bring them in, that is, to optimize all the processes together. For example, when making test scripts, the testers are the most professional, because we are constantly deploying in various environments, and we are constantly participating in the optimization from the very beginning of the project. During the development of the deployment script, due to the continuous rapid submission and feedback, the operation and maintenance personnel can participate in the optimization of the operation and maintenance scheme on the optimized system as soon as possible, and due to the rapid feedback, the customer representative can also correct the problem in the shortest time. , that is to say, if all aspects of the project are close to the quality goals at the later stage of the project, everyone will be confident in the release! In addition, there will be no disputes caused by communication problems, cooperation problems and the emergence of various problems in the later period. The knowledge transfer within the organization is also transparent, and the communication cost is greatly reduced!
The next article will continue to discuss the details of automation gradually, and gradually enter the chapter on technical implementation means.
Reference: http://www.continuousdelivery.info/