Getting the Most out of Your UrbanCode Deploy Implementation

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.


3 thoughts on “Getting the Most out of Your UrbanCode Deploy Implementation

  1. All this guides are ok when you build your environment from scratch and servers and applications can be configured from scratch to use templates/plugins so everyone follow the rules from the start.
    When using single template/plugin for a deployment might be treated as a requirement that is known before the application gets into production.

    When entering the real life scenario when you want to use udeploy on an already setup environment with several development teams, several administrators, and several a bit different rules how the applications are build, installed,tested and run using single plugin/template is a risky thing. It can fit for some parts of applications, and brake others.

    Flexibility is a must. Later if you have time and money for changing applications deployments/runtime config to conform with the standards of one only true plugin/template and more time and money to test such a system with new deployments (via plugin template) concurrently with “old” development/deployment/production process, then you might get lucky to have a deployment system that is using single template/plugin scenario.

    • I totally agree with your comments here. Bringing in a tool like UrbanCode Deploy to an existing enterprise is not a silver bullet and does not magically fix all problems. And yes I agree that there are many many years of existing processes and techniques that are unfortunately typically unique to each application. However, in my experience, UrbanCode Deploy is being brought in to some enterprises that have recognized that this is a problem and this tool is a piece of the solution. Organizations are beginning to make themselves aware of the costs (time, quality, resources) of each application being a one-off. There are sometime sweeping efforts to standardize on deployment platforms and deployment and build processes. And some organizations are even putting time tables in place and “charging” application teams if they have not converted their application over to the standard by a deadline. This is pretty risky forward thinking and it takes some guts to convince the business side of the enterprise that taking a hit now is worth it in the long run, but there are some enterprises that are doing just this.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s