Advanced software engineering daily build [1]: benefits and benefits

In the previous post "Daily build of advanced software engineering [0]: Overview", we mentioned that daily build is a great means of software engineering. This post is about how cool it is. To help everyone better understand the past, let me talk about the past few years.
At the end of the last century, I worked in a small company and participated in the development of a C ++ project. At that time, the company's process was: developers wrote the code, compiled it themselves, and threw it to the testers for testing. If the testers found the bug, they verbally notified the developers to change it. The developers modified the bug, and then test it for the tester. ......

★Case 1 (chaotic development)
One day, the development team's chief found programmer.
> Leader: Have you completed the XX function?
> Programmer A: It's early!
> Leader: How does tester Jia never see the XX function?
> Programmer A: No! Let me go.
Several minutes later, programmer Jia came back.
> Programmer A: Sorry, I only sent the compiled EXE to tester B and forgot to send it to tester.
> Small leaders :! @ # $ % ^ & * (15 words are omitted here)

★Case 2 (test chaos)
I just got to work on the other day.
> Tester A: How does one crash today's XX. EXE?
> Tester B: Are there any? I am doing well!
> Tester A: Hell! Let me ask about development.
After several minutes of inquiry, I learned that xx. EXE is the responsibility of programmer C, so I found the programmer C.
> Tester A: Why does your XX. EXE crash when it runs?
> Programmer C: is this the case ?! Let me look at your environment.
Programmer C studied n minutes later on tester A's machine.
> Programmer C: You are a pig brain. You have not updated XXX. dll, which wastes me so long!
> Tester A: You are pig brain! How do I know that xx. exe will use XXX. dll?
Then the two began to scold ......

★Case 3 (integration chaos)
When the project is delivered, developers are busy modifying bugs, testers are busy re-testing bugs, and no one has prepared the installation package, so the installation package is created until the day before the project delivery. Creating the installation package itself is fast and will be done in half a day. But ......
> Leader: should the installation package be ready?
> Tester C: Well, this is... it seems that the installed software cannot run and crashes.
> Little leaders: Even God! What are you waiting for? Go and check the reason !!! You are not allowed to go home today !!!
Then the development and testing work together. After painstaking efforts, at midnight, we finally found that a DLL was a debug version ......
Some may ask: Why can't I find this problem during normal tests? Because the team usually uses the debug version to facilitate assert assertions. On the day of installation package
When compiling the release version, a guy missed it, so he mixed a debug version of DLL in it. When the running program is installed, the dynamic loading of the DLL fails, so the program crashes.
Bird.

The situations I mentioned above have been staged in many companies until now. Why can we fix the above problems during daily building? Let me explain in detail:

★For "chaotic development"
For daily building processes, developers only need to be responsible for submitting code to the code base. You do not need to provide compiled binary files to testers one by one. Therefore, the problem in Case 1 (leaked to the test file) can be solved.

★For "test chaos"
In the development phase, because the programs obtained by the test are automatically compiled, it ensures that all testers receive a unified running program, in addition, this program corresponds to the latest code in the code library.
In the test phase, after fixing a bug, each developer must submit the changed code to the code base so that the tester can obtain the binary program that has changed the bug. If a developer changes the bug but does not submit the code, the tester sees that his bug has not been changed, so his bug will not be closed.
Therefore, Case 2 does not occur.

★For "integration chaos"
For daily building, an installation package (or an ISO image of the installation disc) is generated every day ). That is to say, every day from the day when the project was developed (this is the legendaryContinuous Integration). Therefore, the integration issue will be exposed at the beginning, instead of waiting for the project to be late.

In fact, in addition to the above three points (I think these three points are more important), there are many other advantages that everyone can think about on their own. In the next post, I will introduce the daily preparations for building.

Http://program-think.blogspot.com/2009/02/daily-build-1-advantage.html