Most clients I work with have various staging environments for their code in between ‘Development’ and ‘Live’. These often map to testing phases such as System, Integration, or User Acceptance Test. A commonly overlooked topic on Jazz.net is the promotion of source code between these environments.
A common strategy adopted in Team Concert is the usage of source code Streams to represent these environments. Users can specify relationship between streams by using Flow Targets; pointers which define which other stream(s) a stream’s code is delivered to. The flow hierachy of streams can be visualized by dragging streams onto the Flow Diagram (in the Eclipse client, right click on the Source Control node in the Team Artifacts View and select New > Flow Diagram).
Team Members usually have one or more Repository Workspaces which flow into a Development Stream, and allow them to check in their source changes to a repository and then share (deliver) them to the team stream. Repository Workspaces can also be used to flow changes between streams.
I’d recommend using a separate Repository Workspace to your development one to handle the promotion of code, and not to load the source code into your Local Client (both Eclipse and Visual Studio have the option to track Workspaces using the pending changes view only). This speeds up the process of promotion as you don’t need to make local changes. When you’re ready to promote code for testing and release, create one baseline per component in your Repository Workspace and deliver to the Development Stream. To promote the code to the next stream (staging environment), right click on the Repository Workspace and select Change Flow Target. This will allow you to select the next stream, with streams in the current flow hierachy appearing at the top of the list. Once you change the flow target, you should see the baseline you delivered as an outgoing change again. Deliver the baseline to flow it up to the stream. Repeat the process (with some testing in between, hopefully) to promote your code through the various staging environments.
Although you can flow change sets in the same way, it’s always good practice to create a baseline, as it is a ‘point in time’ picture of a component which you can roll back to easily if needed. To roll a stream back to a previous baseline, you can use the stream’s editor (available in both Eclipse and VS) to replace the current baseline with a previous one. This is useful for bugfixing and other activites which require previous code bases.
One final thing – the Eclipse client has a neat feature which allows you to see all flow targets in a Repository Workspace’s hierachy (instead of only the current one). This helps you to understand which streams you have promoted code to. To turn this on, go to Window > Preferences > Team > Jazz Source Control > Changes > Flow Targets: Show All.
Feel free to add your own thoughts on how best to promote code using Team Concert SCM.
For more info on Managing Source Code with RTC, go to http://jazz.net/library/article/599