Automating Commercial Off The Shelf Software Deployment

I currently work for a large enterprise. Our little corner of this company has been very successful in implementing and rolling out build an deployment automation across all of the applications that we work with. This has arisen out of the fact that a lot of our applications are fairly simple JVM based apps with an embedded container. The DevOps team that I work with has created a simple pattern for building, packaging and deploying these apps that we then apply to future projects that are of the same nature. When we find improvements to the existing method, we then work with the teams still on the legacy pattern and apply the change to their process as well. One of the unexpected outcomes of this success is that we are now having teams approach us who are currently not doing any automation and asking us to work with them on automating their build, packaging and deployment process.

These requests always put us in a bit of a bind. We have been successful due to the nature of the applications we are working with. JVM based apps invariably are simple to package up and deploy – especially when there is an embedded container and the application is therefore completely self-sufficient. When a new team comes looking for our help, overwhelmingly they are developing on a proprietary platform that does not lend itself to automation as well as a custom solution does. In this first post, I will discuss the strategy that we take when we approach these teams and how we know from day one if we are going to be successful. In the next post I will review one of the successes we have had in working with these teams – automating the packaging and deployment to an IBM DataPower instance.

This post is going to be relatively short and sweet. If you are trying to reliably automate a Commercial Off The Shelf (COTS) product, you need either an API or a command line based solution that allows you to:

  • Stop/Start/Restart/Reload the running processes
  • Remove and clean the currently deployed application
  • Install the new application
  • Update environment specific information
  • Load any application specific data packages or database migrations
  • Verify the status of the application post deployment

If you don’t have an API or command line that provides this functionality, you are not completely out of luck BUT, in my experience, any solution that includes any of the following workarounds:

  • Driving the GUI via a tool like Sikuli
  • Capturing and templating HTTP calls (POSTS/PUTS) to a web based admin console
  • Reverse engineering the application deployment in the DB or filesystem of an application

will require a full time team to maintain and fix as it will break frequently, will require a lot of re-work when a new version of the COTS product is deployed and will not account for any edge cases. In other words, it is doable if the business insists, and will even provide some benefit but don’t expect that you can ever walk away from it without worrying about it breaking. We only agree to work with teams that have a tool that provides API or a command line based interface that fulfills our criteria. We are not in the business of creating a solution that can’t be maintained by the development team that owns the product and so any solution that uses a custom set of tools to do the automation isn’t supportable.

My next post will focus on the work we did automating the IBM DataPower deployment for 2 teams that we work with. This is a product that does provide the necessary API driven interface to manage the deployment remotely but required a custom solution to be implemented to build the framework necessary to support Continuous Delivery for the teams using the platform.