Steve McConnell, code completion (Code Complete) published the following article on the IEEE Software Magazine in 1996, is already the best practice at the time of others (Best Practices).
We are now doing Daily Build, in this point, in fact, it has been backward for ten years, but we hope to adhere to the DAILY Build, provide guarantees for the normal development of R & D.
The original link is http://www.stevemcconnell.com/bp04.htm
The original text is posted, as well as my own translation, improper, please.
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 various 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 Relative SIMPLE CHECK TO SEE WHETHER The Product" Smokees "When IT Runs.
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 would 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 cancelled. The daily build and smoke test process keeps integration errors small and manageable, and it prevents runaway integration problems.It reduces 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 day, qualy, qualy, qualy, GOOD State, And the You Keep It There. You Simply Don't Allow It To 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 to morale. It almost does not 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 this keeps moralhe.
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 the 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 for several weeks before the next good build. When that happens, you lose virtually 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 is not usable, the build is considered to be broken and fixing it becomes top priority.
Each project sets its own standard for what constitutes "breaking the build." The standard needs to set a quality level that's strict enough to keep showstopper defects out but lenient enough to dis-regard trivial defects, an undue attention to which could paralyze progress.
At a minimum, a "good" build shop
Compile All Files, Libraries, And Other Components Success, 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 should exercise the entire system from end to end. It does not have to be exhaustive, but it should be capable of exposing major problems. The smoke test should be thorough enough that if the build passes, you can Assume That it is stable enough to be tsted 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 a 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 The 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 an explicit part of someone's job. On large projects, it can become a full-time job for more than 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 do not write code quickly enough to add meaningful increments to the system on a daily basis. They should work on a chunk of code and then integrate it when they have a collection of code in a 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 should be the exception, not the rule. Insist that developers who have broken the build stop all other work until they've fixed it. If the 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 Contribute $ 5 to a 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 the build, they get called in to FIX IT Even if their defect is discovered at
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 would 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 of 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. But 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 across 40,000 source files. A complete build took as many as 19 hours on several machines, but 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 are not 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 constructor and smoke test
If you want to create a simple program containing only one source file, you only need to compile, connect the file. If it is a team project group, there are many or even thousands of source files, then the process of creating an executable program becomes more complicated and more time consuming. You must gradually build the program with a wide variety of components. The practice in Microsoft or some software companies is: daily construction and "smoke test". Compiling the completed source program every day, then connects to the executable program, and do "smoke test" to simply check whether the executor is "smoke" when the executor is running.
Benefits
Although this is a very simple process, it is very important:
1, minimize integrated risks
A great risk that the project group may encounter is that the project team members have developed different code according to different system functions, but when these code sets become a system, it may not complete the expected functionality. This risk is depends on this regardless of this incompatibility in the project, which has been found. Since the program interface has changed, or the main part of the system has been redesigned and re-real, the corresponding tired work will be very difficult. Attention time. In extreme cases, integrated errors may return to the project to be canceled. Daily constructors and smoke tests can make this integrated error very small, and it is easy to solve, preventing a lot of integration problems.
2, reduce the risk of low quality products
This risk is to integrate unsuccessful, integrated errors. Do some small smoke tests for integrated code every day, eliminating those basic quality problems in the project. In this way, the system reaches a well-known good condition, and maintaining such systems can prevent the system from gradually deteriorating a large amount of time to investigate the quality problem.
3, simplify the wrong diagnosis
When the system is bundal and test every day, the error that occurs any day in the system can become very fine and easy to investigate. For example, on the 17th system is running normally, the 18th is wrong, then only the code change between the two builds can be checked.
4, can greatly encourage the morale of the project group
Seeing the growing growth of the product, it can greatly encourage the morale of the project team, sometimes even for this product to do. Developers may be excited for the system to display a rectangle. Through daily constructs, the product is made a little daily, ensuring that the project morale continues to rise.
Daily constructor and smoke test
Although this is a simple boring, BUILD is carried out every day, it is tested every day, but there are also some detailed details:
1, insist on every day
The daily constructor is the most important thing to "daily." For example, Jim McCarthy said that daily constructs as the "heartbeat" of the project, there is no "heartbeat", the project is dead (Dynamics of Software Development, Microsoft Press, 1995). Michael Cusumano and Richard W. Selby describes another implicit metaphor that compares daily constructs to "synchronize pulse" (Microsoft Secrets, The Free Press, 1995). The code written by different developers will have a difference in "synchronization" between their "pulse", but there must be such a "synchronous pulse" such that these code can be combined into a whole. When the project team insists that these different "pulse" is combined together, the developers will be greatly eliminated from the overall situation.
Some project groups simplify this process into "once a week". The problem brings to the problem, and after a time of Build fail, it may be retroiled to several weeks to find the reason. If this happens, it has not been able to bring the benefits of Chang Build.
2. Strictly check each time Build
To ensure that each build is successful, it must ensure that the results after Build (also known as build) are functioning normally, if build is not running, then this build is considered unsuccessful, and it should be repaired. Build's work is raised to the highest level of the project group. For how to measure a build, each project group defines some of its own standards, these standards need to set a strict quality level to handle those specially serious defects, but also need a scalability to ignore those slightly deficient defects. Some inappropriate concerns may make the whole process be more difficult.
A good build code should have the following conditions:
● You can successfully compile all files, libraries, and other related components;
● You can successfully link all files, libraries, and other related components;
● There is no high-level failure that makes the system unable to run or run an error;
● Of course, you must pass smoke testing
3, smoke test every day
Smoking tests should be a complete test of the entire system process from input to output. Testing does not have to be an face, but it should be able to find a large problem in the system. The smoking test should be sufficient, and builds that smoke test can be considered to be fully tested, sufficiently stable.
Build without smoking test is not too value. Smoking test is like a sentinel, which prevents product quality deterioration and integration issues, not smoking test, and daily constructs may become a waste of time.
The smoking test must be expanded as the system expansion. Initially, smoke testing may be very simple, such as verify that the system will print "Hello World", with the expansion of the system function, smoke testing needs to be more and more fully. The initial smoke test may only take only a few seconds to perform, gradually, the test may cost 30 minutes, 1 hour, or even longer.
4. Create a special Build group
In many project groups, maintain daily construction, and update the smoking test case, it will cost most of the time of work. Therefore, in some major projects, this work is independently completed by more than one person. For example, in the R & D of Windows NT 3.0, there is a special Build Group composed of four full-time staff (Pascal Zachary, Showstopper!, The Free Press, 1994).
5. Add amendments to Build, if this makes sense
General developers will not frequently increase the actual code to the system every day, usually every few days, after developing a set of code for a feature, and then integrate into the entire system.
6. Provide some punitive measures that lead to Build failure
Many project groups that perform daily constructs will specify some punitive measures to punish the behavior that leads to Build failure. From the beginning, the members of the project team know clearly, the normal implementation of Build is the head of the project group. A failure build is an accident of the project group and cannot be a criterion for the work of the project group. Must adhere to: Leading colleagues who fail to fail, must stop in the hands, first solve the problem of Build failure. If the Build of a project group often fails, it has no meaning to talk about the correctness of Build's correctness.
There is a relaxed punishment measures to highlight the priority of the problem. Some Groups Give Out Lollipops To Each "Sucker" WHO BREAKS The Build. This Developer Ten Office Door Until He Fixes The Problem. Some items group will punish the wrong colleague to wear the goat, or to a project fund Donate 5 dollars.
Some project teams have a bit cruel. Microsoft developers, in some well-known, very important products such as Windows NT, Windows 95, Excel and other products, are required to bring a pager, if your code causes Build fail, even at 3 am Clock, you will also ask you to handle this issue. 7, even if it is also necessary to adhere to daily construction and smoke testing under pressure
When the project progress is getting bigger and larger, the maintenance of daily constructs seems to be a waste of time, but it is exactly the opposite. Under the pressure, the developer throws out some usual provisions, which will use some shortcuts for design and implementation, which is generally not used in an environment where ordinary pressure is small. The REVIEW and unit test of the code may also be careful than usual, and the status of these codes will be much faster than usual.
To prevent the appearance of this situation, the daily construct will insist on the relevant provisions, allowing the project under pressure to keep the project. The code is still changing every day, but the construction process makes this change every day.
Who can get the benefits from the daily constructor? Some developers will protest, because their project is too large, it is not practical to make Build every day. But why is the most complex software project group that can successfully perform a system of daily construction? At the beginning of this article, Windows NT includes 5.6 million lines of code, distributed in 40,000 source program files, and project groups can still construct a daily construction.
