Your company is invested in UrbanCode Deploy. Maybe you are an administrator of the solution, or maybe you are onboarding your application to the tool and figuring out where to begin. UrbanCode Deploy is a framework more than anything else, and there are some patterns and antipatterns in this framework which I’ve seen that significantly impact quality of life. This is an attempt to call those out and not give too much detail. 

  1. Do use templates. This one is pretty obvious. Consistency and conformity across application deployments is the main reason companies invest in UrbanCode Deploy. You can have as many templates as you want, but always question the need to create a new one or fork an existing. Templates also rapidly accelerate the creation of new components and applications.
  2. Do review this whitepaper to get a sense of how UrbanCode Deploy performs under controlled conditions. The whitepaper discusses the impact of factors such as agent relays, artifact caching, concurrent deployments, and agents coming online simultaneously.
  3. Don’t forget about everything that comes with hosting a mission-critical application like UrbanCode Deploy on your own: valid architecture, proper infrastructure, a disaster-recovery plan that includes reverse replication, monitoring, incident reporting, and regular backups. See this presentation from InterConnect 2016 for several good tips.
  4. Don’t create objects like “test component” or “dummy process” or something else meaningless. If you are starting out and learning, pick a real use case. Model a real application with real components. Otherwise you will confuse yourself and also pollute the environment. Most objects you delete are not actually removed from the database.
  5. Do maintain an orderly resource tree. The resource tree should have a finite set of top-level resource groups and there needs to a grouping strategy (anything, really). Clean-up unused resources.
  6. Do think about enabling this setting under System Settings once processes are stabilized:

Do and Don’t – Comment for Process Changes

  1. Don’t map the same component resource to multiple environments. You may use component tags in the resource tree across environments in different applications if you aren’t sharing components across applications.
  2. Do take a second especially if you are an UrbanCode Deploy administrator to set your Default Team Mapping preference under My Profile. This is how your newly-created objects inadvertently get mapped to all teams.
  3. Don’t create different components just to run different processes against the same artifact. This is plain wrong.
  4. Don’t create components just to run processes. That’s what generic processes are for. Components are supposed to be something you produce for an application. They are generally versioned. They can also be used to hold configurations in the resource tree (via component resources and Resource Property Definitions) and in this case, you may actually want a group of related processes in the component.
  5. Don’t have applications with too many components. How many is too many? Personally, I think a thousand components in a single application is outrageous. Perhaps in a pure microservices architecture this is feasible, but I can’t imagine coming close to that otherwise. 500 components in an application is a lot.
  6. Don’t rely on ad hoc resource properties. These are properties that are defined ad hoc by a user on the Configuration sub-tab for a resource. If you have important configuration that should be specified at the Resource level, then create Resource Property Definitions (AKA Role Properties) on the components that require the configuration.

Do and Don't - Resource Property Definitions

  1. Do use properties strategically. Properties and property definitions are an integral part of UrbanCode Deploy. Whenever you build a component process, think about where/how to use properties over literal values in your steps when it makes sense. Component processes should be reusable, agnostic to applications and environments, and resilient.
  2. Do use Component Version Cleanup and Deployment History Cleanup.
  3. Don’t keep snapshots around for too long after they are no longer needed. Component versions in a snapshot are excluded from cleanup policy.
  4. Do use specific plugin steps over generic scripting steps whenever possible. Plugins are easy to maintain, encapsulate best practices, and ultimately reduce risk.
  5. Do become active in your favorite plugin repos in the IBM UrbanCode GitHub org. The team at IBM is in the process of moving all plugins to GitHub, so open issues in the plugin’s repo and contribute there.
  6. Do go to the forum first with technical questions because in many cases, someone has already done “it” or asked. Spend some time searching through existing posts before creating a new one. Tag your question urbancode.
  7. Do plan to upgrade ideally twice per year. The team is moving to a rapid release cycle and new features and fixes are regularly made available.
  8. Don’t forget to clean the audit log regularly!

Happy deployments!