Justin:
Here are what I think are some of the main goals of most modern "change
management" applications packages (or "ALM" suites, etc.):
*
provide a way for project administrators to specify the software
development life-cycle and work-flow you want to enforce
* provide a way to override or customize the behavior of the change
management package to cater for unique requirements or special
situations
*
provide some kind of "locking" mechanism to prevent developers from
accidentally overlaying source changes made by another developer,
resulting in "lost changes" and also lost productivity (because the
developer who lost their changes has to re-do that work)
o
optionally support the ability for two or more developers to
check-out the same object at the same time, e.g. to allow for
normal development and "emergency fixes" to occur at the same time
o
provide some kind of mechanism, such as notification, or
"conflict management" to ensure that any emergency fixes will
get merged back into the main development stream upon completion
*
provide a built in "source compare" tool to allow comparing any one
version of an artifact (source member or stream file) with any other
version of the same artifact (source member or stream file)
*
provide an archive or repository of "versions" of artifacts, to
allow "backing out" (an "un-do") of changes and restoring a prior
version, in the event that problems are discovered (usually soon
after implementing those latest changes in the "live" production
environment(s)
*
provide some mechanisms to capture the various optional parameters
used on the "compile" commands, so they can be automatically
"remembered" and re-used on all subsequent compiles of that same
artifact (source member)
*
provide some method or tools to deal with the OS/400 concept of
"level checks" -- e.g. when you change a PF, automatically recreate
all LFs over that PF, and then recompile all programs that use that
PF or any of its LFs, so those applications will not get "level
checks" when the changes to the PF and LFs are promoted into
"production" use (this is often referred to as a "rebuild dependent
objects" process)
o
normally, this leverages the capabilities that are built into
OS/400 and IBM i, such as DSPPGMREF
* ensure proper object ownership and authority for all artifacts, at
each stage or level of a software development project life-cycle
(development, unit testing, integration testing, user acceptance
testing, and finally, live production) -- note that the object
ownership or authorities might well be different in each of these
stages or levels in each project's software development life-cycle
*
maintain a complete "change history log" or "audit trail" to make it
easy to find out who changed what artifacts, when and why
o
this can be useful not only for "auditors" but also for
developers, who can benefit from reviewing the history of
changes to a particular artifact, before making further changes,
or to aid in analysis when determining how and when a certain
problem was introduced
*
provide automation of packaging and distributing a set of related
software changes (a "change package" or "change set") to one or
more target systems (or LPARs)
o
provide a mechanism to allow scheduling when these software
"change sets" are to be installed at each target system
+
these jobs could be submitted manually, e.g. "on demand"
(e.g. for an "emergency fix") or
+
they can be scheduled to run at a given time, say, every
Thursday night, just after the nightly "back-up" runs, for
normal upgrades to the applications, for normal fixes and
enhancements, etc.
o
automatically make a "back up" on each target system of the
objects about to be changed in a "change set" or "change
package" just prior to installing the changes, so that
"back-out" copy is available to quickly "un-do" or "roll-back"
those changes, in the event that problems are found soon after
installing those changes
+
this allows the flexibility to "un-do" the changes only at
one target site, if needed
+ this type of "roll-back" is normally initiated manually, not
automatically
Your suggestion of combining several separate, unrelated, open source
"source code version control" tools with some "build automation" tools
does not create a "change management system." This usually requires
writing several or many "shell scripts" that tend to be fragile, at best.
Like many "home grown" change management applications that various shops
may have developed over the years, they may "work" okay for their
"legacy" code base, but they may likely not easily accommodate "new
stuff" and they tend to be "unique" (or "one-off") solutions, with their
own individual quirks and characteristics, based on who developed them,
(and often, that person no longer works for the company, making it more
difficult to maintain that in-house application, especially since such
"internal use" tools tend to not get documented as well as the "real"
applications.
These same criticisms will also apply to your proposed "home grown"
change management tool-set, using various "shell scripts" to lash
together all of these open source tools to try to make a coherent and
integrated "solution.".
"Those who cannot remember the past, are condemned to repeat it."
-- George Santayana
I hope that helps,
Mark S. Waterbury
> On 5/25/2016 11:52 PM, Justin Dearing wrote:
Anytime on this list people talk about source control management, someone
points out that source control management is only a subset of what an IBM i
change management solution provides. Coming from a windows/linux world, I
get that. Git or subversion is used by your developers. Change management
refers to a whole bunch of policies that you show your auditors. However,
unless your using something like chef or puppet that uses a git based
system for change management, there really isn't an off the shelf or OSS
system I could call a "change management system".
But exactly what does an IBM i person expect a holistic change management
system to do? I think once theinks like jenkins, chef and puppet get
working on PASE, such a system could be built with OSS stuff, and IBM i
people could develop a set of best practices for managing the PASE side of
things that would be very interesting to linux admins.
Justin
midrange.com
