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.
Calling Rational Team Concert an old dog isn’t fair – it’s only just over 5 years old – and I mean it in the nicest possible way in the context of the Jazz Jumpstart team being “old”, and the Rational Emerging Technologies Team, well, “emerging”.
Anywho, as is my wont, I was going through what could be in the next CLM release, noticed the bit about Rational Team Concert Build and IBM UrbanCode Deploy and decided to try out this “emerging” feature with Rational Team Concert 4.0.5 RC1.
Update: Vamsi pointed out that http://cars.flashmx.us/makes no longer works so I’ve updated the post to use http://www.w3schools.com/xml/cd_catalog.xml instead. I’ve also attached that file here in case w3schools drops it as well:-) Note that WordPress doesn’t allow XML files to be attached so change the extension to .xml before using it.
ClearQuest has this concept of “stateless record types” , which are basically one way to store “tables” of values to be looked up and used usually with “stateful” record types. An example of such a stateless record type is “users”, which stores user details (username, full name, email, privileges etc). This is quite a useful concept and all users can do to these stateless records is Submit, Modify, Delete, and Import.
As usual what is a good thing is easily abused. One way CQ’s stateless record types are often abused is they are used to duplicate information that is already stored elsewhere. The “abuse” occurs because the “elsewhere” is the actual source of truth for that information and it becomes a headache to keep the the values in synch.
RTC doesn’t quite have this concept of stateless record types though you can simulate this by setting up work item types that only have a few states and a few actions. What I prefer is the idea that the data should remain in it’s original source of truth and used from there as required, without messy copying, duplicating and synchronising. Of course there are potential performance implications with retrieving remote vales and problems with data sources not making required data available but in the main this is a better way.
We’ve always had pets since I was very young: dogs, cats, cows, goats, rabbits, a fox that escaped and wiped out the rabbits; even a “Bambi” that disappeared, though we had some fantastic chilli venison a couple of nights later. “Popo” was one of a long line of dogs we’ve had; a mostly unremarkable Pomeranian; memorable for the fact that the day he was given to us, he was so terrified of his new surroundings and all us kids squealing over him that he jumped up on mum’s lap and did “his business” on her:-)
In a previous post I showed how to get the Android Platform source into RTC as components and also how to use load rules to ensure consistency in loading (extracting) the source from RTC. There are a couple of articles on Jazz.net that go into loading content from RTC in excellent detail (https://jazz.net/library/article/1016 and https://jazz.net/library/article/1015). The question then came up on how to set up RTC Project and Team areas to implement a very specific access control scheme for both the SCM and Work Item capabilities for teams doing Android development.
My previous post on populating and testing a large Jazz repository could be tested with JMeter was primarily focused on the Work Item capability in RTC. I also needed to populate the repository with lots of SCM data and rather than take the “dumb” (ie. random) path as I had done with the Work Items, I wanted to use a more “realistic” set of artifacts.
I didn’t have to look very far: the Android platform which has apparently become the leading smart phone platform (canalys.com) and 300+ million Android-based smartphone activations (prweb.com). There are already a bunch of posts on Jim’s blog and Jazz.net on how to use RTC for Android app development, so I turned my attention to the Android Platform source, from the AOSP, which proves to be a different kettle of fish when it comes to SCM.