Michael Sayko

Automation is required to build and deploy software applications consistently. Automation is necessary to build and deploy software applications rapidly. While build and deployment automation is essential for modern software development, not all approaches to automation produce the same results.

The use of a commercial tool to automate your build and deployment process saves time and money. In this article, Michael Sayko explains how to go about selecting the right tool for your specific project and team's needs, and then how to use that tool efficiently.

Years ago, I learned of commercial tools that automated builds and deployments by executing a combination of command line instructions and scripts. At the time, I questioned the value that these tools could provide. Even though the tools were promoted for build and deployment automation, they did not generate the command line instructions and scripts to actually build and deploy applications. The new tools did not replace existing build tools like Ant and make. Instead, the tools required that their users provide the build and deployment scripts. Surely, I could create one top-level script to build my application and another top-level script to deploy it. Why would I need a commercial framework to run my build and deployment commands and scripts?

How do you build? How do you select the source code files to include in a build? How do
you identify the revisions, or versions, of the files to include a build? Do you build from the tip revisions in your version control system or do you build by selecting a specific revision of every source code file? Do members of the development team specify the changes to include in each build or do you sweep in all changes implemented at the time of the build? When do you build from revisions in the mainline of the version control system? When do you build from revisions in a branch?

No matter what type of software you develop, from internal IT applications to web applications to commercial software packages, fixing bugs following a release is part of the software development lifecycle. Realistically, software maintenance can be a project by itself. However, the process of merging production fixes into the development codeline is an equally significant effort. Unfortunately, the effort required to merge production fixes into the development codeline can be grossly underestimated and improperly staffed even by organizations that practice otherwise good software development.

The IDE has emerged as the de-facto development tool in many Java shops. As the Java IDE evolved, team support became an important aspect of the tool and plays a prominent role in the popular Java development environment, IBM WebSphere Studio Application Developer 5.0 (WSAD). The clean design of the SCM interface to WSAD means configuration managers do not need to craft a custom solution to integrate their organization’s SCM tool with the IDE.

Since the establishment of software configuration management (SCM) as a formal engineering discipline, the written SCM plan has been accepted as an essential document for software development organizations. SCM engineers regard the plan as a description of the CM process and an enumeration of the CM procedures to be used on a project or program. Writing an SCM plan is often viewed as the first step in establishing the CM process for a new software development effort.

What words come to mind when you mention “parallel development” to software developers and projects managers? Complex and painful may be the typical response. Yet parallel development need not be difficult and laborious. By adopting an appropriate branching and merging strategy, parallel development can be straightforward and efficient.