| To illustrate how all the tools and techniques described in this book can be brought together, I will conclude by revisiting the working example outlined in Chapter 1 and how its Software Build and Release Management process was implemented. The RationalBank Scenario Throughout this book, you have seen references to RationalBank. This is a mythical retail banking organization whose current work includes implementing an online Internet banking application. The application is a traditional three-tier model with a number of components: a Web client customer front end, a thick client administrative front end, some middle-tier business logic, and a back-end database. The examples in this book have concentrated on defining the build and release process for the middle-tier business logic component, RatlBankModel. However, it is worth understanding how the Software Build and Release Management process as a whole could be applied and standardized across all the project's components, especially in the context of what has been discussed in this chapter. I will start by discussing how the RationalBank SCM environment was defined. The RationalBank SCM Environment RationalBank uses the ClearCase UCM usage model, with each of the application components mapped to a single UCM component and UCM project. Table 12.2 lists the naming conventions that are used throughout the project. Table 12.2. RationalBank Naming ConventionsObject | Naming Convention |
|---|
VOBs | RatlBankProjectsUCM Project VOB | | | RatlBankSourcesDevelopment VOB containing multiple components | | | RatlBankReleasesStaging VOB containing multiple components | UCM components | RATLBANKDBDatabase component | | | RATLBANKMODELMiddle-tier business logic component | | | ... | | | RATLBANKDB_RELDatabase staging component | | | RATLBANKMODEL_RELMiddle-tier business logic staging component | | | RATLBANK_BL_RELComposite baseline staging component | | | ... | UCM projects | RatlBankWeb_Proj, RatlBankModel_Proj, ... | UCM streams (integration) | RatlBankWeb_Int, RatlBankModel_Int, ... | UCM streams (release) | RatlBankWeb_Rel, RatlBankModel_Rel, ... | UCM streams (developer) | username_RatlBankWeb_Dev, username_RatlBankModel_Dev, ... | Views | As per stream. For example, for the RatlBankWeb_Int stream, the view tag is RatlBankWeb_Int. | | | Snapshot views are used for all developer views and dynamic views for all integration and release views. |
Each of the UCM projects has a standard directory structure (similar to that used in Chapter 4), with all source files held in an src directory, all intermediate build results built in the build directory, and all release packages (distribution archives) created in the dist directory. The exception is the RatlBankWeb project, where the directory structure has been changed to conform to the requirements of the IDE (Rational Application Developer). In the RatlBankWeb project, therefore, all Web files (.html and .jsp files) are held in a WebContent directory, and all Java files are held in the JavaSource directory. For this project, the build.xml file will be changed accordingly. Forcing Your Build Scripts on Your IDE It is a matter of personal preference whether to make the IDE's preferred build directory structure fit your Ant build scripts or vice versa. In this scenario, since Ant is typically more configurable, the pragmatic decision has been made to change Ant rather than the IDE. |
Each of the development projects uses the Active Development Line and Release-Prep Line branching strategies discussed in Chapter 3. The RationalBank Project Rhythm The intention of the RationalBank project is to develop and deliver frequent changes. This is typical of an Internet banking application, especially the web-based front end where changes (to meet rapidly changing business requirements) might be required to be delivered at frequent intervals. Table 12.3 attempts to identify the project rhythm for the RatlBankWeb project. Table 12.3. Project Rhythm for the RatlBankWeb ProjectQuestion | Response |
|---|
Are there any dependencies between internal components? If so, do the components have to be built in any specific order? | No dependencies between internal components. | Are there any dependencies on the output of external projects or components? If so, how will these outputs be made available? | Yes, dependent on the output of the RatlBankModel and RatlBankDB projects. Requires prebuilt .jar files from each project's staging component. | How many developers are working on the project? How often are they expected to deliver changes into the integration area? | Five developers are working on the project. They are expected to deliver frequent changes, possibly up to five times a day. | What are the inputs for the developer Private Builds? Will they build against the complete source code structure or against a partial structure and prebuilt binaries from the Integration or Release Build? | The developers are building against the complete source code for the RatlBankWeb project. They will additionally work against a recommended composite baseline (from the RATLBANK_BL_REL component) to identify the correct versions of the staged RatlBankModel and RatlBankDB .jar files. | How long does it take to execute a full Integration or Release Build (including workspace population, compilation, unit testing, and internal deployment)? | The complete build of the RatlBankWeb project takes on average 15 minutes, including .jsp precompilation. | How often are Integration Builds expected to be carried out? Where will the outputs be stored? | Given the build time and potential delivery rate, Integration Builds are scheduled for every 30 minutes during the working day. Since no other projects are dependent on the output of the RatlBankWeb project, only the latest Integration Build is stored using CruiseControl. This build is also deployed to the development server for further link testing. | How often are Release Builds expected to be carried out? Where will the outputs be stored? | It is expected that a Release Build will be carried out once a week. The Release Build is stored and baselined in the ClearCase RatlBankReleases Staging VOB. |
Using this table, you can estimate that a build schedule of every 30 minutes should be adopted in CruiseControl for the RatlBankWeb project. This will be subsequently refined in day-to-day development. It was also possible to determine how the inputs from other projects into this build would be made available. For other projects, the build schedule is different. For example, the middle-tier project RatlBankModel has more complicated Java code and therefore potentially longer integration times. There might also be a number of different components in this project, requiring different levels of "component" integration. In such a scenario, the Integration Build for this project might be scheduled only twice a day. Because of the time taken to build and integrate this project, the decision was made to stage its build outputs so that they could be used by other projects. Although this example is slightly fictitious, the schedules that I have seen for real projects with similar development processes and technologies are quite similar. The important thing is that you go through the process of identifying the optional project rhythm for your project. You might deem that you require only a nightly Integration Buildthis is fine. However, by working through the process of examining whether you could build many times a day and what the implications would be, you get a good view of whether your build process can be made more productive. The other point to remember is that if you will build many times a day, you need to make sure that you have a good automated unit test suite. This allows you to have confidence that delivering a small change (even if it's not the complete change) will actually work at the unit level and therefore is suitable for further development or testing. Definition of Build Scripts Since a number of projects are under development, in this example it does not make sense to maintain duplicate copies of what will essentially be very similar targets in the build scripts. Therefore, to simplify this process, as in Chapter 5, a standard Ant library (standard-targets. xml) and set of macros (standard-macros.xml) has been created and versioned in the JavaTools component. However, each of the projects still has its own build.xml, default.properties, and buildinfo.properties files. Figure 12.6 shows the complete list of build scripts maintained for RationalBank. Figure 12.6. RationalBank build scripts
Listing 12.1 shows an example of the build.xml file that is used for the RatlBankWeb project. Listing 12.1. RatlBankWeb build.xml File| [View full width] <?xml version="1.0"?> <project name="RatlBankWeb" default="help" basedir="." xmlns:ca="antlib:net.sourceforge.clearantlib"> <property environment="env"/> <property name="dir.src" value="JavaSource"/> <property name="dir.build" value="WebContent/WEB-INF/classes"/> <property name="dir.dist" value="dist"/> <property name="dir.lib" value="WebContent/WEB-INF/lib"/> <property name="dir.javatools" value="..\..\JavaTools"/> <property name="dir.stage" value="..\..\RatlBankReleases\web"/> <property file="build.properties"/> <property file="default.properties"/> <import file="${dir.javatools}/libs/standard-macros.xml" optional="false"/> <import file="${dir.javatools}/libs/standard-targets.xml" optional="false"/> <!-- define the set of runtime libraries required for project --> <patternset > <!-- suppporting Rational Bank libraries --> <include name="**/RatlBankModel.jar"/> ... </patternset> <!-- define a classpath for use throughout the file --> <path > <fileset dir="${dir.stage}"> <patternset ref/> </fileset> </path> <!-- project override for creating release packages --> <target name="dist" depends="compile,make-manifest" description="create distribution war file"> <war warfile="${dir.dist}/RatlBankWeb.war" webxml="WebContent/WEB-INF/web.xml" manifest="${dir.build}/manifest.mf"> <lib dir="${dir.stage}"> <patternset ref/> </lib> ... </war> ... </target> <!-- project override for CruiseControl Integration build + baseline --> <target name="integration-baseline" description="Integration Build and Baseline" depends="update-view, junit-all, dist, javadoc"> <cc-apply-bl basename="${label}" component="RATLBANKWEB"/> <ca:ccblreport baselineselector="RATLBANKWEB_${label} @${name.project-vob}" outfile="build/ccblreport.xml"/> </target> <!-- project override for Release Build --> <target name="release" description="execute Release Build"> depends="compile, junit-all, javadoc, update-buildinfo"> <ca:ccstage todir="${dir.stage}" outfile="ccstage.xml"> <fileset dir="${dir.dist}"> <include name="**/*.ear"/> </fileset> </ca:ccstage> <cc-apply-bl basename="${build.num}" component="RATLBANKWEB" plevel="BUILT"/> <cc-apply-bl basename="${build.num}" component="RATLBANKWEB_REL" plevel="BUILT"/> </target> ... </project> |
This example reuses a number of the targets from the standard-targets.xml file, such as compile and junit-all. However, it overrides the dist target for creating the distribution archive as well as the CruiseControl integration-baseline and Release Build release targets. You will also notice the definition of a <patternset> called runtime-libs; this <patternset> contains the .jar files that the project must build against and be distributed with for it to run successfully. It is via this mechanism that the outputs from the RatlBankModel and RatlBankDB are incorporated. Finally, you will notice that the release target also stages the distribution archive into the RatlBankReleases Staging VOB. Execution of Build Scripts All RationalBank Integration Builds are automatically executed using CruiseControl. However, each project has a different schedule, depending on its project rhythm. The list of CruiseControl integration projects is as follows: RatlBankWeb_int CruiseControl project for the RatlBankWeb project. This project is scheduled to build every 30 minutes. RatlBankWeb_LinkTest CruiseControl project HTTPUnit testing of the deployed RatlBankWeb project. This project depends on the successful build of the RatlBankWeb CruiseControl project. RatlBankAdmin_int CruiseControl project for the RationalBankAdmin project. This project is scheduled to build every 2 hours. RatlBankModel_int CruiseControl project for the RatlBankModel project. This project is scheduled to build twice a day. RatlBankEJB_int CruiseControl project for the RationalBankEJB project. This project is not yet scheduled. RatlBankDB_int CruiseControl project for the RatlBankDB project. This project is scheduled to build every 2 hours.
Figure 12.7 shows the CruiseControl Build Results web for the complete set of RationalBank projects. Figure 12.7. RationalBank CruiseControl projects
Template Projects in CruiseControl Rather than create a new CruiseControl project for every RatlBank project, it is possible to combine CruiseControl's properties and plugin preconfiguration capabilities to define template projects, as follows: <plugin name="project"> ... <modificationset> <clearcase branch="${name.ucm.branch}" viewpath="${dir.project}"/--> </modificationset> <schedule> <ant antWorkingDir="${dir.project}" buildfile="${dir.project}\build.xml" target="integration"/> </schedule> ... </plugin> <!-- RatlBankModel project --> <project name="RatlBankModel_int"> <property name="dir.project" value="C:\Views\RatlBankModel_int\RatlBankSources\model"/> <property name="name.ucm.branch" value="RatlBankModel_Int"/> </project> <!-- RatlBankWeb project --> <project name="RatlBankWeb_int"> <property name="dir.project" value="C:\Views\RatlBankWeb_int\RatlBankSources\web"/> <property name="name.ucm.branch" value="RatlBankWeb_Int"/> </project> This is another good reason for using a standard directory structure and naming conventions. More information and examples on template projects are available at www.developertesting.com/archives/month200602/20060210-TemplateProjectsWith-CruiseControl2.4.html |
Reporting RationalBank automatically creates and publishes a number of different types of reports. For each Integration Build E-mails are sent on build success to nominated "project integrators" only. E-mails are sent on build failure to all project team members. All changed files are listed on the CruiseControl Build results Web site.
For each Release Build E-mails are sent on build success or failure to nominated "project integrators" only. A ClearQuest change request report is generated for the release (as described in Chapter 8). A ClearCase baseline report is created and merged into the CruiseControl Build Results web (as described in Chapter 9). ClearCase configuration records for all the build outputs are created and versioned (as described in Chapter 9). A Build Record is automatically created in ClearQuest (as described in Chapter 11).
All reports are stored alongside the build outputs in the Staging VOB. Releasing and Deployment All Release Builds are built on a Release-Prep stream rebased to a candidate Integration Build baseline (as in Chapter 10). Dynamic views are created for building on this stream. There is an associated CruiseControl release project for each CruiseControl integration project, as illustrated in Figure 12.7. However, rather than being automatically scheduled, the release projects are executed via "forced" builds from the CruiseControl JMX console. Executing a Release Build also stages the project's built objects into the RatlBankReleases Staging VOB. The Build and Deployment Tracking capability (from Chapter 11) is also used to capture the Release Build baselines and manage their deployment through the different test and live environments. Since all CruiseControl builds are automatically recorded as build records in ClearQuest, this enables traceability of deployment to the build (and baseline) that created its contents. |