It has been a while since my last post. It hasn’t been because of lack of ideas, rather time, although the blog has been bugging me in the back of my mind for attention for quite some time. So here we go … for this come back I have picked an always interesting topic, to force some rules in your SCM.
I wanted to talk about one aspect of managing change sets in Rational Team Concert. Tools like RTC and Rational Developer for z Systems come in hand with the cultural and practices changes in the umbrella of Enterprise Modernization, but let’s face it, there are certain challenges that come into play in discussions with customers quite commonly and will take some time to leave … if ever (languages used and platform peculiarities play their part as well).
I guess any user of Rational Team Concert Enterprise Extensions is familiar with the packaging feature (see Packaging and deploying with Enterprise Extensions otherwise). This packaging feature, based on the location specified in its definition, stores the package it generates for a later deployment. The package can additionally be added to the packaging result Downloads tab with the following flag:
While the package result provides a great insight of what has been packaged in the “Package Summary” tab and the “Package Summary Work Item” that creates; what if I want to manually inspect the contents of the package? Continue reading
In (specially) mainframe development environment, there are situations in which duplicate element names can be problematic. And from time to time I get helping customers migrate to Rational Team Concert, I find them asking of a way of ensuring this source elements names uniqueness in SCM can be enforced. In this post I am going to show an advisor for such enforcement, and talk about some restrictions to the approach.
Work Item based Promotion allows you to move your changes related to a certain work item in your streams hierarchy. At the same time, Rational Team Concert allows a great flexibility to “move” your changes between work items, so developers can report their work or decide which changes better represent their tasks work. However, when it comes to work items promotion, there are times where this flexibility can lead you to undesired scenarios.
One of the coolest features of CLM 4.0.4 (and personally most waited), that I wanted to blog about is the Simulation Dependency Build. This feature allows you, basically, to run a Dependency Build without physically building anything, but generating all the metadata involved in these builds.
The use of Personal Builds allow a developer to verify if their checked in changes build successfully without impacting the team build, or waiting for a deliver-build cycle. In this forum post I want to discuss how to configure your Rational Team Concert deployment to allow the parallelism of personal builds by your developers.
At this point you may be already be familiar with the Promotion and Packaging Enterprise Extensions features, and how you can use them in a work item basis. You can specify concrete work items to be promoted or packaged, therefore associated changes will be the ones to consider in these processes. This offers great fine grain control of how your changes are to progress in your defined development flow, which is to sum with all the goods that managing change sets with work items offer (traceability, process control, …).
In this post, however, I want to discuss the case of dependencies impact and their management: when files get rebuild because a source they depend on has been modified. I will provide a custom Ant task as sample approach for automatically linking those files rebuilt to a work item to incorporate them (and their outputs) in the development flow. In the last part of this post I want to also introduce some new features improvements coming in RTC.
The past days, while I was trying the configuration of a deployment of the Build System Toolkit and the Build Agent (based on version 4.0.4), in a test system using the Money that Matters sample, I faced the following error running a build:
PTY allocated pseudo-tty *PtyPipe
EXEC Unable to set working directory to '"/u/<userX>"' (111).
I want to blog about this error and its resolution, taking the opportunity meanwhile to provide links to important configuration information.
A lot of reorganization work has been happening lately within IBM/Rational and, as one of them, it was with a mix of sadness and mission accomplished feelings that I received the news that Jazz Jumpstart Team was to be disbanded. As a result of that reorganization I have joined the Rational Emerging Technologies Team (aka RETT). You can have some more insight on these changes and what the new team means in the blog post Everything Changes – Change is the Only Constant from Dan Toczala’s Blog. He is the manager of this new team where I am joining some old and new colleagues in this RETT initiative.
What does that mean for me and this blog? Well, not much, as in my new role I am focused on Rational Team Concert for System Z development, so still RTC and the Jazz platform :). I’ll try to focus a bit more my posts on RTC for developing for this platform: how to take the most of Enterprise Extensions, adoption tips, …; or my little solutions for common customizations/extensions that I find for the adoption of RTC for that particular development area. I am keeping here links to other colleagues’ blogs where you will still find cool stuff in other CLM areas that I will be no longer focused on.