In my previous post titled “Build and Deploy: Compare & Contrast Part I“, I discussed that differentiating between the build and deploy processes has been fuzzy over the years. With the advent of the Cloud and related technology, the underlying issues with mashing up the build and deploy activities started to surface and new deployment strategies were needed.

In this post, I will be discussing the delineation between build and deploy along with the rules for efficiently deploying application components to target environments. I will only be focusing on the high-level principles of software deployment. A good reference on the topic is the Free E-book “Application Release & Deployment” for Dummies by Eric Minick, Jeffrey Rezabek, and Claudia Ring.

I will get into deeper details about software deployment in my upcoming posts on DevOps.

Build and Deploy: Compare & Contrast Part II

Figure 1. Click on image to zoom in

Figure 2. Click on image to zoom in

The picture depicts the “continuous development” cycle that a typical developer goes through to create an application component. This cycle is rapid; the developer is constantly making changes to the code as it relates to a specific release, invoking a personal build, deploying the code to a local environment, testing the changes, and continuously getting a feedback. The cycle repeats itself and based on the continuous feedback, when the developer is satisfied with the code, the component gets promoted downstream into the delivery pipeline. With a distributed application, this cycle is duplicated for each of the application components.

[AdSense-C]

As the build of all the application components is complete, the application is deployed to an integration stream and eventually to production as depicted in the picture. Basically, the application is deployed (promoted) downstream from one environment to another through the various stages of the software delivery pipeline.(e.g. QA to Integration Testing to Performance Testing etc.). The promotion of the application from one environment to another is actually a deployment versus a build activity, re-enforcing the fact that these two activities must be independent of each other.

Figure 3. Click on image to zoom in

The diagram depicts application deployments to various target environments. As an example, let’s consider an application with two components (database component and an EAR component). In the case of the Dev environment, all the application components will be deployed to a single server. In the case of the Test environment, the deployment of the components is split between two servers. In this case, the database component will be deployed to the database server and the EAR component will be deployed to the application server. The Integration, Prod and Cloud environments introduce more complex environments requiring a more sophisticated deployment activity.

Although it is possible to achieve software deployment via scripting, or by extending the build tool capabilities, the separation of concerns between the build process and the deployment process has to be maintained.

Figure 4. Click on image to zoom in

The diagram depicts a summary highlighting the major differences between the build and deploy processes. The products used for this comparison are IBM Build Forge and IBM UrbanCode Deploy for no specific reason. This comparison can be applied to other build and deploy solutions.

I hope this post demystified the question about the differences between build and deploy. I will catch you at my next blog.

About the Author

Sami Joueidi holds a Masters degree in Electrical Engineering and an Enterprise Architecture certification form Carnegie Mellon. He has over 20 years of experience as a technical leader of complex IT projects for Fortune 500 firms, in diverse roles such as Systems Integrator, DevOps, Cloud Architecture, Enterprise Architecture and Software Development & Release Management. He guides customers on how to leverage the latest technology trends to their advantage and helps them with their Cloud adoption strategies.

© Sami Joueidi and www.cafesami.com, 2015. Excerpts and links may be used, provided that full and clear credit is given to Sami Joueidi and www.cafesami.com with appropriate and specific direction to the original content.