Open Source Continuous Deployment: Easier Than You Think

Years ago I worked for a medium sized software company that had networking problems that would bring the company's communication capabilities to it's knees several times a month. An experienced networking engineer was at the helm, and we felt lucky to have him whenever these outages would occur, especially considering that networking microcomputers was still in it's relative infancy.

Sneaker-net was quickly becoming obsolete and we were on the cutting edge of the newest whiz bang wired-to-the-gills system that allowed us to not only email each other, but also send emails to people (gasp) outside of the office. Of course we began to get used to this new blessing and would panic whenever it was lost to us. One day an announcement went out (ironically via email) that our network engineer was leaving us for greener pastures, and we immediately began to imagine the worst. Where would we find a replacement for this genius who had seen us through the worst of times?

Thankfully several people applied for the position and the powers-that-be hired the one they thought was the most qualified, and we all crossed our fingers. After about a month, and a few typical outages, we began to notice that they came about less and less frequently, until finally they stopped almost completely. It began to dawn on everyone at that point that perhaps our former colleague wasn't as brilliant as we had thought. This new engineer really knew networking, ate and drank it, could do it in his sleep. That other guy, what was his name again?

Since those days, any time I see a friend, relative, or a team I'm part of settling for less than they should out of ignorance, laziness, or simply being trapped in their own comfort, I'm reminded of the engineer who everyone thought was doing a great job but was really doing nothing more than constantly patching a leaking boat.

Writing scripts in one's favorite language for performing software deployments will certainly get the job done, but how efficient is a such a process? One-off scripts are OK for today's deployment, but can we use it again tomorrow? Allowing employees to create such scripts often allows each employee to be an island, and the willingness to share scripts often depends on personalities and/or individual organizational skills ("I did something like that last month, now where did I put that?").

Enter Chef and Puppet, which are really efficient at managing the lower level I.T. stack. RPM-centric and re-useable, they provide a great service, although they still fall short when it comes to managing the application stack. Many organizations are attempting to use these tools for managing the application stack, and are under the impression that this is as good as it's going to get. Writing an RPM for deploying an application is way more work than it should be. What is really needed to deploy large software projects at the enterprise level is an efficient, robust ARA tool.

So, managing the application stack can be performed in one of three ways:

• Scripted in one's favorite language or the agreed upon language of the team.
• Creating an RPM.
• Using an Application Release Automation tool such as DeployHub, which not only helps manage the application stack, but can also be integrated with products such as Chef, Puppet, and Ansible in order to manage the I.T. stack as well. 

DeployHub is Open Source, and is hosted on GitHub for quick access. It does not require end target agents, making it much easier for testing and production teams to adopt. It can be found at deployhub.org.

DeployHub can be used by Development teams in order to easily package and deploy applications to development environments. Testing and deployment teams can really take advantage of DeployHub's advanced features that allow for the packaging and deployment of applications dynamically into different environments which contain different types of end points, with individual component in the application targeting each of one or more end point types (database servers, application servers, routers, etc.).

Environment variables allow for dynamic interaction with individual endpoints, including the editing of configuration files via scripts. Version jumping is possible which allows production to catch up with the testing team's latest version, even though they are several versions behind.

A calendar allows for automatically deploying a given release on an exact date and at an exact time, and sections of the calendar can be blocked out to prevent teams from stepping on each other's toes.

All in all, an Application Release Automation tool such as DeployHub is leaps and bounds ahead of what most companies are using to deploy software these days. Eventually every company that deals with large software deployments, which is to say every large company, will have to get on board. If they wait too long they might just end up looking back and wondering why they spent all that time patching a leaky boat.