Best practice for changes to source code that are part of a solution to resolve two different Product Change Requests?

Johan Sundqvist's picture

In practice I have two new features that are under change control and that I want to be able to track them as separate changes from the first change and until the features are deployed to production.
How do I handle the fact that they both need to make the same changes to one part of the code? If I let one of them carry the change but then decides later on to back out of that “Feature” then I  will break the other feature that where depending on the same change. 
I am curious to know of any good advice or best practices to use i CM when dealing with those type of scenarios. 
We use MS TFS as version control and status accounting tool, but I am really interested in learning about best practice in general.
Thanks Johan.

4 Answers

Drew Benson's picture

It would seem to me that you have 3 "Changes"

1) The "Common" change (x)

2) The 2 other changes (a + b)

Both the "other" changes have a dependency on the "Common" change


(in theory) The Common change could be implemented independently
That might not be true - but logocally it isn't dependent on change a & b

Change "a" can only be implemented after/with change "x" 
"with" or without change "b".

Change "b" can only be implemented with/after change "x" 
"with" or without change "a". 

Depending on what (testing) environments you have/can use you may need to manage a couple of "instances" of Change "x" - but that shouldn't be to onerous.  



Johan Sundqvist's picture

Thanks Drew!

Your answer is a very good advice to seperate the changes into 3 parts, the problem for me is also how to handle this kind of scenario in a standard way.

Should I have a process for best practice in theses cases and train the development team to act according to some rules when these types of things occur.  (Most likely  the dev team that will spot this kind of problem).

Should we stop development and send both features back to the CCB with a recommendation that the also approve the new change “The common one”? 

Regards Johan.



Drew Benson's picture

I don't want to get too hung up on process detail here (what "boards" you have/need what you call them etc etc) as we are only looking at a tiny snapshot but I would expect a bit more sanity within your process than "formal" approval at such a granular level ............

The "work" (and business need etc) for Feature A and Feature B has been approved (seperately or together)..............
This implicitly included (any) work needed for Common Bit (possibly twice)..........

If you weren't doing Feature B at all - you'd still need to do Common Bit (logicall there would be no seperate Common Bit to need approval) so whatever approval/authorisation you have MUST be OK.

The segregation/seperation of A from B is only a "technical" issue....
Obviously when you come to implementation (assuming they don't "go together") you have one less task for the Feature that goes 2nd (as Common Bit has already been done).

This is assuming that Common Bit is fairly trivial (Features A & B may or may not be - but it doesn't matter "much" as they have been justified already)

If Common Bit is in fact the major part of the change (with the features being trivial)
eg Common Bit is implementing a full Database schema and Feature A & B are trivial SQL reports

a) You would appear to have saved a fair amount of resource - as the major work for Common Bit has been justified/costed and approved (twice).
b) You should possibly look at your Impact Analysis process..........






Johan Sundqvist's picture

Thanks again Drew for taking time to answer my questions in detail.

Best regards!



CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.