build of this configuration was able to use the build parameters already a part of the progressively more automated build process.
Leading e-Service Impacted the Trailing e-Service
The service LServe depended upon MServe. MServe implemented new utilities as it was supporting another web application. The new utilities at times caused build failures.
Did we meet our goals?
We achieved most of our goals—clean build, simple tools, build on demand, build and deploy together, and automation. It was a diligent approach to develop the build and deploy process in small steps. The approach resulted in a single script for both developers and the build miesters. A big bang approach normally is not goal oriented and takes a longer time to build a satisfactory process. The process revealed that the open source environment does require more attention and communication is the key to avoiding build failures.
The author would like to acknowledge Mark Dovi, Software Development Engineer, who actively participated in the implementation of this process. The later development was carried out by Petar Obradovic, Software Development Engineer, who is still enthused about making further refinements. The author greatly appreciates their support in preparing this manuscript and accompanied presentation.
- Steve McConnell, Daily Build and Smoke Test, Best Practices, IEEE Software. Vol. 13, No. 4, July 1996.
- Michael Cusumano and Richard W. Selby, Microsoft Secrets, The Free Press, 1995
- Sanjay Mahapatra , Benefit from platform-independent builds, Java World, August 2000
- Michael Cymerman, Automate your build process using Java and Ant, Java World, October, 2000
- Bhushan B. Gupta and Steve Rhodes, Adopting a Lifecycle for Developing Web Based Application, Software Quality Week, San Francisco, June 2000
- Alan MacCormack, “Product Development Practices That Work: How Internet Companies Build Software,“ MIT Sloan Management Review, Winter 2001