Change Management , Release Management and DevOps (Gitlab spoke)

[xjxx]

Hello Everybody,

In regard to Change Management and Release module are they two separate processes within servicenow, that someone can raise change request, while decide to raise a release or are they integrated (meaning I can invoke a release from the change flow and come back to the change after certain phase of the release and so on ?

The second part is about DevOps, can I integrate the DevOps Action with the change and release modules ? such as invoke deploy of release to production from Gitlab after the release been developed, change approved and schedule time of deployment reached ? then come back to close the release and change enter post implementation review ?

[jMarshal]

I don't think ServiceNow supports that OOB -- having a change (change_request) spawn a release (rm_release). In theory, the release should be quite far along before you engage Change Management.

Change Management isn't intended to help plan the development of a software product or release (the "changes that could happen as a result of the release", if you will)...rather, it is more so for coordinating activities related to the actual technical configuration changes that would be happening for the release, record the approval (authorization) and measure the success for deployment/implementation of a release (IE - the "changes that will be caused by the release" and "did it go according to planned?").

These do probably seem like they are the same, but they really aren't. One approach tries to use Change Management to mitigate risk related to dependencies...and that's not really what Change Management is for. Instead it  describes and reports on risk and impact, which is often "tied to" or a "result of" service/ci dependencies/relationships...but it's not for the purpose of identifying those dependencies and reworking your development plan, to accommodate those potential risks/issues.

Perhaps I'm assuming too much about your situation...

I suppose you could have the CR raised by someone who is not that technical and planning begins before the release is considered...but in that case, you should consider off-boarding those activities to Idea and Demand management, instead of having the initial idea for feature enhancements spur a CR. If it's a bug/fix, that sits in Incident/Problem until it goes through project management > product management > dev/devops > release management > change management > service operations.

Change is almost always the last step before operations and if you are engaging it early, there is probably another process you can replace those activities with.

I hope this helps a little bit. We are currently going through a process of re-baselining change management because we had too many planning tasks in our process, which was causing us to stall-out when trying to use the oob features that are related to those actual activities (SPM stuff, mostly...but also some ITOM stuff).

[xjxx]

Hi jMarshal,

Thank you very much for this. I agree with you in regard to having a new initiative or feature to go through idea/demand process or let's say (Change Control).

Following approval of the idea, a project can be initiated or a direct release and change requests to be created (depending on the idea cost if it is qualify as Project or not).

I will come back to the above in later discussion. But let us come back to the release and change management.

Now as it is widely known the change have implementation phase, and the release has deployment phase. The release will have remediation or early lifecycle phase following deployment and change will have post-implementation review.

I believe the implementation (during change) and deployment (in release) are interconnected.

When the release build and test phase is complete, then (from my point of view) this needs to reflect into a change. In the change the request need to select the Service, and CI that will be affected to get into proper risk and impact of the change and to know which other changes related to this service will be impacted too, attach recovery procedure and go through some security PT testing maybe. Then the CAB need to provide recommendation on the change timing and the business owner of the service to approve, if this is a DevOps related (internally developed code, then the timing of deployment need to be reflected on the release flow, and DevOps pipeline. When delopyed by the pipeline then this need to be reflected back into the release deployment phase and release reflect this on the implementation closure phase to start the post-implementation review phase.

Side Note:

- As per the flow you mentioned dev/ops >> Release >> Change Management. So there is a relation and I believe implementation and schedule need to be set and agreed somewhere and reflected in other modules.

- Other people models use releases to combine changes from Change Management Process. While I believe those can be ideas/demands (Changes Controls). 

- In regards to the DevOps >> Release, I believe when the idea or demand approved, the release need to be created, when the release  ( planning --> Design ) pass and the development phase start, the DevOps will get involved and when the code done and uploaded in the DevOps system (Gitlab/GitHub/Jenkins, etc) the development will be marked complete and the Build/Test phase start.

Those are my views about the flows and how they are supposed to work. I was hoping to be able to link and make some affect between the different flows for Demand/Change Control, Release, DevOps ,Change Management. I am looking to try to build and push such flow in our environment.

[jMarshal]

---

@xjxx wrote:

I believe the implementation (during change) and deployment (in release) are interconnected.

 yes, I can definitely see that connection...I don't think there is anything oob to support it in that way. We aren't mature enough in SPM yet for me to know for sure what the oob activities and features that the deployment stage actually has in platform.

Outside of the platform, we just have the change process as a step in deployment, almost the last step -- where the maintenance and warranty portion are accomplished while the change is in review (waiting for incidents to be linked, if needed).

---

@xjxx wrote:

When the release build and test phase is complete, then (from my point of view) this needs to reflect into a change. In the change the request need to select the Service, and CI that will be affected to get into proper risk and impact of the change and to know which other changes related to this service will be impacted too, attach recovery procedure and go through some security PT testing maybe. Then the CAB need to provide recommendation on the change timing and the business owner of the service to approve, if this is a DevOps related (internally developed code, then the timing of deployment need to be reflected on the release flow, and DevOps pipeline. When delopyed by the pipeline then this need to be reflected back into the release deployment phase and release reflect this on the implementation closure phase to start the post-implementation review phase.

I think you are right-on, here...and I think that ServiceNow could probably support this very well in concept with minimal configuration (customization) to really tighten it up...but I don't think this is that tight oob, yet.

You'll definitely need a new, custom change model to support the DevOps side (this is normal for oob change in platform), but you can probably set something up through low risk BRs and Client Scripts to support the integration of deployment phase activities into the CR initiation (like auto-populating the CI and making it read-only, etc).

I don't know much about the Digital Product Release stuff that Atul (@Dr Atul G- LNG) is referring to, but it is intriguing! Often ServiceNow will fill gaps with OOB features as they see clients like us using it in ways that are logical and fit with their roadmap/paradigm, but aren't available OOB yet....like an actual link between release and change! haha

---

@xjxx wrote:

Those are my views about the flows and how they are supposed to work. I was hoping to be able to link and make some affect between the different flows for Demand/Change Control, Release, DevOps ,Change Management. I am looking to try to build and push such flow in our environment.

---

With the thought that you've put in here, I think you'll be successful with some minimal customizations, to support your ideas on the way to tighten-up the platform features to better support a logical, recommended best practice lifecycle for software/middleware with more automation!

Best of luck! 🙂

[Dr Atul G- LNG]

Hi @xjxx 

In regard to Change Management and Release module are they two separate processes within servicenow, that someone can raise change request, while decide to raise a release or are they integrated (meaning I can invoke a release from the change flow and come back to the change after certain phase of the release and so on ?

Atul: OOTB there is not linking or dependency between these 2. If you want, you need to update the flow make it possible.

The second part is about DevOps, can I integrate the DevOps Action with the change and release modules ?

Atul: Yes, if you are on latest Release D.C. SN introduced a new product called DPR - Digital Product release , which provide a linkage of Release with Dev Ops tool

such as invoke deploy of release to production from Gitlab after the release been developed, change approved and schedule time of deployment reached ? then come back to close the release and change enter post implementation review ?

Atul: It is still in new phase, so not sure, but if we can configure it via flow.

If you want to know more about DPR please join this session

Introducing Digital Product Release – revolutionize your release and change processes

  Please click this URL to join. https://servicenow.zoom.us/w/98174504923?tk=4ToO5yg-vYFULNcoN3-L5aIdZzpsq3N1TIuc52nCiZ0.DQYAAAAW26gP...

Tue 4/2/2024 4:00 PM - 5:00 PM