Remove function from a build.
We are migrating (mainly C) code from CMVC to RTC. We also have to migrate the department's processes which are at the moment very tied into CMVC.
One thing that we can do with CMVC is to exclude a track from a build if that track is thought to be causing a failure (in either system test, acceptance test or compilation/packaging). I think the closest equivalent in RTC would be to:
(a) Create a work space from the main stream
(b) Take out the change sets associated with a Work Item
(c) Take out any other change sets that are dependent on the ones that have been removed.
(d) Make a build from the work space
This seems to be fighting the design of RTC a bit. I wondered if anyone had encountered a similar issue and if so, what they did?
One thing that we can do with CMVC is to exclude a track from a build if that track is thought to be causing a failure (in either system test, acceptance test or compilation/packaging). I think the closest equivalent in RTC would be to:
(a) Create a work space from the main stream
(b) Take out the change sets associated with a Work Item
(c) Take out any other change sets that are dependent on the ones that have been removed.
(d) Make a build from the work space
This seems to be fighting the design of RTC a bit. I wondered if anyone had encountered a similar issue and if so, what they did?
Accepted answer
Oh, how I miss CMVC (certain parts, anyway).
Unfortunately, as you've discovered, RTC has no concept of "reqing out" a track like you can do in CMVC. The method you identified will work, but as you said it's rather heavy handed. You can also "reverse" a changeset but the whole process is rather unintuitive as well.
RTC seems very much based on the idea that you just keep moving forward & deliver fixes - very much like you would see in the OSS world with CVS or SVN. Going "backwards" is possible but painful.
Comments
Thanks Jeff :-)
That is exactly what we thought. I think this function is probably the only thing I'll miss about CMVC - but it's quite a big deal when your development processes of the past 15 years or so are all built around the ability to yank stuff out at will.
We are in fact having to rewrite all of our development processes - maybe not such a bad thing - I think it's probably better than writing complicated code to make RTC do what it wasn't designed for.
1 vote
Personally I miss linked files the most. and track-control. and fine-grained file ACLs.
I'm a big non-fan of linked files ... too much risk of breaking things unless you carefully test every change against every configuration that is "linked" to that common file. Note that RTC does allow some kinds of access control to be defined on individual files. I assume track control is largely what we're discussing in this thread? Most of what can be done with track control can be handled by modeling a track as either an RTC stream or an RTC work item.
One other answer
The approach I recommend for this use case is to use two RTC streams: one where all change sets are delivered (for continuous build), and the other to which changes are promoted (delivered) once they have been validated (ideally, validated by an automated verification suite, but possibly also requiring manual testing). So rather than trying to remove change sets if they are proven to be bad, you instead promote change sets once they have been proven to be good. There still can be cases where you want to drop a promoted change set from the validated, but you can use "reverse" for those, since it should be a relatively infrequent occurrence.
I've seen some customers which have multiple promotion levels, if they have multiple levels of testing performed by different teams or at different frequencies.
I've seen some customers which have multiple promotion levels, if they have multiple levels of testing performed by different teams or at different frequencies.