Build and Deployment Process for Web Applications

[article]

dynamic html and JDBC. The teams were not bound by a single IDE and thus both VisualCafe and Jbuilder were being used across the board. The development was carried out in the PC environment and the deployment platform was Linux 6 with Apache Web server. The development tools included Ant (a build tool) [4], CVS (configuration management system), XML and other scripting languages. The teams used Evolutionary Development Lifecycle[5,6]. The functionality was built in small chunks with a constant evaluation either from a real or a surrogate customer.

The environment included a development, a test and a demonstration server with identical system configuration. The application was built and deployed on all three servers. The development server code was constantly changing. Building on the development server synchronized it with the other servers. In the beginning the testing server was used for both validation and demonstration. This caused lengthy validation downtimes especially when there were customer demonstrations for usability evaluations.

Build and Release Process

Setting Up Build Goals:
The build process was to meet individual developer’s needs and other build miesters needs. Individual developers needed to build their components and test their code while the build meitser needed to build the system for deployment. The activity was initiated with establishing a build team. The team was comprised of two representatives from development and database teams, the system (server) administrator, and a process architect. The first task of this team was to setup build goals. Following are some of the “MUST” goals that the team decided the build process to have.

  • Clean build every time
  • Simple process without any need for documentation
  • Build the entire system as well as any specific components
  • Choose any version of a system component for a build
  • Build recursively starting at any level
  • Use simple tools
  • Build on demand
  • Build and deploy together
  • Automated
  • Build needed targets concurrently

Some of the “WANT” goals included:

  • Be capable of driving a unit test
  • Executable from a web site

Build Configuration:

The entire application was under CVS, a version control utility running on a dedicated server. The code was transferred to a build area on the target server, built on the server and then deployed in a dedicated area where it could be used for production if desired.

Directory Structure:
The application directory structure was predetermined based upon the application web server. The tools and utilities were stored in dedicated directories. In the event that an e-Service depended on another e-service it was stored in the e-Service area as a jar.

Communication:
The build day and time was predetermined for the LServe, Thursday 1 PM. All the developers were reminded of the build time and asked to check in their changes to CVS by noon. Another reminder was sent at noon and code was labeled at 1 PM. Exceptions were made if a developer was working on a critical functionality. Since LServe depended on MServe, MServe was built by Thursday noon.

Incremental Approach – Stepwise Refinements:
Initially, each e-service had its own build script that was used by the build miesters. The application build and deployment was manually performed by using a Korn shell script. It was a “clean build” approach. The server was shutdown, old code was deleted from both build and deploy area. The code, including the barebones build script, was moved from the resident server to the target server using ftp. It was built in the build area and then transferred to the deployment area. Any update to the application configuration files and the server properties were performed manually. The server was restarted. The application was smoke tested

About the author

Bhushan Gupta's picture Bhushan Gupta

Bhushan Gupta has nineteen years of experience in software engineering, nine of which have been in the software industry. Currently a Process Engineering Architect at Hewlett-Packard, he joined the company as a software quality engineer in 1997 where he was responsible for identifying key process areas to reduce rework. Based upon Hewlett-Packard's quality parameters, he has developed quality goals, quality plans, and software validation strategies for several products. In his current position he has promoted the iterative lifecycle, contributed to software validation planning and execution processes, carried out project retrospectives, and software process improvements. He has worked on use cases and their adoption for development of requirements and test cases. From 1995-97 he worked as a Systems Analyst at Consolidated Freightways where he contributed to the design and development of a Windows based logistic management system. During his ten years tenure (1985-1995) at the Oregon Institute of Technology Bhushan Gupta developed, planned, and taught numerous software engineering courses. He served as the curriculum coordinator for five years and resigned from his duties as an associate professor.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09