Filed under: Automation, — Tags: Automated deployment, Automation vs Manual, Gall's law, KISS, Manual deployment, Puppet — Thomas Sundberg — 2015-02-28
I had a discussion about an automation task that I have implemented the other day.
The task is about automating the deployment of a web application on top of a JBoss. The application is old and we are not allowed to do any improvements at the moment. The instruction is, deploy it as it is at the moment. You will be allowed to do improvements later when you are able to deploy the application smothly.
We are using Puppet to orchestrate the deployment. The application is stored in a large zip file that is available from a repository manager.
I used Puppet for some of the parts and then I implemented a shell script that does the rest of the steps. That is downloading the distribution, unpacking it, placing the files at the proper locations, set the proper rights on directories, add it as a service and so forth.
A colleague commented that this is a manual installation but without any human interventions except starting Puppet. I have a hard time to understand which part of the process described above that isn't automated. We are able to deploy the application many times on different hosts, sometimes many times a day. What is it that isn't automated?
It is true that the process described above is all the manual steps that would have been necessary. It is also true that it would not be very hard to do it manually, except for the fact that I might miss a step or two. The documentation of the installation process is not an essay on a Wiki, it is in a version controlled Puppet manifest backed with a few files. The files include a shell script that does the actual job.
The interesting question here is: "When does a manual deployment become an automated deployment?"
My answer is when all you have to do is to run a script, a script that can be scheduled.
The process implemented is very close to a manual deployment and it can, and it will be, improved. The improvements will, however, be done in small iterative steps. I want to take baby steps in order to not break something that works. The progress may seem slow when I do it, but I will always know that the process isn't broken. I can always revert the changes if I break something.
A friend of mine tried to build a complicated thing once and failed. He called me and had some questions. I asked him "How did it go when you did it manually?" It turned out that he couldn't do it manually and therefore not automate it. Before you can automate anything, you must be abe to do it manually. Automation is usually more complicated compared to doing it manually.
The distribution for the application we are installing will be replaced with an RPM package and all of a sudden, the Puppet part will be possible to transform from a complicated process to a simple process. The end result is very likely a Puppet manifest that installs the RPM and ensures that the service is started, nothing more. That should be 10 - 15 lines of code in the Puppet manifest.
This follows a new favorite of mine, Galls Law Another way of saying something similar would be KISS, Keep It Simple Stupid.
This is exactly how I want to develop things, start out small and make it gradually more complicated, if needed. But starting with a simple system combined with automated tests allows me to always know that it is still working and that it is still solving the problem I am trying to solve.
Building something complicated is difficult. Don't do it if you can avoid it. If you can't avoid it, at least make sure that all components are simple and the complexity only shows up when the components are combined.
I would like to thank Malin Ekholm, Adrian Bolboaca and Alexandru Bolboaca for proofreading.
RSS