Deployment within Release Management

[apg1]

We are looking at the Release Management at the moment and I am coming to a point where I cannot find a suitable solution for tracking the deployment of a release.
In our environment a "Deployment / Migrations / Rollout" of a release, tracks what is moving from one environment to another. Ie. A release is ready for deployment into a staging environment, or the released code get deployed in Database X > then Database Y > then Database Z > then Production Database. But because we do not always go straight to Production, it does not fit into our definition of Change Management.

Our existing product is a "Migration database" which stamps each "release task" with details of what environment it has been moved to.
I can picture it perfectly for our SN envs:
1. Create a new Release ie. "Service-Now June Build " define scope and await approval.
2. Link any Defects and Enhancements against the release.
3. Build in "SN Development env" and update release to "Work in Progress"
4. Create Testing or Documentation records for the release
5. Once successfully tested create a migration record to push this work into the "SN Test env" to allow business user testing
6. Once successfully tested and ready for production deployment create an RFC within the Change Management processes to push this into production
7. From each "Environment" record in the CMDB you can see the associated release details and when it was updated added to the environment.

So I guess the long winded explanation above leads to the questions... Has anyone found a useful solution in ServiceNow for tracking a Deployment within Release Management? Or does anyone think this might be a useful enhancement?

Cheers.

[gflewis]

I think different organizations have slightly different processes, and as a result you will need to do some customizations to Release Management. If your promotion path is always the same, and the code is not evolving as it moves through different target environments, then you can simply alter the choice values for the "state" field to keep track of where the release is now. If you want multiple Change Requests (one per environment) pointing to a single release, then just add an Environment and a Release field to the Change Request form. However, this assumes that the Change Request varies while the Release remains intact. We use Release Management to track the features that make up a release and we use Change Management to track the deployments / rollouts.

We had a more complex situation when we went to modify Release Management to support the requirements of our database group. They needed to track the fact that the components of the release (ie. features) evolved as the release moved through different environments. We added the Environment and Change Request to the Planned Task table. Then we created a UI Action to promote a task to the next level. This UI action essentially cloned the task and its children while bumping up the Environment. After the tasks were cloned the developers would make changes. Thus you could see that the work in the production environment was different than the work in the QA environment which was different from the work in the development environment. It may sound perverse, but we had to reflect what was really happening.

[apg1]

Thank you. Plenty of information to go from. We are in a great position to pilot this with a team, so different ways of looking at Release is greatly appreciated.