|
View previous topic :: View next topic
|
| Author |
Message |
rohanthengal
Active User
.jpg)
Joined: 19 Mar 2009
Posts: 206
Location: Globe, India
|
|
|
|
At my current project, I am seeing SCLM configuration tool as a bottleneck for planning of frequent changes into production (as per current demand of agile development).
What could be the best possible substitute (mainframe configuration tool) for SCLM thinking from flexibility to promote changes on frequent basis ? |
|
| Back to top |
|
 |
rohanthengal
Active User
Joined: 19 Mar 2009
Posts: 206
Location: Globe, India
|
|
|
|
I came to know about using GitHub solution for easy version controlling and flexible development, deployment.
Any views or experiences of using it ? |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
Perhaps the methodology rather than the tools need to be addresssed first.
I have worked in places where there was almost zero change control where we could get in and update production code / JCL almost at will, and others where we had to jump through hoops and dance on fire to get a change implemented. They were not software problems.
What bottlenecks and holdups are you experiencing and are they 100% confirmed to be due to the software ?
What would you suggest as a valid solution or work around ? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
| Quote: |
I am seeing SCLM configuration tool as a bottleneck for planning of frequent changes into production
|
we need facts not eyeball measurements 
the major bottleneck for making changes to the production system are the paperwork and the general process flow
with any SCM
the bottleneck are not the two commands needed
build and promote
but rather all the tasks between
..
analyze the requirement ( no computer needed )
get the proper signatures
propose a solution ( no computer needed )
get the proper signatures
IMPLEMENT the solution ( a computer is needed )
BUILD the affected modules ( a computer is needed )
TEST the affected modules ( a computer is needed )
check the results ( the computer need is irrelevant )
get the signatures for the certifications
determine the window to PROMOTE the changes
find the person with the privileges to issue the PROMOTE
so at the end the agile philosophy is just a truck of of horse manure
if the clerical work is not needed or if everybody can do everything
then where is the need for a controlled development environment ? |
|
| Back to top |
|
|
rohanthengal
Active User
Joined: 19 Mar 2009
Posts: 206
Location: Globe, India
|
|
|
|
Majority of the times - We could not deploy change into production because some of it's prerequisites did not go live into production.
But this would be overall methodology which many mainframe configuration tools may be facing - either it be CHANGEMAN or ENDEVER. |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1050
Location: Richmond, Virginia
|
|
|
|
I worked for several years at a major financial institution where to make any change to a program, "every" (whatever that means) functionality had to be re-tested.
Needless to say, some minor fixes were never performed. |
|
| Back to top |
|
|
hankoerlemans
New User
Joined: 25 Jan 2018
Posts: 62
Location: Australia
|
|
|
|
Sounds to me rohanthengal that SCLM is doing what it is supposed to do.
Stop you making changes that are unsafe. 
However I presume you've looked at an UNCONDITIONAL promote to an integration level, rebuilt at that level, tested, and then promoted, CONDITIONALLY, all the nicely tested bits you need ?
However, happy to stand corrected, I doubt very much whether an AGILE development methodology has very much to do with ensuring that changes are promoted properly in a timely fashion in a way that keeps everyone happy that you are not going to make things worse ?
The SCM has very little impact on agile. If you stuff up your code, SCLM, GIT, Rtc,blah, blah will all helpfully store your stuffed code.
In a past life I worked somewhere where CHANGE MANAGEMENT had a higher business priority than application changes. What we had needed to keep working and then we could address how well the new stuff worked.
But this is just a variation of previous comments....
Cheers |
|
| Back to top |
|
|
|
|
