wiki-software-developI have been doing Build and Release Management for the last 10 years, and I often see questions or posts on the future of Build and Release Management.  What’s next for those doing Build and Release Management?    That’s a question we keep seeing.  

Years ago, Build and Release Management emerged out of necessity to have a consistent way to deploy the changes from Dev to Test, then Test to Production.   For those of us that use to develop software solutions, you will understand that a lot of the emphasis was on building the solution, not the deployment technology.  Even back when Windows development came along, may developers would develop their DLLs, Exe’s and not take it the next step to create a MSI, Installshield or Wise Installer package.  So, what you were left with was a manual way to copy and register the newly developed software.   Creating the installation package was always the secondary mission.  I have seen the same happen with Web Applications, where the developers would spend hours on creating the Java Web Application, but not think of a way to deploy it consistently. The process was manually staging the application by file copy as the normal operating procedure.  The use of build and deployment scripts was an extra step, and unless you specified that in the Statement of Work, so be it!    So, then came along new technology like ANT, Maven, and other Software Configuration Management Software (SCM) deployment tools.  We’ve even wrapped up that up further with wrapper automation like ElectricFLow by ElectricCloud, or used automation technologies like Jenkins to help make the job go easier.  So, what’s next for Software Configuration Management, and what’s next for Build and Release Management where we look for consistency between the environment deployments?

Enter the new era of Infrastructure as a Service (IaaS), and Platform as a Service (PaaS) to add a to twist.  The combination of these is where I think the Build and Release Management is headed next.  When you have the ability to spin up a full LAMP Stack at Amazon Web Services (AWS), or a DB services like RDS at Amazon or other providers, the whole bottom tier is covered with regard to SCM.   The only thing you need to be worried about is building upon that foundation.   There lies the problem.  How do we consistently layer on the software application portion of the stack using AWS or have the same control if you plan to host it internally.  The direction for data centers nationally lies in the AWS model or the ability to stand up IaaS as rapidly as possible.  Gone, will be the days of waiting weeks  for Infrastructure components.  But that is not enough to cover SCM.  You still need the combination of Infrastructure and the software component in order to complete the stack.  Well, I am greedy, I am also thinking you need the data too.  Let’s take WordPress as an example. You can spin up the LAMP stack with a base WordPress environment, but what about all the customization a user does to make it a complete application? If you know WordPress, that configuration is saved in the database, plus the files you added.   Wrapping up a consistent package is really the goal of SCM. And, I believe the Build/Release function will now morph to standing up not only the application, but also the Infrastructure and platform on demand.

Enter new Tools like Chef, Puppet.  This technology focuses on Software Configuration Management, but to be honest, you still need an orchestrator looking above the stack to make sure you can provision the full stack, plus the configuration of the user’s customization.    So, while Puppet and Chef can get you 90% of the way, what is above these 2 to get you 100% of the way.   That’s full Software Configuration Management Orchestration.   This is fairly new territory because as you have seen from doing some research, most of the direction is looking at rapid infrastructure provisioning with some basic software application, i.e. LAMP, or WordPress, or Drupal, Joomla,  But, what i am referring too, is all of that plus the customization’s and configurations that make it complete, ready to publish.   As you know, the Build and Release Manager’s goal is to promote what was tested to Production. That means we look to promote exactly byte-for-byte the same configuration and data models, except for specific environment attributes.  So, therefore, we now need to look at Data Sets and these data elements we can export and import into the Software Configuration Library.What is nice about Chef is the ability to store their json and script files to store the configuration. That can be put in source code control.    The focus has to be on your software configuration management practices for as much as the stack as possible. In addition, we can now control the configuration of the infrastructure and then deliver the full application.   That’s the difference and gets us back to the start of this article.  The automation of the full end-to-end process is something that has to be something that the development teams need to invest to get the full value of the service.  The IT Organization needs a full orchestration tool that can assemble and drive the full application stack.   It also needs the maturity of the development process that they have mature build/deploy processes.  If your organization is already doing build/deployments, then the only thing you need to encapsulate is the IaaS component, or possibly the data and user configuration component.  That’s where Chef/Puppet and even Automation Tools like Jenkins and ElectricCommander help out.    The full end to end process to encapsulate the infrastructure, application stack and the data  is the focus of the future Build and Release Management.   The ability to organize this from beginning to end is the future for us in Build and Release Management.

William is a certified Practitioner in IT Service Management for Release and Control, with experience in Global Change, Configuration and Release Management.  He is also an experienced Project Lead in delivery, IT Automation, systems implementation, build, deployment and release practices.

This article is in a series of articles around IT Change, Configuration and Release Management using ITIL’s Foundation Framework.  See my full profile on LinkedIn:v

Copyright. William Mantz 2018. All Rights Reserved.
Images used with permission from GNU, please see Image Description or Alt Tags for attribution.




\\*picture attributed to Creative Commons License,




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s