Daily Build is your friend
Author: Joel Spolsky Translation: Chen Bin January 27, 2001
In 1982, my home purchase IBM's PC (the earliest personal computer produced by IBM is a ancestral ancestor of modern popular standardized personal computers). Our home may be one of the first few families with this PC in Israel. At that time, we ran to the warehouse waiting for the computer from the port. In fact, I persuaded my dad to buy a personal computer with a full set of equipment (the translator pressed: Some very cheap subsidiary equipment, that is very expensive), including two floppy drives, 128K Memory, a needle-style printer (used to quickly print a draft) and a brothers of the brothers that run the gun to scan the sound (the translator is DAISY WHEEL Printer, it is a printer that has been eliminated. The principle is similar to the old-fashioned mechanical typewriter, which can produce a clear English character). The affiliated software is also very complete, PC-DOS 1.0 (earliest PC operating system), $ 75 reference book, including BIOS's full source code. A assembly language compiler, a great IBM monochrome display that displays 80 columns wide characters and supports lowercase letters. The whole set of configuration has spent $ 10,000. These money include the ridiculous import tax of Israel. Oh, then my family can really spend money!
Because "everyone" knows that Basic is a language that is played with children, use this language to write out non-structural spam, then your brain will also become a cheese produced by Camembert by this language. (Camembert Cheese, a cheese, solid, cake, gray, a fist size). So we spent $ 600 and bought an IBM's PASCAL language development package, and it takes 3 soft plates to be installed. The PASCAL compiler runs the first floppy disk, and the second floppy disk, and the Pascal linker requires a third floppy disk. I wrote a simple output "Hello, the World" program and then compile this program with a total of 8 minutes.
Well, 8 minutes seem too long. I wrote a scriptor to self-move the entire process, which reduced the time to 7.5 minutes. This is better. But I want to design a program that can play Oosage. (Translator is pressed by Othello, a chess game, rule see http://www.ugateways.com/bof4.html) This game can always touch me. I have to spend a lot of time waiting for the compiler to compile my program. "That's it," a professional programmer told me, "We usually put on the SIT-UP Board in the office (the translator is pressed: a fitness equipment, you can do sit-ups or oxygen exercises above) When the Pascal compiler starts running, we start working. I have programmed a few months, my body should not be too awkward! "
Later, one day, Danish programmers wrote a very spiritual program called Comss Pascal. Philippe Kahn (founder of Borland) bought it, renamed Borland Turbo Pascal. Turbo Pascal is so unimaginable because it can do all things that IBM Pascal can do, but as long as 33K memory. Moreover, an editor is also available. This is not the best. The best thing is to compile a small program just less than one second. This is like a company that you have never heard of the company has produced the cloning version of the General Company Buick sedan, which can take one million miles per hour, but only a drop of gasoline. A small ants drink this gasoline will not die. Suddenly, my programming efficiency has become much higher.
At that time, I began to understand the concept of "REP loop". Rep is an abbreviation for "Read, Eval, Print". This concept explains the basic principle of LISP (a programming language, used for artificial intelligence) interpreter: It "Read" your input, calculate your input results, print results. Here is given: I entered some things, the LISP interpreter is calculated, and then the result is output.
On a slightly large scale, when you write the code, you are also in a REP loop macro version, this loop is "encoding - compile - test". You write the code, compile the code into an executable file, then test it, look at how to run.
The key is that when you write a program, your work process is looped. The shorter the time spent in a loop, the higher your productivity, and of course the shortest time will not be less than the time of the compiler. This is why programmers always have a truly fast hardware and compiler developers always constantly make their compilers run faster. The reason for the faster formal pure computer scientific perspective. Visual Basic's way is that when you enter the code, it starts to perform code syntax resolution, so that the program interprets the running speed. Visual C approach is incremental compilation (Incremental Compiles), precompiled headers, and incremental links.
But a large team has multiple developers and testers. You have encountered the same loop, and you may have more documents to write (but this is just a draft, God!). A tester discovered BUG and reported, and the developer repaired this bug. So how long does the tester get a corrected code? In some software development agencies, such a report-correction-re-test loop may take several worships. If a cycle takes so long, it usually means that the agency productivity is low. I want to make the entire development process to be more smooth, you must find a way to make the report-corrected-reort-fixest loop time less.
A good way is Daily Builds. Daily construction means automatically, every day, completely build the entire code tree, (Translator Press: "Code Tree", the original is Source Tree, meaning the directory, subdirectories, file of the entire project source code, the location of the file is as possible Fixed in advance, in the development process, the relative positions between each file will not be confused. The source code tree is a project all organized code files. Usually the code tree should use version control software management Get up. Although this concept is very basic, according to my observation, there is still a software company in this regard, so it is necessary to explain it.) Automatically - because you set the code every day in a fixed time. Use cron in a UNIX environment, use the Task Schedule under Windows.
Every day - or more frequent. Of course, the number of times built daily, the better. However, sometimes the number of builds is still sufficient, the reasons and version control are related, and I will talk about it.
Complete - very likely that your code has multiple versions. Multi-language versions, multi-operating system versions, or high-end low-end versions. Daily Build needs to build all these versions. And each file needs to be compiled from the head instead of using the imperfect incremental compilation function of the compiler.
The following is the benefits of daily build (Daily Build):
When a bug is corrected, the tester can quickly get the latest revised version to start retest to verify that the bug is really fixed. Developers can more determine that their modifications they do for code will not undermine any of the 1024 operating systems. Verify this does not need to install OS / 2 on their machines (IBM's PC operating system). Those developers who will modify the code import (Check IN) version control server know that their modifications imported to a module will not dragging the hind legs of the developers. The dragging leg means that the programmer developing other modules uses this modified module, out of the problem, so their own module has no way to develop. Every day construct will not be dragged behind. If a development team is compared to a PC, a programmer in the team causing other people to develop other modules, which is equivalent to the Blu screen. When a programmer is forgotten to import him (she) new file into the Repository (finger the code tree on the version control server), "Blue Screen" during this development process often occurs. Because there is this file on this programmer's own computer, he has no problem with this program. However, other programmers are derived from the version control server. Due to this file on the server, they have encountered a link error (Link Error) and cannot work. External teams (such as market sales departments, some customers who conduct Beta test) can get a relatively stable version, which is more favorable for their work. If you use a binary to be built (such as an executable, a DLL, etc.), then you find a very strange, you can't resolve the bug, you can search for these files ( Binary Search to determine when this bug has appeared for the first time. If you have a complete version control for the code, you can also find that who is the introduction of the code (Check IN) caused this bug. When the developer fixes an error reported by the tester, if the tester reports the built-in version of the found error, the developer can test whether the bug is really fixed in that version. (Translator Press: The tester report has a bug, just reporting an error symptom, and a number of errors may have multiple, each reason may be in different modules. The method in the foregoing is to avoid only fixing only one One reason in the module, the other modules, due to the changing, covering rather than repairing the specific steps of daily builds. You need to build a daily build server with the fastest computer. Write a script, you can automatically export (check out) complete code from the version control server, (do you have any version control, isn't it?), Then build the code from the beginning, build all the versions. If you have a installation package, you have to automatically run in the script. All things that will be sold to the end user must be included during the construction process. Put the built version in its respective directory, the same version constructed at different times should also be organized according to the date, do not cover each other. Run such scripts every day.
The most critical is that all these steps should be completed by script, from the check out code to the user download of the final product in the network (of course, the product is placed on a test server). It is the only way to ensure that any records in the development process is recorded by document rather than by a person's brain. Otherwise, you will encounter such a situation, the product needs to be released, but only Shaniqua knows how to pack the product, but he just hit by the bus. In Juno, one of the companies worked in this article), you must make a daily construction, your only thing to learn something is a shortcut to double-click the daily build server desktop. If you find a small bug on the day of the issuer, there is no problem. Fix it, then re-run the daily build script, now you can release the programs in An An. Of course, the law of gold is a daily build script should be to do all things from the beginning, follow this law, there will be no problem. Set the warning parameters of your compiler to the maximum (in Microsoft's VC is -w4; -wall is -wall), when you encounter any of the minor warnings, you should stop. If the daily construction fails, the work of the entire development team will not work. The urgent urgency is to find out the reason, so that the daily construction can be successfully carried out. One day maybe you will run several daily build scripts a day. Once the daily construction fails, you should automatically use the email to inform the entire team. Extracting the appropriate part of the error log and is not very difficult in the text of the Email. Daily build scripts can also be organized into an HTML file to automatically publish the current status report to a web server that you can access, so that the tester knows that the version is successful. When I worked in Microsoft's Excel team, one of our effective ways is that who leads to Daily Build failure, he (she) has to be responsible for watching the daily construction of the day (translator Press: Microsoft usually every The day build is in a half night), until another person caught the built failure to replace him (she). This can certainly make each developer carefully do not build because of the error of your code, more importantly, everyone in the team can learn the DAILY BUILD. If your team works in the same time zone, daily build is a good idea at daily build. Each programmer is imported before lunch, so when the programmer is eating, the building system is working. When the programmer has finished eating, if every day is built, all the people are all, they can find the reason for failure as soon as possible. When building a system works, no one will worry about the CHECK IN code that hinders yourself. If your team works at two time zones, planning daily builds to make a time zone work does not affect the work of another time zone. In Juno, New York programmakers import (Check IN) to the version control server at 7:00 pm. If their introduction leads to the failure, the programmer of Hyderabad (translator according to: Indian Technology Heavy Town) is almost unable to carry out after 8:00 in New York City. We don't have any problems before the programmer in the two places every day. Further reading:
Some discussions about daily build tools are important for daily construction, which is one of the 12 steps of high quality code. Windows NT Team G. Pascal Zachaless About Microsoft Windows NT teams have some interesting things in a weekly built. Super Star (Translator Press: Original to showstopper, refers to special people who are loved, outstanding people or things). Steve McConnell (Translator Press: Famous Software Engineering Writers, WIN2000 Development Group General, "Writing Solid "Debugging the development process" has Chinese translation.) Writing article About Daily Build is here. This article is published in English, entitled Daily Builds Are Your Friend
