How to keep your streams flowing smoothly in Rational Team Concert
This article explores some of the best practices for team-based Release Engineering in a Rational Team Concert environment using Jazz Source Control. In particular, we introduce two new features in RTC 3.0.1 that are designed to aid the Release Engineer in their day-to-day tasks: a new post-build option that automatically delivers changes to a chosen stream, and the ability to use the Pending Changes view to track incoming/outgoing changes from a stream.
Note: This article assumes you already have some familiarity with multi-stream development and Jazz builds. To get started with multi-stream development please read Stream strategies with Rational Team Concert 3.0 for a high level overview, and Multi Stream Development for a hands-on approach. Please also see Getting Started with Setting up Jazz Builds for a starting point for Jazz builds.
Friendly Note: Actual Release Engineers should take no offense to our description of “Release Engineering duties” throughout this article. We use this term lightly when we describe the process any team must undergo when integrating their changes with other teams, whereas true Release Engineering is a much more complex and involved discipline.
Table of Contents
- Introduction
- Example: A new flow process for delivering to an integration stream
- Tips to efficiently manage streams
- How do I use the “new” method to accept from an integration stream instead of delivering to it?
- Can I take advantage of the “Post-build Deliver” step without creating an intermediate “green” stream?
- How do I prevent developers from delivering to the “green” or integration streams directly?
- Dilemma between having a quick build vs. a build running many tests
- Do Source Control preconditions apply when using the “Post-build Deliver” step?
- What constitutes a good default or current flow target for a stream?
- When looking at a build result, how do I know if it performed the “Post-build Deliver” step?
- New in RTC 4.0
- Conclusion
1. Introduction
A Release Engineer is responsible for monitoring the health of a stream. Are the changes delivered to that stream safe or will they introduce compilation errors and test failures? Is the stream up to date? Are there new changes that need to be accepted from another stream? Are there changes that need to be delivered to another stream?
By simply adding a post-build step to your build definition, you can set up a stream that will automatically pick up the latest changes from a green build. This provides an additional level of confidence that the stream only contains changes that were validated.
You can also easily track changes between a stream and its default flow target through the Pending Changes view. This allows you to see when changes become available to be delivered or accepted, all without the need to load a repository workspace from that stream.
The first section of this article walks you through a simple and concrete example. It highlights the new features in the Pending Changes view and Build Definition editor that aid in Release Engineering duties. The second section of the article provides a combination of tips, facts and questions that relate to managing streams, Release Engineering, or different ways of using the new features discussed in this article.
2. Example: A new flow process for delivering to an integration stream
The Release Engineering duties include pushing a team’s changes to an integration stream. The following sections describe two different ways the Release Engineer can perform these tasks, as well as outline where the new features help in this process.
To give some sense of reality to this situation, let’s create a fake company and name some of the projects, streams and workspaces that it may have set up in Rational Team Concert. This will allow us to have a mental picture of what is going on, as well as give some context and naming conventions that can be used in the screenshots and text throughout this article.
Imagine a company which is creating a software product named ‘ProductX’. In Rational Team Concert, the project lead creates a dedicated project area named ‘ProductX Project Area’. It is decided that only three teams are needed for this project, and so three team areas are created from this parent project area. The team areas are named “TeamA”, “TeamB” and TeamC”. A stream is created for each team (ex: “TeamA Stream”) and a stream is created and owned by the parent project area called “Integration Stream”. The streams contain a component for each team: “TeamA Component”, “TeamB Component” and “TeamC Component”.
Now that we have a rough outline of the project structure, we can now dive into the details of this example. In the next section we will demonstrate how Dave, the Release Engineer for “TeamA” can push his team’s code changes to the project’s “Integration Stream”.
2a. The “traditional” method
For lack of a better name, we will call “the Release Engineering process in which none of the new features are used” the “traditional method”. It is likely that this method (or a variation thereof) is currently used by most teams, and thus the entire process will not be described in great detail. The purpose is, however, to outline some of the disadvantages of this approach and point out some key areas where our new features could help out. We’ll start by showing a flow diagram of the current approach:
Figure 1: The “traditional” method of pushing changes to an integration stream.
In the diagram above, we can see that comment 1 does not involve any of the Release Engineering actions per se, however this step represents the source of ‘what’ he must push to the integration stream. Comment 2 is also something the Release Engineer does not actively do, yet continuous builds let the team members and Release Engineer be aware of any possible breakage (test failures or compile issues, etc.). Clearly if every continuous build is failing, the Release Engineer is not going to push any of their changes to an integration stream.
Comment 3 is the aspect we would like to focus on. The continuous build, and likewise the build workspace (“Build’s “TeamA Stream” Workspace” in this example), is a good indicator as to whether the team’s code is in a good enough state to be delivered to the integration stream. However, the Release Engineer generally does not deliver changes that are in the build workspace to the integration stream. He has to load / accept all changes from his Team Stream (“TeamA Stream”) in order to deliver to the “Integration Stream”. To do so, he generally has to change flow targets in his workspace to the “Integration Stream”, deliver the changes, and then remember to change his flow target back so that he can continue development work for his team.
The Release Engineer also has to ‘revalidate’ the changes before delivering to the Integration Stream. Consider the situation where the continuous build has been running green for a week. The Release Engineer looks at the last build, and seeing that it is still green, accepts everything from his Team Stream (which the continuous build is building against) and immediately delivers these changes to the “Integration Stream”. To his surprise, his changes now broke the continuous builds running against the “Integration Stream”. What could have happened in this situation is that team members could have delivered changes ‘after’ the last build has run, so everything looks OK when looking at the build history but in reality they are not. Fortunately, there are a few things the Release Engineer can do to avoid this situation. One option is to look at the snapshot of the most recent green build, and deliver only the change sets in that build snapshot. The other option, which ensures everything is OK before delivering, is to request a personal build. If the personal build runs “green” then he knows he is safe to deliver the changes. The problem now is that the Release Engineer has to manually start a build (essentially duplicating what the next continuous build would have done), wait until it finishes, and then deliver.
From briefly describing this process we can immediately see some problems or annoyances which include:
- As a Release Engineer, you have to accept your team’s changes into your repository workspace before delivering them to the integration stream.
- There is no guarantee that the changes accepted have been validated. You have to either:
- Make sure that you deliver only the change sets that were present in a green build.
- Run a personal build. Wait until it is done, and then deliver.
- Having to change flow targets in your development workspace to flow with the integration stream in order to deliver, and remember to change it back when done.
2b. The “new” method
Without going into detail on how this “new” method differs from the “traditional” method described above, it might be best to start with a diagram. The diagram below shows the layout of this new process.
Figure 2: The “new” method of pushing changes to an integration stream.
In this process, it is still true that team members deliver their changes to the “TeamA Stream” and that a continuous build runs against the “TeamA Stream”, however comments 2 and 3 indicate where new features can be used within this process.
One immediate difference between the two diagrams is that there is now a new stream called “TeamA Green Stream”. Using this method, each team would have to create their corresponding “green” stream. But what does that mean? Who delivers to it or maintains it? The good news in this case is ‘nobody’ so to speak. By adding the “Post-build Deliver” option to a build definition, a build can be set up to automatically deliver “blessed” changes to this “green” stream. Having a build automatically deliver changes based onthe status of the build result can have a wide range of uses. One consequence of setting up a “green” stream is that it addresses the “problem” from point #2 in the above section. The Release Engineer can have confidence that all the changes in the “green” stream have been validated. In other words, he or any interested stakeholder who wants the latest stable version of a team’s code can simply load from the “green” stream and have confidence that the code has met the standards that the continuous build enforces (ex: no compile errors, no test failures, etc.). As a consequence, the Release Engineer no longer has to run a personal build, or worry about accidentally accepting changes that made it into the stream just after a build has run.
Users are free to come up with other benefits of having a “green” stream, however when reminding ourselves of some of the other “problems” mentioned in the section above, does this mean the Release Engineer still has to load from this “green” stream, change the flow target to the “Integration Stream”, deliver, and change the flow target back to his team’s stream? The answer, as you already know from reading comment 3 in the diagram above, is ‘”No”. It is possible to now show a stream in the Pending Changes view, similar to how it currently shows repository workspaces. Furthermore, you can directly accept and deliver between streams using this feature. This essentially eliminates problems #1 and #3 from the previous section.
The following two sections show how to set up and use the new “Post-build Deliver” option for a build, as well as how to use this new feature in the Pending Changes view.
2c. Adding the “Post-build Deliver” step to the build definition
When creating a new build definition, the “Post-build Deliver” option can be selected from the “Post-Build” page of the “New Build Definition” wizard. Move the “Post-Build Deliver” option to the bottom of the list (if it is not there already) to ensure that it is the last post-build task to run. This can be accomplished by using the “Move Up” or “Move Down” buttons. As shown in Figure 3 below, we can see that the “ECJ Publishing” and “Junit Publishing” tasks will run before the ‘Post-build Deliver” task, which is what we generally want.
Figure 3: Selecting the "Post-build Deliver" option.
After finishing the wizard, a new tab called “Post-build Deliver” is available in the Build Definition editor. It is also possible to add this option to an existing build definition. Simply press the down arrow in the “Build Definition” header and select “Edit Configuration” as shown in Figures 4 and 5 below.
Figure 4: Adding “Post-build Deliver” to an existing build definition. Step 1.
Figure 5: Adding “Post-build Deliver” to an existing build definition. Step 2.
Figure 6 below shows the actual “Post-build Deliver” tab in the build definition that “TeamA” is using.
Figure 6: The “Post-build Deliver” page used by “TeamA”.
The “Trigger Policy” section allows you to specify the criteria for when to automatically deliver component changes. For example, if a team wants to mirror another stream (“green” or not), they would use the “Deliver always” trigger policy. However, in our case, “TeamA” wants to automatically deliver “blessed” changes to a “green” stream. To do this, they have chosen the option “Deliver if build has no errors or warnings”. This section also has a checkbox that allows you to disable the post-build deliver without having to remove this post-build option from the build definition.
The next section on the Post-build Deliver tab is pretty straightforward. The “Deliver Target” section allows you to choose the target stream to flow changes to after the build has completed (and after the build has passed the trigger policy requirements). Users can press the “Select…” button in order to browse and select the desired target stream. The label is also rendered as a hyperlink as a convenient way to open up the selected stream in a Stream editor.
The “Components to Deliver” section is a little more complicated. This sections gives you the flexibility to choose “what” exactly gets delivered. Should it be all the components or only a subset of them? Do we want to add newly created components to the target stream? Or do we want to remove components in the target stream because they were removed in the ‘source’ stream? These options are all available via checkboxes and a component picker.
If a team wants to deliver ‘all’ components, we recommend selecting the “Deliver all components in the build workspace” checkbox. It is possible to use the component picker and select all components in the build workspace, however if a component were to be added after the build definition has been saved, this component would not be included in the selected component list. Using the checkbox ensures that all components are considered at the time of the build. In other words, only use the component picker for a proper or strict subset of the components in the build workspace.
It is also important to understand what is actually being ‘delivered’. First off, the post-build deliver option only works if the “Jazz Source Control” pre-build option is present in the build as well (the Build Definition editor shows a warning if this requirement is not met). One of the reasons is because the components that we pick are in fact from the current components present in the build workspace specified on the “Jazz Source Control” tab. The post-build deliver option also requires that the “Jazz Source Control” pre-build option create a snapshot during the accept phase of its operation (see the “Accept Options” section in the “Jazz Source Control” tab). It is actually the baselines of each component within this snapshot that are delivered to the target stream.
For each component that is “marked” to be delivered (either a selected subset, or all components), a “replace in target stream” operation is applied. In other words, it is not the exact ‘deliver’ operation that is commonly used in the Pending Changes view; it replaces the component in the deliver target with the component baseline from the snapshot (this is similar to how the Jazz Source Control pre-build option does a replace instead of a regular accept when updating the build workspace from the stream). This ensures that there are no conflict issues when pushing changes to the target stream, and that any discarded changes get dropped. To illustrate this example further, imagine that both the build workspace and target stream contain “change set A”, as well as all other change sets (i.e. they are ‘identical’ if you will). Now imagine that this “change set A” were to be discarded from the build workspace (or really, if it were to be discarded from the stream that the build workspace flows with). If the Post-build Deliver step performed a “normal” deliver, there would be nothing to deliver since there are no change sets that exist in the build workspace that do not exist in the deliver target (in this example anyway). Thus at the end of the build, even though we set up a build to deliver all components, and to only do so when the build has no errors or warnings, we are left in a state where the deliver target still has “change set A”, whereas the build workspace does not have “change setA”. This eliminates all confidence that the target stream is a “green” stream. However, by performing a “replace in target stream” operation on all selected components we avoid this problem.
Another question you may ask is “Why do we require a snapshot? Why can’t we just flow changes from the build repository workspace itself?” The reason is that using the snapshot isolates what is delivered from any possible subsequent changes in the build workspace. For example, if a build ran green, and the post-build deliver trigger policy check determined it should go ahead with the deliver, it is possible that additional changes got added to the build workspace (possibly from another concurrent build running) right before the components are delivered. By delivering the components from the created snapshot, we guarantee that they have not changed since creation.
2d. Tracking changes between streams in the Pending Changes view
To track a stream in the Pending Changes view, select a stream node in the Team Artifacts view, and from the context menu select “Show” –> “Pending Changes” as shown in Figure 7 below.
Figure 8: The "TeamA Green Stream" in the Pending Changes view.
You can create baselines directly on the stream from within the Pending Changes view. You can also accept and deliver changes or baselines that do not introduce conflicts. Otherwise the operation would fail and you would have to accept or deliver the changes into a repository workspace, resolve the conflicts in the regular fashion and deliver the merged changes back to the intended stream.
As already mentioned, one of the benefits of this work flow is that the Release Engineer does not have to load a repository workspace first before pushing his team’s changes to an integration stream. This is visible in the diagram by the fact that the component icons for the stream are empty, meaning they are not loaded. The other benefit is that the Release Engineer does not have to undergo a context change on his development workspace by changing the flow target to the integration stream, delivering the appropriate changes, and changing the flow target back to his team’s stream. Keeping both nodes in his Pending Changes view (his repository workspace and his team stream), he can work as usual and immediately see when changes are ready to be delivered to the integration stream, or when other teams changes are ready to be accepted into his team stream; all without requiring manual effort.
3. Tips to efficiently manage streams
The following sections are a combination of tips, facts and questions that relate to managing streams, Release Engineering, or different ways of using the new features discussed in this article.
3a. How do I use the “new” method to accept from an integration stream instead of delivering to it?
It is possible to use the same approach described in the example above to accept from an integration stream as well. In the original example the continuous build would build against the “TeamA Stream”, that is, the build workspace would accept from the “TeamA Stream” every time a build started. The idea here is that we want to update our team’s stream with components from other teams. This means that we want a build whose build workspace pulls our components from our team stream, and other components from an integration stream. This can be done by setting up scoped flows in the Workspace editor for the build workspace.
The following figure shows how “TeamA” would set up their build workspace to accept from both the “Integration Stream” and the “TeamA Stream”.
Figure 9: Setting up scoped flows in the Workspace editor.
“TeamA” can now create a new green stream called “TeamA Green Integration Stream”. This again gives the Release Engineer confidence that new changes in this stream have been validated. “TeamA” would set up their “Post-build Deliver” step in a build definition exactly as in the previous sections, except now the changes get automatically delivered to this new green stream. The figure below shows the settings they would use.
Figure 10: The “Post-build Deliver” page used by “TeamA” to perform continuous integration.
This new green stream can be shown in the Pending Changes view as well. This way the Release Engineer can track when to deliver or accept changes.
Figure 11: Showing both “green” streams in the Pending Changes view (not filtered).
Depending on the number of components, having two “green” stream nodes and a repository workspace showing in the Pending Changes view, things can get quite cluttered. As shown in the figure below, you can uncheck the “Show unchanged components” option to make the Pending Changes view more manageable. This helps more when streams or workspaces have 10+ components, as opposed to our example which only has 3.
Figure 12: Unchecking "Show Unchanged Components".
Figure 13: Showing both “green” streams in the Pending Changes view (filtered).
Another small tip in this example is that the Release Engineer only has to pay attention to the Outgoing change sets, and can ignore any Incoming changes. In other words, he is only interested in delivering to the “TeamA Stream” or “Integration Stream” and not accepting into the “green” streams.
3b. Can I take advantage of the “Post-build Deliver” step without creating an intermediate “green” stream?
Yes, it is possible to both eliminate the “green” stream as well as the need for a Release Engineer to push changes to the integration stream. If each team’s component in the integration stream were truly independent of one another, then it would make sense that each team could asynchronously deliver their code changes to the integration stream as they pleased. Returning to the original example of this article, it would be possible for “TeamA” to set up their post-build deliver tab as follows:
Figure 14: Selecting the team’s component.
Figure 15: How to deliver only the team’s component.
In this scenario “TeamA” still uses the same trigger policy (to ensure anything they deliver has been validated), however now they are only delivering their single component to the “Integration Stream”. In this situation there is no “green” stream, and the Release Engineer no longer has to deliver changes to the integration stream since it is now automated.
Also note from Figure 15 that the two checkboxes “Add components to deliver if they do not exist in the deliver target” and “Remove components from the deliver target if they do not exist in the build workspace” are NOT checked. It is recommended to not propagate component additions / deletions to an integration stream via some automated mechanism. The last thing the team would want is to have all other components removed from the integration stream because someone accidentally modified their team’s stream. The adding or removing of components should be done manually by the Release Engineer in these cases. For example, if the team needs a new component, they should first add it to their stream, and deliver it to the integration stream. They would then modify the “Components to deliver” selection in the “Post-build Deliver” tab to include this new component and have it automatically delivered afterwards.
For “mission critical projects” this approach might not be recommended. It is always encouraged to have a human brain have the final decision as to ‘when’ and ‘what’ gets delivered to an integration stream. However, this method may be perfectly acceptable for smaller projects, or projects where teams and their components are very much independent.
3c. How do I prevent developers from delivering to the “green” or integration streams directly?
In our example, developers in “TeamA” are expected to deliver to the “TeamA Stream”. Then a successful build (with the post-build deliver step) pushes these changes to the “TeamA Green Stream”, and finally the Release Engineer manually pushes these changes to the “Integration Stream”. If a developer delivers their changes directly to the “green” stream or the integration stream, this would break all the benefits of our intended controlled flow process.
As a result, developers should not deliver directly to the “green” or integration streams. Accidental delivery can be prevented with the precondition “Restrict change set delivery to components in a stream”. That precondition is available in the Project Area editor under Process Customization / Operation Behavior / Operations / Source Control / Deliver (server). Set one precondition scoped to the stream “TeamA Green Stream” and another precondition scoped to the stream “Integration Stream”. Select all the components and use “Edit Permissions” to require a role such as “Releng” that regular developers do not have. Make sure the build user and the Release Engineer have the “Releng” role so that the build can deliver to the “TeamA Green Stream” and so that the Release Engineer can deliver these changes to the “Integration Stream”. You can create such a “Releng” role if you don’t already have something similar already. Figure 16 below shows how to setup this precondition.
Figure 16: Only users with “Releng” role are allowed to deliver to “TeamA Green Stream”.
Note that the Pending Changes view will warn you if you try to deliver to a non-default flow target. If the repository workspace is correctly set up with its default flow target set to the “TeamA Stream”, accidental delivery to other streams, such as the “Green” stream, is less likely. You can decide if that is a sufficient safeguard in your organization or if you need to fully prevent accidents with the precondition “Restrict change set delivery to components in a stream”.
3d. Dilemma between having a quick build vs. a build running many tests
In the example above, let’s consider that a continuous build for the “TeamA Stream” takes 15 minutes to complete (10 minutes to produce a binary and 5 minutes to run 10 tests). When the developer Chris delivers a change set to the “TeamA Stream”, it won’t be long before that change set makes it into a build and gets automatically delivered to the “TeamA Green Stream” (assuming it doesn’t break the build). This means the releng process remains fluid despite the introduction of different stages of streams.
Now, maybe 10 tests aren’t good enough. Maybe, from time to time, bad changes make it into the “Green” stream because the continuous build doesn’t run the full test suite. There is an obvious solution. Just set up the continuous build so it executes the full test suite. Have we solved the problem?
Let’s examine what will happen now if the full test suite is huge. The continuous build may now take 8 hours to complete. Consequently, a change that Chris delivers in the afternoon may not be part of a build until the next day. The releng process isn’t as fluid anymore.
The changes delivered by the developers will get integrated later. In turn, the developers will be receiving changes from other teams using a similar flow process at a slower pace. This increases the risk of integration issues since each change was developed in an older context.
If a build takes 8 hours, it may only be scheduled to run every 4 or 8 hours to avoid overloading the build engines. But this increases the number of changes included in each build. This makes it harder to isolate which change is responsible for a failure.
Note. Continuous builds can be scheduled at intervals shorter than the time they typically take to complete on average. You can use multiple build engines on different servers to scale. Multiple continuous builds can run concurrently and deliver to the same target stream. The target stream will get the right changes in the right order, even if a build started later than another one yet finished earlier because it ran on a faster server.
So there is a trade-off in term of how much test coverage should be part of a continuous build, depending on how long your test suite takes to run and how often you need to integrate changes with other teams. Having these two factors in mind helps finding the right balance.
3e. Do Source Control preconditions apply when using the “Post-build Deliver” step?
Yes, the “Deliver (Server)” and “Deliver phase 2 (Server)” operations are the two Source Control preconditions that you can customize. These preconditions are executed before changes get delivered to a stream by a user (through the Pending Changes view with “deliver”, “replace with” or “replace in” actions) or by the build engine user as part of the “Post-build Deliver” step described in this article.
For example, you can set the server preconditions “Require Work Items and Comments” and “Require Work Item Approval”. They will be enforced, regardless of how the changes are delivered – automatically by a build (“Post-build Deliver” step) or manually through the Pending Changes view.
The “Post-build Deliver” step will fail the build and log the appropriate error messages in the build log if any precondition has not been met. It is then up to the Release Engineer to look at these logs in order to determine the corrective action needed (associating a work item to a change set, updating the review request, etc.).
3f. What constitutes a good default or current flow target for a stream?
In our example, the Release Engineer flows changes from the stream “TeamA Green Stream” to the stream “Integration Stream”. This is the regular way changes are meant to be flowing in that organization. As such, in the Stream editor for “TeamA Green Stream” there should be a single flow entry set to “Integration Stream”. It should be both marked as default and current.
Setting the flow target on a stream is a way of describing the way changes are meant to flow. This relationship is visualized in a flow diagram as shown in Figure 2. In addition, the context menu action “Show” –> “Pending Changes” on a stream uses the current flow target of that stream to determine outgoing and incoming changes in the Pending Changes view. If no flow entry has been set yet, the following message will show up.
Figure 17: Prompt from “Show” –> “Pending Changes” action with no flow target.
Note. Whereas a repository workspace is owned by a contributor, a stream is owned by a project area or a team area. As such, changing its flow entries will be visible to every user who has access to that stream. It is recommended to use the flow entries on a stream to capture persistent relationships with other streams and not day-to-day operations. If a stream doesn’t have a well-defined target stream, it is best not to use “Show” –> “Pending Changes” on that stream. Instead use a repository workspace that accepts from the source stream and change the workspace’s flow target as needed. The context menu action of “Show” –> “Pending Changes” on a stream is best suited for flow processes that are linear and static.
3g. When looking at a build result, how do I know if it performed the “Post-build Deliver” step?
In the RTC Eclipse client or in the web UI, you can easily tell if a build performed the “Post-build Deliver” step by looking to see if there is a “Post-build Deliver Target” contribution item shown in the build’s “Contribution Summary” section. An example is shown in the figure below.
Figure 18: The "Post-build Deliver Target" contribution item.
Knowing if the “Post-build Deliver” step has been performed and knowing the “deliver target” is one thing, but how can we figure out exactly what was done? How many components were actually delivered? Were there component additions or deletions as well? This information is all available in the build log. By opening the build log and scrolling to the bottom, one can see a post-build deliver summary report similar to what is shown in the figure below.
Figure 19: The Post-build Deliver Summary Report.
5. New in RTC 4.0
There are two new enhancements to the “Post-build Deliver” option in Rational Team Concert 4.0. These enhancements are shown below:
The first enhancement modifies the “Trigger Policy” section. As shown in Figure 20 below, there is now a checkbox called “Abort post-build deliver if there are incomplete build activities” which is checked by default. If the intended use case of the post-build deliver option is to create a green stream, then this new option should remain checked. We can assume that it is an error for a build activity to remain incomplete if a build has finished. For example, if the “JUnit Publishing” phase successfully started and determine that there were errors and that the build result should be put in an error state, it might be possible (due to network issues for example) that it failed up update the build result or mark the build activity as complete. This new option can help in these cases. However, if you want to create a build which will always perform the post-build deliver, even in the presence of incomplete build activities, this option can be unchecked. The decision to perform the post-build deliver will then be solely determined by the regular trigger policy options.
Figure 20: The Post-build Deliver Trigger Policy Section in RTC 4.0.
The second enhancement to the “Post-build Deliver” page involves an entirely new section called “Snapshot Owner”. By customizing the radio buttons in this section, users can setup a build that will automatically set the deliver target as the owner of the snapshot that was created during the build. By default, the build workspace will remain the owner of this snapshot. The usefulness of this feature can be seen when someone is interested in finding the snapshot that the ‘green’ stream was updated with. The average developer may not know the name of the build workspace, however they will know the name of the stream. This way they can simply use the context menu action of “Show” –> “Snapshots” from the “easy to find” stream node instead of the build workspace node. The only caveat for this new feature is that snapshot ownership can only be changed if all components are to be delivered, i.e. if the “Deliver all components in build workspace” is checked. If only a subset of the components are to be delivered during the post-build phase, then it would not make sense to have the snapshot owned by the stream (deliver target), since it never was a complete snapshot of that stream in the first place. The new “Snapshot Owner” section, which is added below the “Components to Deliver” section, can be seen in Figure 21 below.
Figure 21: The Post-build Deliver Snapshot Owner Section in RTC 4.0.
4. Conclusion
In many organizations, changes must flow through different levels of streams to satisfy various degrees of integration and validation. You can greatly improve your release process by configuring your build so that it automatically delivers new changes to a dedicated “green” stream upon success. This is a powerful way to ensure every change delivered by a developer did pass through a green build.
Since the input of a build is a stream, and a green build can deliver its changes to a different stream, you can use the post-build deliver mechanism as a building block to set up sophisticated flow processes. You can set up various levels of streams and builds chained together.
You can track multiple streams and their default flow target in the Pending Changes view. As a Release Engineer, you can use this feature to find out when there are new changes to deliver or accept.
Copyright © 2011, 2012 IBM Corporation