enforcement of build best practices, reusability, and transparency (self documented). The Community Developed build must be able to actively understand when a change has occurred, where the shared source code resides, and how to incrementally build the new changes as efficiently as possible (see Figure 2).
Defining a build best practice is critical to the agile developer. This involves simple steps such as identifying directories where shared objects are to be referenced. Definitions of environment variables should be well communicated such as the CLASSPATH definition. File and directory names should be discussed and agreed upon minimizing the need for code and package re-factoring. The Community Developed build should enforce the use of the same version of the JDK. This will prevent unexpected compiler errors that may be hard to understand. Make sure the system path has the java and javac programs coming from the same location on the file system and that the CLASSPATH used is from the same instance of the JDK. A Community Developed build process allows input from all developers to determine the overall build best practice before anyone starts writing scripts.
Script reuse is critical. Removing redundancies in scripting is the fastest way to improve your overall builds. For developers using IDEs, the build scripts themselves should be based upon the IDE project file. This can be challenging as the builds may need to use quot;headlessquot; mode techniques to build inside the IDE the same as outside the IDE. Agree on how the scripts are to be written. Write simple, transparent, portable and organized scripts. Try to minimize the number of lines of scripting and minimize the number of properties for each builder to set.
Your Community Developed build process should be transparent. Every script should follow the same general logic allowing anyone to understand the process. There should be no hidden or hard-coded directories. This makes debugging a build simply impractical. In order to achieve the incorporation of local build directories into the Agile development effort, environment variable settings can be used and passed to the local build to determine the order in which code should be found and compiled. If the order can be managed, the code managed in the version control tool can be passed to the compiler first, and then secondly the items in the local build directory would be passed to the compiler. It is important to note that for this to work, common components should not be managed inside of the local Project. Common components should always be found by the compiler in standardized directories.
Continuous Agile Builds Must Be Community Developed
A disciplined and well managed build process is the core of any Agile Development effort. Without a well managed central build, there is an immediate breakdown in the process, impeding the creation of executables even though source code may be clearly shared via a Version Control tool. When the build breaks, so does the Agile development process. Agile development can only be a dream if the build is at best a chaotic process.
Builds can be the most chaotic process in the overall Agile development effort requiring attention to detail so that the many pieces fit together correctly. For that reason, the builds must be carefully managed, centralized, and consistent whether the build is a local build or a shared build running on a specialized build machine. If Agile development is to be achieved, the build process must be controlled and repeatable by all members of the development team at all levels, local and shared.
About the Author
Ms. Ragan has had extensive
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
