In my last post there’s a tidbit about overcoming an access problem using an agent (or the CLI). That was with UCD 6.0. No need for this with the upcoming release of UCD 6.0.1 : see Eric Minick’s post about Plugins for Artifact Sources.
So as in my post an agent is installed on the packaging server but instead of having to define a process using the Create Versions step, simply configure the component to use this agent to run the appropriate Source Config type. Here’s look at the new configuration settings:
Option 1: Use the system’s default version import agent/tag
Selecting this means the Agent or Agents specified in Settings > System > System Settings will be used. Either a specific agent or a group of agents with a tag can be specified here.
Option 2: Import new component versions using a single agent
Specify a single agent to always use for this component rather than the Agent(s) specified in the System Settings.
Option 3: Import new component versions using any agent with the specified tag
Specify an Agent or Agents with a specific tag to always use for this component rather than the Agent(s) specified in the System Settings.
How often an agent checks for new versions to import is specified in the “Automatic Version Import Check Period” System Setting. Or a manual import can be initiated using “Import New Versions”
There is now an additional section in the Versions tab for Components that shows if there are any currently executing imports, which can be cancelled if required.
The import history for a component can be viewed its Configuration tab.
Now since the source configs are implemented as plugins, implementing a custom importer that, for example, constructs custom version names or imports bits and pieces from a complex directory structure, is as simple as writing a new plugin.
UrbanCode 6.0.1: New and Noteworthy
The first of a series of posts by Eric Minick on what’s coming up in the 6.0.1 release
A quick couple of UrbanCode Deploy tips, one on getting the SSH config right and the other on using the UCD agent and/or CLI provide an access work around.
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.
Having successfully gone through installing WebSphere and creating Base WepSphere profiles using Urbancode Deploy (UCD), the next logical step is to use the profile in some way. Here’s where the Application Deployment for WebSphere plug-in comes in. There are a bunch of steps in this plug-in that help with a whole range of WebSphere tasks.
After creating generic UCD processes to first install WebSphere and then create standalone (Base) WebSphere profiles, I wanted to turn my attention to applying the second process to WebSphere ND. I’d already written about creating a clustered CLM setup using the command line in my old post Clusters of CLM applications without a GUI so this should have been pretty simple. It occurred to me that the steps in both the processes from the last two posts could actually be steps in a UCD plug-in, just like the Application Deployment for WebSphere plug-in. Of course I’ve never written an UCD plug-in before and my experiences with writing RTC extensions had left me with the distinct feeling that this kind of thing was not for mere mortals like me. This was the domain of gurus and gods like Ralph Schoon. However, the thought had been planted in my head and, like in Inception, I could not help but follow it through.
Following up my last post, I describe a simple sample UCD process that helps with automating the creation of Base WebSphere profiles. I hope to attack setting up WebSphere ND infrastructure at some later time. As with the previous post the intent is not to create a “perfect” process but one that gets the job done while exploring some other aspects of UCD.
I seem to gravitate to WebSphere like a moth to a flame. I just finished co-authoring a couple of CLM Deployment Wiki topics (Configuring enterprise CLM reverse proxies: WebSphere 8.5 ND Proxy & CLM deployment automation for WAS – departmental topology) both with my co-conspirator Indradri Basu. Incidentally Indradri was also my sounding board for Clusters of CLM applications without a GUI.
So I guess it was natural that while figuring out some of UCD’s features, I looked at automating the WebSphere Install process.
It’s an IBMIM world. Or becoming one. Resistance is futile. Urbancode Release (UCR for short) is no exception. The new release uses IBM Installation manager, which of course I know and love from doing oodles of CLM and WAS 8.x installations (not to mention a dark past with other Rational tools:-). I suppose this made me somewhat gung-ho when installing UCR on a test Windows 2008 R2 64-bit server and promptly came unstuck.