(This article is published in "programmer" 2006 6th)
Perhaps due to the inherent "high-tech" characteristics (or said, software people's advice self-pity), the management and process control of the software project never lacks a variety of tools. In some large, "regular" software companies, configuration management should use Rose to draw a large pile of beautiful graphics through ClearCase, and the pressure test should be run with LoadRunner. When the software company's bosses are obsessed "Formal Management" with beautiful reports and documents, these expensive business tools have been favored by them.
Fortunately, more and more software developers and bosses began to realize that the methods used by software projects do not have certain regulations, different projects, and different teams need to choose different development methods. The tool is the same as the three prisms that reflect the figure. Thus, selecting development process tools to a large extent, a by-product of choosing a development method.
For enterprises applying developers in the intense demand to change the storm, how to keep up with the real needs of customers, how to ensure that the maximum value for customers is what they think every day. At this time, paying attention to AC feedback, the various agile development methods of customer value are driving, they have become their natural choice. Interestingly, the open source process tools are mostly adapted to agile methods. It seems that it is in fact, but it has its truth: open source projects are less affected by various political factors, and the survival environment has more uncertainty, so it is also more emphasis to ensure maximum customer value. And this idea, with agile methods are unwinding. In addition, those "pragmatic programmers" to advocate agility methods are often the activists of open source communities, so I am suitable for the open source process tools for agile projects, especially prone to find it.
Agile developers are happiness because they have many excellent open source tools to choose from; agile developers are painful because they must find out their own in the tools that are fascinating. A set of tool stacks and combines them to synthesize a complete development process with their own management strategies. This article will introduce readers to a group of process tools commonly used by ThoughtWorks, as well as some experience in using these tools in agile projects, hoping to help readers slightly relieve this pain.
As a programmer, the author focuses on the technical level more attention to the process tool. From my perspective, agile methods are the most important, and the most immediate part is the test driver and continuous integration, and our tool trip starts from these two things.
Unit test: JUnit (and MOCK)
In the toolbox in agile development, Junit is likely to be the most widely known, and one of the most important values, of course, it also affords such award. If the discussion is born, Junit is created by Kent Beck and Erich Gamma. If the influence is influential, the "red bar / green strip" it is introduced is far-reaching.
Figure 1: Various Green Bars
"Red Bar / Green Bar" is more than just a mark of test success and failure, which constitutes the most basic rhythm in agile development: "Writing test - red - writing code - green strip - Reconstruction", these five simple The step ensures that each thoughts have unit tests as records, each code has unit tests to ensure its quality, and the entire software project is always moving toward the value, the most optimized direction. The red strip and the green strip are clearly intuitively pointing out your current location and the work that should be done next. A striking red strip / green strip has such an important hint for developers, so that when Microsoft does not place such a striking sign in the unit test tool of Visual Studio 2005, it has attracted a developer. Resentment carrier. When I said JUnit, I mean the entire XUnit family - covered from Java / .NET until C / C to Haskell / Eiffel to the big family of JavaScript / Ruby / Python. Although running on different platforms, different languages, they have the same group that cannot be misreaded: Red Bar / Green, Testcase / TestSuite ... This also makes developers who always feel relieved. Before you start writing your code, you write a test for it; run all the tests as much as possible. You can immediately feel the help brought by TDD.
However, there is a catalyst that allows this chemical change to be more intense, that is the Mock framework. The MOCK framework represented by Easymock and JMOCK, its role is to simulate the relevant objects other than the object being measured, thereby achieving the decoupling between objects to achieve a "unit test" in the true sense. Wonderful is that when you put the MOCK frame in the test drive practice, the development process will guide you to get low coupling, modular design, because you have a tightly coupled class to test, and the Mock framework Let you be willing to separate more classes with IOC mode to assume your respective responsibilities. On the main platforms such as .NET and Ruby, similar MOCK frameworks are available.
Function test: Selenium
Throw all the technical considerations, with intuitive, I personally think that Selenium's biggest advantage is that it is shocking: hundreds of Test Case runs, I only see the web page is turning over the screen, simulating A variety of users operate, and finally generate a huge report, the background is calm and pleasant. Even for the whole, the psychological effect of this process is also self-evident.
Figure 2: Selenium also adopted a red bar / green strip interface design
Many people think that the web interface is not test driver before using Selenium, and does not need to be tested. However, we often encounter such a dilemma: the customer thinks a sentence on the page should be written, but the developer believes that the customer's three days ago is another, seriously recalling but no one can remember three days ago. Say what. If the JUnit unit test records the developer's design idea for the software, Selenium records the customer's requirements for software functions, and the customer's request is still met.
Selenium's usage has a lot. You can put it outside the build process, and the customer's regular inspection software is in line with the requirements; you can also make it as part of the build process, use it to drive the development, form a larger "red- Green - Reconstruction "cycle. In addition to writing a test script in an HTML format, Selenium also supports programming-driven mode, which can be used to write multiplexed test cases. And the entire Selenium is written in JavaScript and HTML, which means you can easily integrate it into any web application, regardless of the platform for developing this application is J2EE or .NET or RAILS. Selenium's name has an interesting origin: Before Selenium appears, the most famous web application function test tool is a Mercury Quanlity Center, but it is a commercial tool, but it is powerful but the price is not very kind. It often makes developers again. Love hates. So, ThoughtWorker, who has opened the open source test tool, called Selenium - "Mercury" meaning "Silver", and "Selenium" exactly a special medicine that specializes in mercury poisoning.
Build a script: Ant vs. maven
Now you have used Junit to write all the design ideas, and use Selenium to write down all the features. You also need to let all test cases can run automatically so that all tests are still passed smoothly. At this time, Ant came to your hand. Developed by Apache, many years of practice, Ant has accumulated a lot of practical plugins, almost all common tasks have corresponding plugins to be completed. Moreover, in the ANT script, you can directly call the Java class (Nant's Nant's Nant can be directly inserted into the C # code in the script), that is, you can actually use Ant to do anything.
However, the most common usage, or use Ant to complete the entire build process: from the compilation source code, to the package application, to the deployment server, to the initialization database, to perform the test report, only one instruction can be completed. Similar buildings have already existed in the world of C / C , that is, famous make, but Ant is easier to use.
The MAVEN-bit advantage of the next day, the biggest advantage is that it has built more support for J2EE projects (especially web projects), as well as more project management related functions. Like unit testing, create a report, etc., in the ANT, plugin implementation, in Maven, has built-in support. Even many open source projects are generated directly with Maven. However, with the author's foolish, Maven is more suitable for open source software such a loose project, and it is enough for the general enterprise to apply Ant.
However, after entering the world of Ruby / Rails, the author feels Ant and Maven have a common defect: their build scripts are written in XML, so the volume is quite huge, and it is not easy to understand. In contrast, Rake directly uses Ruby to write build scripts, which is more simple and easy to use. Perhaps we need to find another domain-specific language that is more suitable for describing the task of describing the "Software Build".
Version control: CVS vs. Subversion
Any multi-person development project must have a version control system - even if a person developed, a version control system is also required to provide backup and recovery support. Due to comprehensive testing as a guarantee, agile methods advocate the use of "ownership all code" code ownership form, which means that two people often modify a document, in some configuration files There is more frequent. Therefore, the version control system used by agile development is best not to use file-level locks - this is the way VSS default locking method, but we can also change the lock mode by configuring. Open source choice is CVS and Subversion (referred to as SVN). There are some differences between CVS and SVN, but we usually don't have to mind these differences as developers. It is worth noting that when the file conflict occurs, the SVN will force the user to decompose conflicts first, and then submit the file to the code base. Also, every time someone successfully submits a new file, SVN generates a new revision of the entire project instead of a revision of each file as CVS, which makes the version control easier.
In a agile project, each development Pair will submit its latest code every 15 minutes (up to 1 hour), and a project group usually generates dozens of revisions daily. Even if it is not possible to successfully build a version, you usually have a hundred build versions per week. The report corresponding to each build version is the best way to effectively master the progress of the project manager.
Continuous integration: CruiseControl
We have already mentioned that some of the revised version of the developer is constantly submitted, which is unable to successfully build, the reason is to run a faithful watchman on the version control system: continuous integration tools. Their representative is CruiseControl developed and maintained by Thoughtworks employee.
CruiseControl's task is very simple: Whenever someone submits a new file to the code base, it will check the entire project to a test environment, then execute the build script of the project, complete the entire build process, and run all test. If all this is passed smoothly, CruiseControl will generate a new build version; otherwise, the build failed, all people do not allow any code to check out or submit any code until people who fail to fail save the problem, let the build resume until.
A code base that can successfully build represents the health of the project. Keeping project health is so important, and CruiseControl must tell the entire team with the most striking way: our project is now. To this end, various teams came up with various ways. We can use a client tool to monitor the build situation of CruiseControl, then let this client call other programs when discovering the failure: sing a song, make a strange call, or light a light ... In short, let everyone know.
Figure 3: Red light / green light, constructing results
Knowledge Sharing: Wiki, especially Tiddlywiki
The "Agile Declaration" clearly wrote: "Individual and interaction is better than process and tools." For a agile team, the most important thing is to establish effective communication channels. In ThoughtWorks, each project has its own wiki, developer, project manager, customer ... all projects involve their harvests with experience in Wiki so that everyone can share and communicate.
Open source wiki is easy to find, I don't have to say more here. The only thing I want to introduce is this small thing called Tiddlywiki. This is a Wiki written in HTML and JavaScript, using it even does not need a server, you can start writing your wiki if you open this HTML file locally. The content you have written is also saved in this HTML file and also provides the ability to modify the tracking. With this wiki, you can put the entire document in your version control system and don't need any additional configuration for it. Also, don't forget the most important tool: Paper card - you can write, write any color, you can draw any figure you want to draw, you can use any order to place them, you can move any time, you can add Note, everyone knows how to use them. You can even tear them, the high quality paper card is torn with a special feel ... well, the paper card is not software, usually not free, but you know how to get them.
Figure 4: THOUGHTWORKS - a trusted global paper card provider
Written in the last
After introducing our commonly used tools, I believe that the reader already knows: To practice agile development, which tools can begin starting. Finally, I still have an advice to give me dear readers: Don't be tied to your hands and feet. Every project, each team is unique, they need their own unique ways, and you need to choose the right tool and appropriate way of use for the procedures and teams. This is not an easy task, I hope this Xiaowen can give you a good start.
