Daily build and smoke test

Steve McConnell, the author of code complete, was in IEEE in 1996
The following article about daily compilation and Smoke Testing is published in the software magazine.
Practices.
We are working on daily in several projects.
Build, in this regard, has actually been behind others for ten years, but we hope to stick to the daily
Build well to ensure normal development.
Original link is http://www.stevemcconnell.com/bp04.htm
I will post the original text and my own translation below. If not, please make an axe.
Daily build and smoke test
If you want to create a simple computer program consisting of only one
File, you merely need to compile and link that one file. On a typical team
Project involving dozens, hundreds, or even thousands of files, however,
The process of creating an executable program becomes more complicated and
Time consuming. You must "build" the program from its varous components.
A common practice at Microsoft and some other shrink-wrap Software
Companies is the "Daily build and smoke test" process. Every file is
Compiled, linked, and combined into an executable program every day, and
The program is then put through a "smoke test," a relatively simple check
To see whether the product "smokes" when it runs.
Benefits. This simple process produces several significant benefits.
It minimizes integration risk. One of the greatest risks that a team
Project faces is that, when the different team members combine or
"Integrate" the code they have been working on separately, the resulting
Composite Code does not work well. Depending on how late in the project
The incompatibility is discovered, debugging might take longer than it
Wocould have if integration had occurred earlier, program interfaces might
Have to be changed, or major parts of the system might have to be
Redesigned and reimplemented. In extreme cases, integration errors have
Caused projects to be canceled. The daily build and smoke test process
Keeps integration errors small and manageable, and it prevents runaway
Integration problems.
IT organizations CES the risk of low quality. related to the risk of unsuccessful or
Problematic integration is the risk of low quality. By minimally
Smoke-testing all the Code daily, quality problems are prevented from
Taking control of the project. You bring the system to a known, good
State, and then you keep it there. You simply don't allow it
Deteriorate to the point where time-consuming quality problems can occur.
It supports easier defect diagnosis. when the product is built and tested
Every day, it's easy to pinpoint why the product is broken on any given
Day. If the product worked on day 17 and is broken on day 18, something
That happened between the two builds broke the product.
It improves morale. Seeing a product work provides an incredible boost
Morale. It almost doesn' t matter what the product does. developers can be
Excited just to see it display a rectangle! With daily builds, a bit more
Of the product works every day, and that keeps morale high.
Using the daily build and smoke test. The idea behind this process is
Simply to build the product and test it every day. Here are some of
Ins and outs of this simple idea.
Build daily. The most fundamental part of the daily build is the "Daily"
Part. As Jim McCarthy says (dynamics of software development, Microsoft
Press, 1995), treat the daily build as the heartbeat of the project. If
There's no heartbeat, the project is dead. A little less metaphorically,
Michael cusumano and Richard W. Selby describe the daily build as the sync
Pulse of a project (Microsoft secrets, the Free Press, 1995). Different
Developers 'Code is allowed to get a little out of sync between these
Pulses, but every time there's a sync pulse, the Code has to come back
Into alignment. When you insist on keeping the pulses close together, you
Prevent developers from getting out of sync entirely.
Some organizations build every week, rather than every day. The problem
With this is that if the build is broken one week, you might go
Several weeks before the next good build. When that happens, you lose
Ally all of the benefit of frequent builds.
Check for broken builds. For the daily-build process to work, the software
That's built has to work. If the software isn't usable, the build is
Considered to be broken and fixing it becomes top priority.
Each project sets its own standard for what constitutes "Breaking
Build. "The standard needs to set a quality level that's strict enough
Keep showstopper defects out but lenient enough to dis-regard trivial
Defects, an undue attention to which cocould paralyze progress.
At a minimum, a "good" build shocould
Compile all files, libraries, and other components successfully;
Link all files, libraries, and other components successfully;
Not contain any showstopper bugs that prevent the program from being
Launched or that make it hazardous to operate; and
Pass the smoke test.
Smoke test daily. The smoke test shocould exercise the entire system from
End to end. It does not have to be exhaustive, but it shocould be capable
Exposing major problems. The smoke test shocould be thorough enough that if
The build passes, you can assume that it is stable enough to be tested
More thoroughly.
The daily build has little value without the smoke test. The smoke test is
The sentry that guards against deteriorating product quality and creeping
Integration problems. Without it, the daily build becomes just
Time-wasting exercise in ensuring that you have a clean compile every day.
The smoke test must evolve as the system evolves. At first, the smoke test
Will probably test something simple, such as whether the system can say,
"Hello, world." As the system develops, the smoke test will become more
Thorough. The first test might take a matter of seconds to run; as
System grows, the smoke test can grow to 30 minutes, an hour, or more.
Establish a build group. On most projects, tending the daily build and
Keeping the smoke test up to date becomes a big enough task to be
Explicit part of someone's job. on large projects, it can become
Full-time job for more than one person. on Windows NT 3.0, for example,
There were four full-time people in the build group (Pascal Zachary,
Showstopper !, The Free Press 1994 ).
Add revisions to the build only when it makes sense to do so. Individual
Developers usually don't write code quickly enough to add meaningful
Increments to the system on a daily basis. They shocould work on a chunk
Code and then integrate it when they have a collection of code in
Consistent state-usually once every few days.
Create a penalty for breaking the build. Most groups that use daily builds
Create a penalty for breaking the build. make it clear from the beginning
That keeping the build healthy is the project's top priority. A broken
Build shocould be the exception, not the rule. Insist that developers who
Have broken the build stop all other work until they 've fixed it. If
Build is broken too often, it's hard to take seriously the job of not
Breaking the build.
A light-hearted penalty can help to emphasize this priority. 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.
Other groups have guilty developers wear goat horns or contriers $5 to
Morale fund.
Some projects establish a penalty with more bite. Microsoft developers on
High-profile projects such as Windows NT, Windows 95, and Excel have taken
To wearing beepers in the late stages of their projects. If they break
Build, they get called in to fix it even if their defect is discovered
3 a.m.
Build and smoke even under pressure. When schedule pressure becomes
Intense, the work required to maintain the daily build can seem like
Extravagant overhead. The opposite is true. under stress, developers lose
Some of their discipline. They feel pressure to take design and
Implementation shortcuts that they wocould not take under less stressful
Circumstances. They review and unit-test their own code less carefully
Than usual. The Code tends toward a state of entropy more quickly than it
Does during less stressful times.
Against this backdrop, daily builds enforce discipline and keep
Pressure-cooker projects on track. The Code still tends toward a state
Entropy, but the build process brings that tendency to heel every day.
Who can benefit from this process? Some developers protest that it is
Impractical to build every day because their projects are too large.
What was perhaps the most complex software project in recent history used
Daily builds successfully. By the time it was released, Microsoft Windows
NT 3.0 consisted of 5.6 million lines of code spread internal SS 40,000 Source
Files. A complete build took as ready as 19 hours on several machines,
The NT development team still managed to build every day (Zachary, 1994 ).
Far from being a nuisance, the NT team attributed much of its success on
That huge project to their daily builds. Those of us who work on projects
Of less staggering proportions will have a hard time explaining why we
Aren't also reaping the benefits of this practice.
Editor: Steve McConnell, Construx software, 11820 Northup way # e200,
Bellevue, WA 98005.
E-mail: steve.mcconnell@construx.com-www:
Http://www.construx.com/stevemcc/
Daily construction and smoke test
If 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 ", to check whether the execution program is "smoke" at runtime ".
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 ". For example, Jim
McCarthy said that the daily structure is regarded as the "Heartbeat" of the project. If there is no "Heartbeat", the project will die.
Of software development, Microsoft Press, 1995 ). Michael cusumano and
Richard W.
Selby describes another implicit metaphor, comparing the daily structure to the project's "synchronous pulse" (Microsoft
Secret, The Free Press, 1995 ).
The code written by Different developers will certainly have a "synchronization" difference between their "pulse", 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, in some well-known and important products such as Windows
NT, Windows
95. Excel and other products are required to carry a pager at any time during later development. If your code causes build failure, you will be asked to handle the problem immediately even at three o'clock AM.
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? Windows
NT contains 5.6 million lines of code and is distributed in 40 thousand source program files. The project team can still adhere to the daily structure.