The question about the differences between build and deploy always comes up when I am interacting with my customers. Because of the frequency and the confusion around this topic I felt I should write a post about it.

I will be publishing two posts based on this topic. I will also be releasing in the near future a series of posts along with youtube videos to discuss DevOps in more depth (in the meanwhile, feel free to download the free E-book DevOps for Dummies). This post discusses the challenges in differentiating between the build and the deploy processes. I will be providing you with my perspective on why we should have a clear separation between the process of building (compiling) an application and its deployment to target systems. In my perspective, these two activities fall into two distinct and separate domains. However, collectively, they play an important role in achieving a DevOps Software Delivery Pipeline.

Build and Deploy: Compare & Contrast Part I

Differentiating between the build and deploy processes has been fuzzy and often times, many developers do not distinguish the differences between these two activities. This is because, throughout the history of software development, the scripts used to build an application also included the necessary steps to deploy it. They usually refer to them as “build and release” scripts. They may be written in various scripting languages such as Perl or JavaScript. They are often obscure and do not provide good visibility into the build and deployment processes. Furthermore, debugging them is time consuming and often challenging.

Over the years, several build solutions such as Jenkins, IBM Build Forge, IBM UrbanCode Build and others were released to the market place. These tools automated the build process. They provided the developers the capability to build their code often in an efficient way with better visibility into the build process. In this agile world, we refer to this DevOps activity as “continuous development & continuous build”. This new capability got us closer to achieving the DevOps “Software Delivery Pipeline” goal. However, even with these automated “build” solutions, the fuzziness between the build and deploy activities still existed.

Figure 1. Click image to zoom in

Figure 2. Click image to zoom in

In this new technology-centric world, software became more complex. It evolved from being monolithic to distributed applications. These applications are made up of multiple components and target different environments (e.g. Dev, Test, Prod, Cloud). Application components can be deployed to different heterogeneous servers (e.g. a database component can be deployed to a Database Server, and the application component, such as an EAR file, can be deployed to an Application Server). Furthermore, the architecture of the distributed applications has further evolved to “hybrid” applications. These types of applications are composed from Microservices running on the Cloud requiring a different build and deploy approach (I will be publishing a post on Microservices in the near future).

[AdSense-C]

The advent of the Cloud and related technology, flexibility and portability of these hybrid applications on where they get deployed, whether on premise, public cloud, private cloud or bare metal became critical. It became apparent that the packaging and deployment processes for such applications require new strategies and the underlying issues with mashing up the build and deploy processes started to surface.

In my next post titled “Build and Deploy: Compare & Contrast Part II“, I will be discussing the delineation between build and deploy along with the rules for efficiently deploying application components to various target environments.

About the Author

Sami Joueidi holds a Masters degree in Electrical Engineering and an Enterprise Architecture certification from 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.