content:
What is the effective management of software development Why do I need a Japanese build day build sample day built value selection day build or the basic tool day construct of the basic tool day constructed by the basic tool day constructed by the continuous integration day, further understand the author's evaluation of this article
related information:
Software Quality Road (1): Software Quality Framework Software Quality Road (3): Test Drive Development Software Quality Road (4): Establishing Core Framework Software Quality Road (5): Assembly Large Software Architecture
In the Linux area:
Tutorial Tools & Product Codes and Component Project Articles
Lin Xing (IAMLINX@21cn.com) March 2004
Day build is a very basic software development practice, unfortunately, there is no much organization truly realize its benefits. Through the discussion of this chapter, you can know that the day builds the meaning of software development, understanding the basic situation of day builds and how to build day.
What is the effective management of software development in a national bank, what is the correctness of complex capital liquidation? Every day, the outlets in each place need to ensure the balance of accounts, funds, and tickets; these outlets have been summarized, and the balance of account balances must be guaranteed at each collection point, and finally complete a bank of a bank. Settlement. Every day, it is like a designed machine that works. Not only the bank is like this, not only one of the companies. A small grocery boss, also knows the account per day, see today is a loss. These behaviors have become part of the work and even become a habit. Software development is also the same. You must find a way to measure every day, to ensure that every day's work can be effectively continued, and ultimately turn software development into an intrinsic process. This method is called the day construction or continuous integration. Why do I need a day building day build and sustained integration, and those familiar with open source should know Nightly Build. And continuous integration of this word comes from the XP method, its frequency can build higher than the day, can be integrated in a few minutes, so it is called. In this article, we only discuss day builds, and it is very easy to build daily build to continuous integration. In fact, there is no provision for continuous integration to be done in minutes. If you are willing, it is also possible to continuous integration in one week. The purpose of this is to construct or continuous integration techniques for better use: at least in units, the higher the frequency, the better the effect. So, what is the day building? The process of our traditional development software is generally the same, understanding the field problems, then assigns tasks, which are responsible for different software components. After the development is completed, the components of each person are integrated to form a complete software. This idea doesn't seem to have any problems, but there are a lot of problems in practice. First of all, this way is suitable for the case where the developers have no intersection, which is very common, but now, with the expansion of the software scale, the division of labor cooperation is deepened, the inter-inter-inter-inter-inter-inter-developer is getting higher and higher. This clear duty has become more and more difficult. Second, when the software is integrated, there will be a variety of problems, but it is difficult to find out where the problem is. The public is reasonable, and his wife said that his wife is reasonable. Everyone's code has no problem, and a large number of problems will occur together. So the day construct will convert usually a rare integrated work into frequent work, so that it is a simple job that is just like a nightmare. This is also very easy to understand, if integrated work a few months, who can remember the details of a few months? But if you integrate the sky, even in minutes, it is easy to eliminate BUG. The sample construction example is now 17:00 in the afternoon, and it is time to build a day. The three programs in the team have submitted their source code and test code to a machine named Zeus, which will be responsible for the construction of the code. Before they submitted the code, they have passed the build on this machine and complete the test. The rest of the program seems to have encountered trouble, his code has some problems, and he now needs to write more tests to improve the test network. It seems that the time is too late, he can only make it in tomorrow. Since his code does not have dependence with others, there is no relationship after late submission, but he must carefully detect the latest source code to the local, with the help of version control tools, this Work is very simple. 17:10, Zeus finally started the process of constructing.
He detected the latest code from the code source, then start compiling, build, and implemented all the tests, from the console interface, the person in charge of the day building (one of the programmers) seems to have seen some tests Through him, he said that there seems to be trouble. After the test is complete, all API documents will be generated from the code, and the code analysis and test coverage analysis, the latest test reports and various other reports will be released on the web. At last. The built-in software and related information have been successfully released, and the clock points to 17:18. "Now it is just the early stage of the project. It is time, at least 20 minutes.", The old bird programmer tells the experienced programmer and let everyone look at the test results. A programmer is muttered, looking at the log log, "I have tested it in this machine. How can I have a fault." The results discovered that the environment was changed, the configuration file was changed. It seems that there is still less conflict in the integration process, but these problems can be discovered soon and soon solve. The above is a typical day build process, the day-built process is fully automated, and the machine will perform all the build steps in the order sequence by pre-defined instructions. The steps involved in the day construct are optional. The value of the day can be considered to construct too waste time, but in fact, the daily constructive cost is negligible than the final incident cost. Of course, the establishment of the establishment system in the enterprise does require a lot of time, but in the long run, this is definitely worth it. From the surface, the day build can reduce the final tap cost, but this is just the most basic value of the day. In fact, the more critical role in building a day is the system that can be introduced into the day constructed. What does it mean? The idea of the day will bring changes to the development process of software companies: developers will collaborate more frequently under the system, development progress, and the quality of the software will be more stable. Software development itself is an activity that emphasizes communication and collaboration. However, in daily activities, there is often an impeding communication, such as both sides that need to communicate are not in the same geographic location, noise, communication, and so on. Therefore, there is a way to provide a method in software management to encourage people to communicate. Day build is one of the methods (but it is not the only way). Every construction will involve all members of the team, so communication is less, under the driving of the construction practice, each developer is working hard to the final purpose - "successful construction" efforts. In the third chapter of ALISTAIR COCKBURN, in the third chapter of the agile software development, the relevant issues in team communication and collaboration are detailed. For example, the essence of communication, affecting the various factors of communication, and how to overcome them. Finally, he also discussed how to promote team communication and build a successful team. Under the driver built on day, the progress of the project will become very obvious. Every day, the results will be released through a certain channel, the team and team's boss can see the software now, the completion of the project, the problems, and so on. This information constitutes basic information for software development. Not only can you clearly describe the progress of the project, but also provide basic data support for the management staff. With basic quantitative data, software development is not taken out of your head. The last value built in the day is to provide integration. At present, there is no unified management software in software development, and it seems to be difficult to do, because different software organizations are very different. During the development process, some valuable practices were joined, in the process of integrating into the day, these excellent practices were easily become part of the development process under the promotion of day construction.
Another excellent practice in the article advocated - test drive development practice, it is easy to integrate into day buildings. In fact, software testing is very important, it has become a judgment factor for successful day construction. Selecting Day build or continuous integration Although the essence of day builds and continuous integration is the same, their difference in integration has also led to some management differences: First, the day build has established a clear working day. Small objectives, the purpose of the team is to make the code can be built daily. Under the guidance of developers, it is often possible to play a high efficiency. Continuous integration makes this frequency smaller, as long as your code is submitted to the code library, you will test your results immediately. If there is a problem, you must immediately exclude, otherwise, either the process cannot continue, either wrong The developer's mailbox is filled with warning information during integration. This approach is higher for team requirements. For teams that have just been built in contact with the day, it may have a hand. Secondly, there is a very clear boundary line in the day, and the development work is done, or it is not completed, there is no third state. The basis of the basic practice day construct built in the day constructs three practices: automatic construction, unified code source and integrated test. The automatic building of automatic build is through scripting language, not by clicking the build button in the IDE environment. Day builds need to be constantly integrated, if hand-made, the cost is not good. So smarterly is to automate this work. In the early UNIX environments, the corresponding script is used to complete the build process. With the development of the advanced IDE environment, people who are slowly don't want to write Make scripts. But now, in order to automatically build the goal, we need to return to the history of manually preparing the Make script. It should be said that the construction method in the IDE environment focuses on personal development, while automatic construction focuses on team development automatic build goals are all build processes that can be all enabled through a simple command. The unified code source, ensures a development team sharing a unified code source. At this time we need to use the version control tool. The shared code library is also a basic practice of XP. Although XP also requires developers to modify the code of others, we do not advocate this practice, which requires a very high degree of tacit understanding between members. The unified code source guarantees that all of the person's code is always come together, this is the basis for the day building. If there is no guarantee, every construction we have to concentrate all the code of the owner, which will undoubtedly make the build process into disaster. The unified code source guarantees that any team member gets all the code and is based on this. Integrated tests only use code compilation and cannot prove that software can work properly, and the standards for evaluation software should be test. Integration tests must be implemented in day builds to ensure that the software is indeed work. Integration tests are also quite a numerical nouns, and some people refer to BVT-Build Verification Tests because they think that the main purpose of this test is to verify the correctness of the build. Some people call it smoke test because they think that the purpose of this test is to run software, see if it will "smoke". The test should be completed, rather than being abandoned with the test process without being satisfied. Testing will form results, successful testing, failure test, failure test details. The final result will notify the corresponding person through some way, requiring them to modify the design or test (if it is the problem of test itself). Integration tests are key factors that demonstrate successful construction. Like construction, integration tests should also be automated.
There are many tools built by the basic tools built in the day, but the most basic, the most wide tool is Ant (http://ant.apache.org). ANT is similar to Make, but has joined cross-platform features. Under this goal, Ant abandon the disadvantages of the Make tool to give the shell, providing a building way using an XML configuration file and defined a unified microcaround and powerful extension mechanism. These features make Ant quickly accepted and promoted. At present, the latest version of AT is 1.6.0.
Description = "Compile the Source"> Description = "Generate the distribution"> The above is a simple, but you can fully explain the example of the ANT workflow, from the manual of Ant. In this example, first define the basic information of the project and the properties required to use during the construction process, then initialize the environment (2) (create a time stamp and target directory), in 3 and 4, on the project Compile and package, at 5, provide a way to clear the project output. In Ant, the most critical four concepts is the Project, Target, Task, and Property. The definition and scheduling of these four concepts, the processing of the configuration file constitutes the core of Ant. And the specific tasks are used as the extension mechanism. This microcaround handling idea has been used in many successful software projects. This article does not intend to fully introduce Ant, so if you intend to introduce day builds in your organization, learn to use Ant is necessary. There are currently a lot of IDE environments to provide support for Ant (eg, Eclipse), so it is very convenient to use Ant. In principle, the light Ant has been able to complete a day build process, but there are some software to provide better packages, making the continuous integration make more simple. Typical two tools are Anthill (http://www.urbancode.com/projects/anthill/default.jsp) and CruiseControl (http://cruisecontrol.sourceforge.net/). The former is a commercial software that provides a lot of excellent day building practices. It is also very simple to use. The latter is developed by the famous Martin Folwer, which can be used free of charge. Another software worthy of interest is the Maven project under APCache (http://maven.apache.org/). This project is still very young and the current release of 1.0. MAVEN's positioning is the project management software, using the project object model (POM) to describe a project, further simplify the build process, and unify the workpieces produced by the process. Another goal of Maven is to promote excellent practices through a practical tool. For example, the organization developed by the directory tree. Although the price of the day constructs has many benefits, it is not a smooth sailing. The biggest problem is how to introduce three basic practices for daily build. The first two relatively simple, the hardest is to establish an automation test. For details on this part, please refer to the relevant part of the test drive development. The core task of building extended task day is compiled, constructed, implemented, and issued. In addition to these tasks, you can also add an extended task in micro. Generate a document. There are many ways to generate documents, the most critical is to generate an API document. Javadoc's concept weakens the importance of documents in traditional software development, and embed a large number of documents into the code level. In addition to the standard Javadoc documentation, you can use a third-party tool to generate custom documents, such as the To-Do List document. XDoclet is one of the tools. Precompiled. Many applications introduced the precompilation. Typical aspectj, as an AOP tool, aspectj's role is to generate an AOP's Java code using a specific code generator, and then compile. Incorporate pre-compiled work into the build process, you can simplify development workload. Typical also includes some ORM tools. Code analysis. Code analysis is an important job of software metrics. Code analysis can provide managers to provide a judgment code quality basis (do not use it as a unique standard). Code analysis is formal, so it can be made into software, integrated into the build process. For example, it is determined whether the code complies with the ratio of coding specifications, documents, and code, and the rationality involved in the classes. Test overlay analysis. Test coverage analysis is very important as a means of assistance testing. The review of the test code, the most critical evaluation test is sufficient (relatively), and this work is alive alone. Therefore, it should be automated and become part of the construction process. Problem tracking. Problems in the test process should be included in a problem tracking system that can be used to design automated tasks through and problem tracking system interfaces. Archive and backup. This is very basic, but it is also very important. The workpiece generated every day should be properly archived and backup. To learn more about the full introduction of the day build technology in a short article, from the DW website, you can find more content related to the management day build tool. About the author Lin Xing, is committed to studying agile theory and excellent software design ideas, and applies it to domestic software organizations. You can get more information by accessing www.qca.cn and www.qca.cn and www.qca.cn and www.qca.cn and www.qca.cn.
