Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Fri Aug 17, 2007 11:01 am Post subject:
It sounds like you talking about making a change that will affect both written organizational Policies and affect training documentation. If this is the case, and you have version controlled your documents, then yes. You are in fact making a change that will affect the Attributes of items that should be considered Configuration Items.
I say "should be" because I don't know how mature your Configuration Management process is. But even if your Config process is non-existent, you should think in terms of "Would this change affect hardware, software, or associated documentation that should be kept in a controlled state?"
Interesting perspective that I had frankly not considered. I was looking at it more from the point of view of where do you draw the line when using standard functionality within an application.
I am now thinking that any configuration/setup change that might change the way an application works or how the user interacts with the application might be a candidate. Like you indicated, this would also potentially change the policies and training documentation as well.
Joined: Sep 16, 2006 Posts: 3379 Location: London, UK
Posted: Tue Aug 21, 2007 12:44 am Post subject:
think this way as well
1 - Development environment - loose to no configuration or change from an operational POV. Version & revision control applies to code and packages
2 - UAT / Testing Environment - Medium control from a operational environment. You want tto have the UAT & Live environment as == as possible.
So Configuration of the h/w & version of the S/w are kept. and changes to the environment are controlled.
Version and revision code kept.
This is where you write the documentation and test the documentation against the application....
3 - Live - tight control. Push to live for application and documentation in parallel. May have a staggered roll out / training etc... _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Mon Aug 27, 2007 4:59 am Post subject:
Thanks for your comments as well. We have restled with having to create RFC's for changes to a Dev instance. We have a fear of never getting any work done if we guard it too tightly.
In a mature environment, RFCs are entered long before any work is done in "any" environment, so that they can be planned and addressed through normal lifecycle procedures. Depending on the type of RFC, you will have different levels of approvals and/or control.
The problem arises in that too many people in enterprises want a hand in everything that's going on. The reality is that control of a Dev environment is something that should be far more flexible and rapid than control over a Production environment. However, if you do it correctly, you should still see your Changes marching across all of your environments, sequentially, as the best practice is that if a Change modifies a configuration that other systems depend on, that Change needs to be tested, thoroughly, before deployment to your Production environment.
It's always a smart thing to create and manage RFCs through all environments. It will help you understand their impact, more effectively, long before you try to roll them out to Production.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue Aug 28, 2007 12:37 pm Post subject:
Make sense. We have a long way to go before we are that mature, but it gives us a goal.
It's real simple to become that mature...
Put an attribute on your RFCs that is called "Environment", where the values would be:
- Awaiting Development/Engineering
- Private Workspace
- Common Development Staging
- Common Development
- Systems Integration Testing Staging
- Systems Integration Testing
- User Acceptance Testing Staging
- User Acceptance Testing
- Production Staging
When RFCs are created, always assign them to "Awaiting Development/Engineering" as the default Environment.
Then, ensure that the appropriate groups have regular approval meetings, "before" Development and Engineering starts.
Once the RFC is approved, have the appropriate teams work on it in the appropriate environment(s) and control its promotion to the next environment.
While this isn't a perfect solution (no solution is), it's a solid start.
Frank Guerino, CEO
On-Demand ITIL Platform
This is what we are struggling with. We have defined our change management process as "gate keepers". So any promotion of code to any of our environments, excluding development of course, requires an RFC.
We are not at the point of how to handle software changes up front with RFCs, we are just getting knowledge of "releases" when they want to be deployed into an environment. But I want to change that like you laid out in your previous post.
How do you track the "release" through each environment without an RFC, how does that process work?
Somebody wants to change our application because of an incident or the business requested a new feature, so an RFC is submitted, lets say its to fix a defect found in production.
So the user enters RFC stating the change.
This goes to CAB for review.
Everyone agrees, the change is needed and approves the change.
What do you put in the proposed change date? As in when does the requestor want to make this change. Now, to us this means put change into an environment, not actual go and build.
How do you scheduled the actual change date (we have these on our RFC forms as to when the change will be implelented), would this mean when will it be deployed to production?
What CIs do they pick, say they are changing the current version of XYZ 1.0, they would link the RFC to this, but they would also need to create a new CI XYZ 1.??
Now they go in development and make the change, compile the code and test it and are ready to deploy it to our testing environment. How does the current RFC track this and as well track the CI status/lifecycle? Do you enter another RFC to request deploying XYZ 1.?? into Testing? How does this get approved to go into the testing environment? As we track CIs in our testing environment. Once XYZ 1.?? goes into testing, we would update our CMDB to reflect this, XYZ 1.0 would lose its relationship to the server its installed on and we would create a new relationship to ZYZ 1.?? to that server.
Hope this came out right and you understand where I am going with this.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum