Daily construction and smoke test

Daily construction and smoke testIf you want to create a simple program that only contains one source program file, you only need to compile and connect that file. If a team project team has many or even thousands of source program files, the process of creating an executable program becomes more complex and time-consuming. You must build programs step by step using various components.

In Microsoft or some other software companies, it is customary to construct and perform "smoke tests" on a daily basis ". Compile the completed source program every day, connect and combine the program into executable programs, and perform "smoke test ", it simply checks whether the execution program is "smoke" during running ".

Benefits
Although this is a very simple process, it has very important significance:

1. Minimized integration risks
A major risk for the project team is that project team members develop different codes based on different system functions. However, when these code sets become a system, maybe the system cannot complete the expected functions. The occurrence of this risk depends on how long it takes to detect this incompatibility in the project. Because the program interface has changed, or the main part of the system has been re-designed and re-implemented, troubleshooting can be difficult and time-consuming. In extreme cases, integration errors may cause the project to be canceled. Daily construction and Smoke Testing can make this integration error very small and easy to solve, preventing many integration problems.

2. reduces the risk of low quality products
This risk is associated with integration failures and integration errors. Perform a few smoke tests on the integrated code every day to eliminate the basic quality problems in the project. In this way, the system is in a healthy state. maintaining such a system can prevent the system from gradually deteriorating to the point where it takes a lot of time to troubleshoot quality problems.
3. Simplified error diagnosis

When the system builds and tests every day, the errors that occur on any day of the system can be very detailed for troubleshooting. For example, if the system still runs normally on the 17th and an error occurs on the 18th, you only need to check the code changes between the two builds.

4. It can greatly boost the morale of the project team
Seeing the continuous growth of the product can greatly boost the morale of the project team, sometimes even whatever the product is used. Developers may be excited when the system displays a rectangle. Through daily construction, the product makes a little progress every day to ensure that the morale of the project continues to rise.

Perform daily construction and Smoke Testing
Although this is a simple and boring job, it builds and tests every day, but it also has some worth noting details:

1. Daily persistence
Daily structure, the most important thing is "Daily ". As Jim McCarthy said, the daily structure is regarded as the "Heartbeat" of the project. If there is no "Heartbeat", the project will die (dynamics of software development, Microsoft Press, 1995 ). Michael cusumano and Richard W. Selby describes another implicit metaphor that compares the daily structure to the project's "synchronous pulse" (Microsoft secrets, the Free Press, 1995 ). The code written by Different developers must be synchronized between their "pulses", but such a "Synchronous pulse" must exist ", these codes can be combined into a whole. When the project team insists on combining these different "pulses" every day, developers will be greatly removed from the overall situation.
Some Project Teams simplify this process to "build once a week ". The problem is that after a build failure, it may take several weeks to find the cause. If this happens, the benefits of building often fail.

2. Check every build
To ensure the success of each build, you must ensure that the build results (also known as build) can run normally. If the build cannot run, therefore, this build is considered unsuccessful. At the same time, we should increase the repair work to the highest level of the project team.
Each project team defines its own standards on how to measure a build. These standards need to set a strict quality level to deal with especially serious defects, at the same time, it is also necessary to have certain scalability to ignore those insignificant defects. Some improper concerns may make the whole process fail.
A good build should meet at least the following conditions:
● Successfully compile all files, libraries, and other related components;
● Successfully linking all files, libraries, and other related components;
● There cannot be any high-level faults that make the system unable to run or cause operation errors;
● Of course, the smoke test must be passed

3. Perform a smoke test every day
Smoke testing should be a complete test of the entire system process from input to output. The test does not have to be comprehensive, but it should be able to detect major problems in the system. The smoke test should be sufficient, and the build that passes the smoke test can be considered to be well tested and stable enough.
Build without smoke testing is of little value. Smoke Testing is like a sentinel. in preventing product quality deterioration and integration problems, without smoke testing, the daily construction may become a waste of time.
Smoke Testing must be expanded as the system expands. Initially, smoke testing may be very simple, such as verifying whether the system prints "Hello world". With the expansion of system functions, smoke testing needs to become more and more adequate. The initial smoke test may take only a few seconds. Gradually, the test may take 30 minutes, 1 hour, or even longer.

4. Create a dedicated build team
In many project teams, maintaining daily structures and updating smoke test cases will take most of the time for one person to work. Therefore, in some large projects, this work is independent of more than one person to complete full-time work. For example, in the development of Windows NT 3.0, there is a dedicated build team (Pascal Zachary, showstopper !, The Free Press 1994 ).

5. Add revisions for build. If this makes sense
Generally, developers do not frequently add actual code to the system every day. Generally, after developing a set of code for a function, then integrated into the entire system.

6. prescribe some punitive measures that cause build failure
Many project teams that execute daily construction will prescribe some punitive measures to punish those actions that cause build failure. From the very beginning, the project team members knew that the normal execution of build is the top priority of the project team. A failed build is an accident of the project team and cannot become the working principle of the project team. Stick to it: colleagues who fail to build must stop their work and solve the build failure problem first. If a project team often fails to build, over time, it makes no sense to discuss the correctness of the build.
There are easy punitive measures to highlight the priority of solving the problem. Some groups give out lollipops to each "sucker" who breaks the build. this Developer then has to tape the sucker to his office door until he fixes the problem. some Project Teams will punish colleagues who make mistakes to put on a goat's horn, or donate 5 yuan to a project fund.
Some project teams have a cruel punishment. Microsoft developers are required to take a pager at any time during the development of some well-known and important products such as Windows NT, Windows 95, and excel, if your code causes the build to fail, you will be asked to handle the problem immediately, even at three o'clock a.m.

7. Adhere to daily construction and smoke testing even under pressure
When the project progress is under increasing pressure, it seems a waste of time to maintain the daily structure, but the opposite is true. Under pressure, developers will discard some ordinary regulations and adopt some design and implementation shortcuts, which are generally not used in environments with low stress. Code review and unit test may be more careless than usual, and the status of these codes may change much faster than usual.

To prevent this situation, the daily structure will adhere to relevant regulations to keep projects under pressure on the right track. The code is constantly changing every day, but the construction process makes this change controllable every day.

Who can benefit from the daily construction process? Some developers protest that daily build is meaningless because their projects are too large. But why is the most complex software project team able to successfully execute the system constructed on a daily basis? At the beginning of this article, Windows NT included 5.6 million lines of code and distributed in 40 thousand source program files. The project team can still adhere to the daily structure.