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.
A mild case of paranoia. Or too many episodes of Breaking Bad and Walter White Syndrome. Whatever it is, I feel like Darrell Schrag’s been peering over my shoulder (across all of 9000+ miles) as I’ve been working on this post, tut-tutting at some of the wrong turns I’ve taken. Though Darrell had no idea I’ve been writing this post, “Getting the Most out of Your UrbanCode Deploy Implementation” might well have been directed at me: this post is a kind of a case in point, at least of his advice on using/creating plug-ins.
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.
About this time last year I wrote a couple of posts on using JMeter against a Jazz server. A few days ago Gary posted a comment about “making it possible to kick off JMeter tests from RQM and get results sent back so that they can be managed inside RQM” and it stuck in my head, so here’s how it can be done.
RQM allows arbitrary tools to be executed as “test tools” via one facility : the Command Line Adapter. It’s pretty well documented in the Infocentre and Article 809 on Jazz.net . So it ended up being a (mostly:-) straightforward exercise. My requirements were simple: execute a JMeter testplan from RQM and get the appropriate result (PASSED, FAILED,…) to be set for the RQM Test Result. The result would depend on the result of executing a HTTP Request and I’d consider it a bonus if I could set a Custom Property on the RQM result with the value of the HTTP Response Message.
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:-)