Enforcing changset delivery to multiple releases
Hello RTC experts,
Is there is a way in RTC to enforce changeset delivery to more than one release? For e.g., if a changeset is being delivered to release R1.0.1, a corresponding changeset must be delivered to R 1.0.2, R1.1 and R1.2.1, etc. Currently, we rely on developers to do it but a lot of folks miss some releases. If there is nothing available OOTB, ss there a plugin that can be developed to inject this rule? Thanks!
2 answers
You could use the RTC build machinery to check if there are any changes in R1.0.1, and then automatically do the deliver to the appropriate streams. Note that if any other changes are being delivered to these other streams, the deliver might fail because of a conflict (but you can just use the build machinery to treat that as an error, and have the failure of the build notify you that manual conflict resolution is required.
You could also add a delivery precondition that checks for an approval from a "release checker" role. You can give that role to every developer and the only purpose is to provide approval that the change has been released to all relevant streams. It'll serve as a reminder to check where it has been delivered.
If you want something that actually does the checking, you could write a custom delivery precondition. It could check if the change set exists in the other streams. However, it assumes you have a primary stream where you would then check if the change sets exist in the secondary streams. The check shouldn't be made on the secondary streams as you would deliver to them first. Also, it may also be affected by gaps to the secondary streams. That means a separate change set may have been delivered to the secondary stream for that change.
It might be a good idea to investigate your options in automatically creating work items for each release you intend to deliver a change. Using one work item for a change to multiple releases doesn't really track the work done for each release. You want that audit trail of what changes were made for each release since that particular release may require merging that isn't required in another release.
If you want something that actually does the checking, you could write a custom delivery precondition. It could check if the change set exists in the other streams. However, it assumes you have a primary stream where you would then check if the change sets exist in the secondary streams. The check shouldn't be made on the secondary streams as you would deliver to them first. Also, it may also be affected by gaps to the secondary streams. That means a separate change set may have been delivered to the secondary stream for that change.
It might be a good idea to investigate your options in automatically creating work items for each release you intend to deliver a change. Using one work item for a change to multiple releases doesn't really track the work done for each release. You want that audit trail of what changes were made for each release since that particular release may require merging that isn't required in another release.