Rolling back the COBOL program changes.

[Rima Bali]

Hi,

Assume there is a program1 which has got changes. We have our team divided in 4 different locations. Now, all of us are making changes in this program for different requirement. Every one has retrofitted the code changes for other teams and doing UAT. But in case, we go for production deployment and for a team the changes needs to be backed out so how do we back-out only the impacted changes? Is there a good practice to do it?

[enrico-sorichetti]

a good practice would have been not to have 4 teams modify at the same time the same program

[Robert Sample]

There is no defined good practice for what you have done. In the future, do not allow 4 groups to update the same program. Many source code management systems allow only one check out at a time of a given program, which is one way to prevent the situation you're in.

[Akatsukami]

n the future, do not allow 4 groups to update the same program.

Robert, you should know better than to write this*. This is nor practical.

[zprogrammer]

This is why we have Version controlling in place ..

Your shop architecht should have designed the changes in the right order for releases...

But To me too many cooks spoil the broth

[ Post made via Android ]

[Anuj Dhawan]

Assume there is a program1 which has got changes. We have our team divided in 4 different locations. Now, all of us are making changes in this program for different requirement. Every one has retrofitted the code changes for other teams and doing UAT. But in case, we go for production deployment and for a team the changes needs to be backed out so how do we back-out only the impacted changes? Is there a good practice to do it?

Release Management at your shop has to come in to the picture for the situation, you describe. This is the strategy your shop has to define. In a typical situation - one or more programmers, will update the same source of code but which newly developed code should be promoted to next level (for example, QA or UAT) must be a collective decision by the team supporting the software.

No version control tool can magically merge (retrofit) the code from different resources, it has to be done manually, AFAIK. Though some of the version control tools can let you know that a given program is being modified by different programmers and might tell the 'package' in which it is being modified.

[Rima Bali]

This is why we have Version controlling in place ..

But can a version control tool merge the changes form different programmers?

[Rima Bali]

There is no defined good practice for what you have done. In the future, do not allow 4 groups to update the same program. Many source code management systems allow only one check out at a time of a given program, which is one way to prevent the situation you're in.

Thanks. But we are not using any version control tool. We send an email to everyone saying that we are reserving the program for us. But then others also send the similar email.

[nicc]

Then you (the company) needs to change its way of working. At the moment you are a catastrophe waiting to happen. If you have clients then they would be wise to move elsewhere.

[Robert Sample]

I agree with nicc -- your company is just begging for problems with the current approach. It is far too easy for changes to be lost with your approach.