XP and Ant, Page 5
Some projects elect not to have any formal automated build process. They rely on a developer manually performing a known set of steps for each iteration of the build cycle. Here are some of the pitfalls of this approach. The process must be well documented and communicated to all members of the team. That's certainly true whether or not an automated process is used. However, when a process is automated, changes can be made behind the scenes that don't affect the interface or the way a developer uses the tool. When that's the case, users are shielded from the details of the implementation. They only need to know if there is a change in the manner in which a procedure is run. Suppose that part of your build and deployment process is to deploy Enterprise JavaBeans into an EJB container. If the build tool has a rule for EJB deployment, developers need only to invoke that rule. Suppose that the team decides to change the EJB container product. It's then possible to change the underlying implementation of the rule for EJB deployment without changing the way in which developers invoke it. In this way, the development team is shielded from the changes in EJB deployment procedures because they're automated.
The level of complexity in a manual process is greater than that of an automated process. Because of the increased complexity, the probability of an error occurring in the execution of the task increases. Someone might miss a step, or changes in the procedure might not be communicated effectively throughout the group. Certainly, no tool can solve a lack of effective communication. But again, as the complexity of any procedure increases, the probability that an error will occur also increases. A problem created by missing even a single step in a procedure (such as forgetting to copy a DLL or a JAR file) is often the nastiest type of problem to track down. When the problem is finally found and corrected, nothing of value has been added to the project. Correcting a bug that results in a code change usually improves the product and definitely adds value. By contrast, time spent tracing a bug caused by a procedural error is time wasted.
A complex manual process is not a repeatable process. Even if the same person performs the process each time, there's no guarantee that the results will be the same. Certainly, the quality of the outcome is likely to vary among individuals. By configuring a build process, you can debug the process once and then use it repeatedly.
A manual process is also fatiguing because it adds to the overall workload of project team members. If getting a procedure correct under normal circumstances is difficult, it's even more difficult when the team is under pressure, which is often the case in development projects. The time when people are under the most pressure is the time when they're most likely to make a schedule-killing mistake in a procedure. Repeatedly performing a procedure that could be automated is mentally fatiguing and adds to the likelihood that mistakes and schedule slips will occur. It's part of a vicious cycle.
Another downfall of manual build and deployment processes is that they require each team member to have specialized knowledge of the process. When a team member leaves the project, that knowledge is lost. The time and training required to bring new team members up to speed on the procedures increases with the level of complexity of the procedures. Automating those procedures reduces the learning curve for new team members. This also permits team members to develop areas of expertise instead of requiring everyone to be an expert in everything.
No project is too small to have some level of automated processes in place.
Custom and Proprietary Solutions
Some of the disadvantages of custom and proprietary build processes are really true of any proprietary solutions. Most developers we know really don't like to work on them. In fact, most developers prefer to develop skills that they can take with them to the next assignment. Learning the details of an in-house product that's not used anywhere else is generally not appealing. The consequence is that it could be difficult to attract qualified people to the project if it's seen as a technological dead end. Also, with a proprietary solution, you're virtually guaranteed to have to train new members to the project in your methodology. Ant is becoming a widely used tool, so it's possible to hire someone with a working knowledge of the tool.
It might be argued that custom scripts written in a standard scripting language, such as Perl, shouldn't be considered a custom solution. Certainly, it's true that the language itself is a standard and that it's possible to hire people who are experts in it. But there is a downside to choosing a proprietary solution to your problem. Creating proprietary solutions when off-the-shelf solutions exist is generally a bad idea. When using an off-the-shelf tool, you gain the benefit of numerous hours of development, debugging, and testing by the producers and customers of the tool. On the other hand, a proprietary solution requires your team to pay for all the initial development and debugging. Proprietary solutions also require your team to pay for the ongoing cost of maintenance, which includes fixing bugs and adding new features. With an off-the-shelf solution (especially a free open-source tool), the cost of development is amortized over a much larger customer base, making it more cost-effective. In short, a quality off-the-shelf solution will probably be quicker and cheaper to implement and maintain over the life cycle of the project.
Another advantage of Ant is that the buildfiles are written in XML, which is fairly self-documenting. With scripting, unless the writer used meaningful variable names and comments, the script could be fairly obfuscated and unmaintainable. This isn't necessarily the case all the time; it's just that Ant XML files in general are more likely to be easily maintained than custom scripts. Also, just because you have custom scripts doesn't mean that you have to throw them away to use Ant. Ant has a BSF scripting engine capability that enables you to integrate existing scripts.
Integrated Development Environments (IDEs)
Various IDEs on the market help a user with the development process. Most include the capability to define a project's build requirements to facilitate a well-configured repeatable build process. Many also include a lot of other features, including a symbolic debugger, visual graphic design tools, and testing features. Here are some aspects of relying on an IDE for your build process to consider.
One of the disadvantages of relying on an IDE for your build process is that it might tie you to the platform on which your development work is being done. Many Java IDEs are written in Java and, therefore, are platform-independent. If your IDE isn't platform-independent and you must support multiple platforms, you might find that you are maintaining more than one build process. This can be problematic because it's difficult to keep multiple processes in sync. It's also common to experience problems with infrequently used build processes because of changes in the surrounding environment. Another problem when relying on the IDE's build environment is that if you're forced to change IDEs, you must redevelop your build and deployment process. Depending on the complexity, this could be time-consuming.
Another problem with IDEs is that the environment must be set up for each developer. We have worked on projects with more than a hundred developers using an IDE. Sometimes problems are caused by subtle differences in the configuration of development environments among developers. These problems can be difficult to track down.
IDEs are definitely useful. Fortunately, with Ant and IDEs, it's not an all-or-nothing choice. One of the features of Ant is that it can be integrated into many of the IDEs that are now available. This gives you the benefits of both products. You can use the IDE for code development and debugging tasks, and you can use Ant to achieve a common enterprise-wide build process. In Chapter 9, "Company ReorganizedWorking with a New Subteam," we delve into the techniques of integrating Ant with a popular IDE.
Page 5 of 6