I think it is fair to say that almost every customer that purchases or even investigates the use of UrbanCode Deploy, or any continuous deployment solution, has already spent a ton of time building deployment scripts, build processes, and “best practices” of their own. And typically these things do the job, albeit most of the time not the most reusable and transparent solution. So their first approach to implementing a continuous deployment solution is to wrap their existing scripts or processes. After all, they work and do the job, why not reuse them? Beside, there are some other features, like the UrbanCode Deploy inventory, that are valuable in and of themselves. This is considered the low hanging fruit implementation of something like UrbanCode Deploy. Simply wrap what you have and you are off and running.
But if you peek just a bit into the future, this is not the best approach. The following are some common shortcuts that people take instead of implementing with future benefits in mind.
- Simply executing shell scripts to perform deployments – this is the quick and dirty solution, but misses out on a number of valuable capabilities. First, you should take advantage of as many existing plugin steps as possible. Plugins offer canned and consistent execution of a single function. Reusing a step that you know works insure that you don’t have random errors across different deployment processes. I would even argue that you should be on the lookout for abstracting process steps into custom plugins. If you think there might be some reuse of a step that you have scripted, find a way to wrap it in a plugin step.
Also, upgrading a plugin upgrades the use of those plugin steps everywhere in your UrbanCode Environment. If you find a better way to execute a step, upgrade the plugin and all deployment processes that use that step get the new and improved way.
- Not taking advantage of templates – It is understandable that you would want to build a deployment process and test it first before you would consider it the default way. However, you should quickly abstract processes into templates to insure best practices are followed. If you have developed a tried and true way to deploy apps to Tomcat, for example, then you should provide a way for each and every Tomcat application to take advantage of your success. Creating component templates that encapsulate standard processes is something that should be put at the forefront of an implementation effort.
- Not taking advantage of UrbanCode Deploy code station – Code station is UrbanCode Deploy’s internal component content storage mechanism. Many customers already have some type of build target repository (i.e. Nexus) and don’t see the need to replicate this storage also in UrbanCode Deploy. But code station is more than simply a repository. It also hashes each and every file that makes up a component. This provides an easy mechanism to know if files have changed when a new version of a component is provided. A key value of UrbanCode Deploy is that it only updates the files that have changed, and you don’t need to do anything to enact this feature. It accomplishes this by comparing hashes. If the file has not changed and the inventory indicates it already exists, then there is no reason to push it again. Of course you can override this and push it anyway, but why would you?
- Providing only changed elements to UrbanCode Deploy – many customers have been bitten in the past by overwriting code that works with code that doesn’t. Almost everyone has a story that involves many hours of hunting for the cause of production problem only to discover that something that worked got overwritten by something that was broken and that element being overwritten wasn’t even supposed to be affected by the changes. The natural knee-jerk reaction to this is that only things that you believe have changed get deployed. The mentality goes way back to mainframe days. Providing complete builds to UrbanCode Deploy allows you to take advantage of the code station feature as described above, and it allows you to always be able to deploy any version since UrbanCode always knows how to get from full component version to full component version.
Most implementation of a continuous deployment solution start out with a quick win and hopefully everyone can be back on to their “regular job.” But by spending a small amount of time to do things right from the beginning, there is a lot of value to be had in the future.