In the first half of this 2-part series I discussed my tips, tricks, and experiences in using Rational Team Concert to get up to speed with the world around me. In this article I’ll discuss the features and time savers I use when I’m developing in this environment. Some of the tips are specific to our development team, however they will still provide insight into how we operate and may give some useful ideas you may wish to adopt in your own processes.
Environment Setup
The Jazz.net Collaboration Wiki is kept up to date and includes a very helpful page on getting a development environment setup. I won’t go into all of the details here, but I will point out a few very nice things that we do. One nice trick is something called Developer Offerings. These are pre-built versions of our products with full source included that you can set your Eclipse target platform to. This allows you to only load the Components you are working on in your Eclipse workspace so that re-compiling takes minutes not hours when working on large products. A very nice way to manage this is using Eclipse PDE target files that point to P2 repositories containing the developer offering you want to target. You can then put the target file under version control and it is easy for developers to stay up to date with the latest target platform.
Streams, Components and Workspaces
The source control model provided by Rational Team Concert affords a lot of power and flexibility but as the saying goes with great power comes great responsibility. The latter is especially true when you’re on a team that intersects more than one project. In my case for example, with JTS and RTC, I have to track changes that are delivered to one or both of them. There is a great post and some articles on how all this works including things I won’t mention here like Snapshots and Baselines but I will summarize the basic model which should be enough to get started.
- Each Repository has a number of Components. These correspond to distinct units of an application i.e. the components come together to make an application.
- Each Repository has a number of Streams. Streams are a grouping of some or all components, generally around a particular feature. For instance we have a Reporting Stream that contains the components important to Reports. Streams do not need to contain all the components necessary to successfully compile (nor do you need to load all of the components from a stream) which is made possible by the developer offerings mentioned above.
- Each User in a Repository has a number of Workspaces. Workspaces are a personal area to make changes in. Workspaces then flow with a stream, that is to say when a user delivers a change to the stream they will show up as incoming changes in workspaces that are flowing with that same stream.
- Some streams are special in that they are used regularly for builds. This is not a tooling option, as builds can be configured to build from any stream (or workspace which I’ll touch on in a second) but rather a team practice. For instance we have an integration stream that contains the latest finished features of the product. The common pattern is that developers will work on features in their own workspaces and will deliver them to the team’s stream once finished. At certain intervals a member of the team will load all the changes from that stream, switch the flow target to the integration stream and deliver a group of features which will then be picked up in the next build.
The flow from my workspace to my teams stream to the integration stream
- Streams can have preconditions defined on them to check for things like approvals, copyright notices, permissions etc. when delivering changes.
One useful time saver when delivering to multiple streams is that you can change flow targets on individual components rather than a whole workspace itself. This saves the time of synchronizing changes for all the components in the workspace as opposed to just the one in question. To do this, in the Pending Changes view, right-click a component and select Change Flow Target.
Sometimes you want to get some Change Sets in your workspace that have not yet been delivered to a stream. Once a change set has been checked-in and associated with a Work Item you can load it by right-clicking on the change set and selecting Load from the Links tab in the work item. The change will then be brought into your workspace, however you may be prompted to apply it as a Patch if there are gaps in the changes, that is the file has been modified in between the version you have locally and the version the change has been checked-in against.
The ability to suspend changes in a workspace is another useful feature I use in two ways. Firstly, its great when I have one feature partially completed and need to make a quick change to one of the files for something else. I dump all of my current work into a change set and suspend it to get a clean workspace back, make my change and then resume my suspended changeset. This is all possible from the Pending Changes view again accessed by right-clicking on the change sets. Secondly, suspending change sets is useful when merging conflicts. The easiest way I have found to merge changes is to suspend my own conflicting changes, accept all of the incoming ones and then resume my own. This lets me do the merges locally and make sure nothing gets lost prior to delivering.
Pending Changes View showing different flow targets for components, suspended change sets and unloaded components
The term workspace I have used so far has referred exclusively to the RTC Workspace however I find it useful to utilize Eclipse Workspaces as well. I have separate RTC Workspaces for each of the applications I work on. This gives me a clean separation, however it is time consuming to reload components and target platforms when switching between. Instead I maintain separate Eclipse Workspaces that have a 1 to 1 correlation to RTC Workspaces so switching is as easy as opening a new Eclipse instance. There is a bit of initial setup work to recreate Repository Connections and re-apply any environment settings (compiler compliance etc.), but in the long run the time-savings is more than worth it.
Builds
No one likes to break the build. Unfortunately being new, this is more likely to happen. The Build team has a great “face saving” feature that allows you to run Personal Builds out of your workspace without the need to deliver changes to a stream first. This way you catch any build problems before they affect the whole team. To run a personal build, from the Request Build screen, expand the Build Options and select Personal Build. By default your current workspace will be the one to build from however you can choose any public workspace or stream by selecting Browse.
Request Build Screen
More than once I have run builds to try out a change and then wondered why my button, page etc. was missing. The Build Page has a section called Contribution Summary which is really useful in determining what recent changes are included in that build. It will show you both the work items and change sets that have been delivered since that build last ran. To see them, expand the Builds tree in the Team Artifacts view, right-click on your Build Definition and select View Latest Build Results. This will show the recent (and currently in progress) builds in the Builds view. Double-clicking on a build will open the build page where you can look at the contribution summary. Conversely if you open a work item, the links page has a section showing which builds that work item was included in.
Build Page
Brent Barkman
Reports team
(11 votes, average: 4.64 out of 5)
Loading...