Rolling back the COBOL program changes.
Rolling back the COBOL program changes.
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?
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?
-
- Global Moderator
- Posts: 832
- Joined: Wed Sep 11, 2013 3:57 pm
Re: Rolling back the COBOL program changes.
a good practice would have been not to have 4 teams modify at the same time the same program
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
- Robert Sample
- Global Moderator
- Posts: 1898
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: Rolling back the COBOL program changes.
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
- Global Moderator
- Posts: 122
- Joined: Tue Oct 20, 2015 3:20 am
- Location: Bloomington, IL
- Contact:
Re: Rolling back the COBOL program changes.
Robert, you should know better than to write this*. This is nor practical.Robert Sample wrote: ↑Thu Apr 26, 2018 9:01 pmn the future, do not allow 4 groups to update the same program.
"I come to the conclusion that, men loving according to their own will and fearing according to that of the prince, a wise prince should establish himself on that which is in his own control and not in that of others." -- Niccolò Machiavelli
-
- Global Moderator
- Posts: 588
- Joined: Wed Nov 20, 2013 11:53 am
- Location: Mars
Re: Rolling back the COBOL program changes.
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 ]
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 ]
zprogrammer
- Anuj Dhawan
- Founder
- Posts: 2807
- Joined: Sun Apr 21, 2013 7:40 pm
- Location: Mumbai, India
- Contact:
Re: Rolling back the COBOL program changes.
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.Rima Bali wrote: ↑Thu Apr 26, 2018 8:06 pmAssume 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?
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.
Thanks,
Anuj
Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.
Anuj
Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.
Re: Rolling back the COBOL program changes.
But can a version control tool merge the changes form different programmers?
Re: Rolling back the COBOL program changes.
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.Robert Sample wrote: ↑Thu Apr 26, 2018 9:01 pmThere 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.
Re: Rolling back the COBOL program changes.
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.
Regards
Nic
Nic
- Robert Sample
- Global Moderator
- Posts: 1898
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: Rolling back the COBOL program changes.
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.
Create an account or sign in to join the discussion
You need to be a member in order to post a reply
Create an account
Not a member? register to join our community
Members can start their own topics & subscribe to topics
It’s free and only takes a minute