1. Definition of continuous integration
Master Martin Fowler defines continuous integration as follows: Continuous integration is a software development practice, that is, team development members often integrate their work. Usually, each member integrates at least once a day, which means that integration may occur multiple times a day.
Continuous integration does not eliminate bugs, but makes them very easy to find and correct.
According to the actual understanding of the project, "continuous" in continuous integration refers to uninterrupted; "integration" can be divided into broad and narrow sense, broad integration Refers to the integration of various software processes, including development, deployment, testing, etc. In a narrow sense, integration is the integration between code and code, so as to ensure that the code merges without conflict.
Each integration is verified through automated builds (including compilation, release, and automated testing), so that integration errors can be found as soon as possible. Many teams have found that this process can greatly reduce code integration problems, allowing the team to develop cohesive faster software.
Please note that continuous integration is not equal to continuous compilation.
2. Problems in the current software development process
Before continuous integration was applied, the traditional development model looked like this:
At the beginning of the project, the modules are divided and assigned to the corresponding developers;
After a developer develops a module, he conducts unit testing;
After all the modules are developed, the project manager will integrate all the codes;
The integrated project is deployed to the test server by the project manager and handed over to the tester for integration testing;
If a bug occurs during the test, record the problem in the bug list;
The project manager assigns the Bug to the corresponding responsible person for modification;
After the modification is completed, the project manager integrates the project again and deploys it to the test server;
Testers perform regression testing in the next integration test;
Deploy to the production environment after passing;
If the test fails, repeat the above work of "assign bug -> modify bug -> integrate code -> deploy to test server -> integration test".
The following problems may arise during this process:
Bugs are always discovered at the end.
With the development of software technology, the scale of software is also expanding, and software requirements are becoming more and more complex. Software can no longer be developed simply by dividing modules. It often requires mutual cooperation within the project. There is a certain dependency between them, so the bugs that existed in the early stage are often not discovered until the final integration.
The later in the project, the more difficult it is to solve the problem.
Many developers need to spend a lot of time in the integration stage to find the root of the bug. Coupled with the complexity of the software, it is difficult to locate the root of the problem. And we all know that the longer the interval, The cost of bug fixes is higher, because even the developers themselves forget what kind of code they wrote in the first place, so they have to read and understand the code from scratch.
The timing of software delivery cannot be guaranteed
precisely because we cannot fix bugs in time, or fail to fix bugs at an early stage, which prolongs the entire cycle of bug fixes. In any case, it is impossible for us to deliver software that we know to have bugs to client.
Moreover, a lot of work was generated that was not estimated in the early stage-developers had to spend a lot of time on finding bugs; testers were constantly required to perform regression tests; project managers had to be tired of integrating the damn code , Deploy these repetitive tasks-eventually lead to the lengthening of the entire project cycle, and the delivery time is delayed.
Programs often need to change
certain items, and programs often need to be changed. Since product managers often communicate with customers, the actual software is often the best prototype, so software will be used as a prototype as a tool for communicating with customers. Of course, What customers hope most is of course that the customer's ideas can be reflected on the prototype immediately, which will cause the program to be frequently modified. Then it means "assign bug -> modify bug -> integrate code -> deploy to the test server- >Integration testing" work has exploded invisibly.
Ineffective waiting increases.
It is possible that the developer is waiting to integrate other people's modules; the tester is waiting for the developer to fix the bug; the product manager is waiting for the new version to go online so that he can demonstrate it to the customer; the project manager is waiting for others to submit the code. No matter what , waiting means inefficiency.
Low user satisfaction
The users here are in a broad sense, and can refer to the final customer, product manager, company leader, tester, or even the developer himself. If you think about it, the project that was originally completed in three months It has been stretched to nine months or even a year, can users be satisfied! Product managers and company leaders often need to use the project as a prototype for demonstration, and the result tells me that there are still many bugs that have not been resolved just before the demonstration, and the project cannot be started and cannot be accessed , this is so embarrassing.
3. What constitutes "sustained"
There is no clear definition of how many times a day needs to be integrated. Generally, a certain frequency is set according to the actual needs of your project, ranging from a few times to dozens of times. It can be set to trigger according to code changes Integration, or set a fixed time period to integrate, or manually click the integration button to "one-click integration".
Continuous Integration Workflow
When a code change is initiated, the developer fetches a copy of the current codebase from the codebase (like SVN, Git, etc.).
As other developers commit changed code to the codebase, this copy will gradually stop reflecting the code in the codebase. The longer the code branch remains checked out, the more integration conflicts when the developer branch is reintegrated into the mainline and the greater the risk of failure.
When developers commit code to the codebase, they must first update their code to reflect the latest changes in the codebase.
When the repository differs from the developer's copy, they must take the time to resolve the conflict first.
4. The benefits of continuous integration
Repetitive labor is liberated
Automated deployment work can liberate repetitive labor such as integration, testing, and deployment, and the frequency of machine integration can obviously be much higher than that of manual work.
Fix problems faster.
Since continuous integration can acquire changes earlier and enter testing earlier, problems can be found earlier, and the cost of solving problems is significantly reduced.
Faster delivery of results
Early integration and early testing reduce the chances of defects being carried over to deployment. In some cases, finding bugs earlier also reduces the effort required to resolve them.
If the integration server finds an error in the process of building the code, it can promptly send an email or text message to the developer for repair.
If the integration server finds that the current version is unavailable during the deployment process, the integration server will roll back the deployment to the previous version. In this way, there will always be an available version on the server.
Reduce manual errors
One of the biggest differences between humans and machines is that in repetitive actions, humans are prone to make mistakes, while the probability of machines making mistakes is almost zero. Therefore, after we build the integration server, the rest will be handed over to the integration Let the server take care of it.
Reduced waiting time
Continuous integration shortens the time from development, integration, testing, and deployment, thereby shortening the waiting time that can occur in the middle. Continuous integration means that development, integration, testing, and deployment can also continue.
Higher product quality
integration servers often provide Code review, code quality inspection and other functions. It will mark irregularities or errors in the code, and can also set emails, SMS, etc. to alert. Developers can also continue to use Code review Improve programming skills.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it away directly: [Collect at the end of the article]
[The following is the most complete software test engineer learning knowledge architecture system diagram + full set of materials I compiled in 2023]
1. From entry to mastery of Python programming
2. Interface automation project actual combat
3. Actual Combat of Web Automation Project
4. Actual Combat of App Automation Project
5. Resume of first-tier manufacturers
6. Test and develop DevOps system
7. Commonly used automated testing tools
Eight, JMeter performance test
9. Summary (little surprise at the end)
life is long so add oil. Every effort will not be let down, as long as you persevere, there will be rewards in the end. Cherish your time and pursue your dreams. Don't forget the original intention, forge ahead. Your future is in your hands!
Life is short, time is precious, we cannot predict what will happen in the future, but we can grasp the present moment. Cherish every day and work hard to make yourself stronger and better. Firm belief, persistent pursuit, success will eventually belong to you!
Only by constantly challenging yourself can you constantly surpass yourself. Persist in pursuing your dreams and move forward bravely, and you will find that the process of struggle is so beautiful and worthwhile. Believe in yourself, you can do it!