In the concluding paragraphs of my last post, UrbanCode Deploy with Patterns: Hello World ,I briefly compared the UrbanCode Deploy with Patterns (UCD+P) use of OpenStack HEAT Templates (HOT) for blueprints with my own simple XML blueprint for vSphere compute resources. In the past week a Fix Pack was released for UCD+P which adds initial support for provisioning to VMware vSphere infrastructure. So in this post I’ll do a “Hello World” -style example of connecting UCD+P to a vCenter 5.5 server, provisioning a VM on it and deploying multiple UrbanCode Deploy (UCD) components to the VM.
Having hooked up UrbanCode Deploy with Patterns (UCDP) to OpenStack and UrbanCode Deploy (UCD), it’s time to take a look at a “HelloWorld”-style example. I’ll work through a single-server UCDP blueprint, deploying a single UCD component to it.
One of the neat features of UrbanCode Deploy with Patterns (UCDP) is the ability to deploy blueprints to multiple clouds. Last time around I wrote about hooking up UCDP to an OpenStack cloud. In this post I’ll look at how to setup UCDP to connect to Amazon EC2.
UrbanCode Deploy with Patterns (UCDP): a mouthful right? A pretty neat and powerful mouthful though. Consider theses two posts: Cooking up deployments on stacked clouds and UrbanCode Deploy with vSphere and Chef. UCDP makes it simpler and easier to carry out a bunch of steps detailed in those posts. Before I get into the details, let me first quickly go through how to install UCDP and connect it to an OpenStack setup.
Remember that old,old post of mine: HTTP Filtered Value Set Providers and dependent enumerations ? Probably not. It goes into a little feature of Rational Team Concert that makes it easy to avoid having to duplicate data from external systems that RTC might need to integrate with. UrbanCode Deploy can do something similar for value sets for process properties.
In a previous post (Cooking up deployments on stacked clouds) I looked at using UrbanCode Deploy with OpenStack and Chef. I showed one way of creating a stack from a Heat template, injecting the UCD agent and Chef into one of the newly provisioned servers, cooking a Chef recipe and deploying an application on it. This time round I look at how to do almost the same thing with VMware vSphere.
Managing database schema changes can be a non-trivial task. Very often the danger associated with potential bad changes being deployed makes DBAs very protective of their territories and resistant to changing tried and true methods.
However, the push towards more Agile development methods, adoption of DevOps practices and Continuous Delivery capabilities is including database development in its embrace; the last 10 years or so has seen a lot of work towards aligning database development with application development best practices. That said, there are probably quite a few organisations out there where the normal practice for deploying database changes is to use some sort of “list of instructions” and various GUI DB tools with maybe some scripts thrown in. Even adopting practices such as SCM and CI can appear daunting.