Re: Change Management
Date: Thu, 4 Sep 2008 16:46:37 -0400
For routine administration we don't need a CM.. But we have IM's here (Incident Management) for items which require approvals. In this case, an IM would be required from a few sources and once they were obtained the account would be created.
Examples of a CM: code change, database init parameter change, patch, etc. IM: Reboot, create a user, add disk space, etc...
On Wed, Aug 20, 2008 at 1:39 PM, Ahbaid Gaffoor <ahbaid_at_att.net> wrote:
> Today I had a developer object that I was raising too many CMs, here's my
> usual process:
> [CM = Change Mangement Request]
> 1) Receive a request
> 2) Develop the scripts to fulfill that request
> 3) Test them in an Alpha database and commit them into some form of source
> controls (CVS)
> 4) Do the final pre-production tests against the Gamma database (which is a
> pre-prod copy of prod) by checking out the source from CVS and running
> 5) Schedule the change *
> If anything changes before prod, it's back to Alpha to revise and test...
> 6) Apply the change in production by checking out the source and running it
> * When scheduling changes all interested parties are notified of the
> upcoming change and have time to revise and submit their comments.
> One of our developers (a senior one) complained today when I raised a CM to
> roll out a new user, it's role and it's profile in production
> I believe it's better to over communicate and schedule production changes as
> simple as they may appear, our developer feels that there was no need to
> raise a CM.
> What are your thoughts / experiences out there?