Creating a Change Management System within Azure DevOps

I.T. organizations and the businesses they serve need to be on the same page. Yes, one of those “obvious” leading sentences. But believe it or not, many I.T. organizations can lose sight of that fundamental for a number reasons and get away from disciplined Change Management. It happens. To get back on track with Change Management in a quick and budget-friendly manner, I will outline a method to leverage Azure DevOps with many of the features you might find in a Service Now implementation and even some features that it does not have. If you already use Azure DevOps in your organization, that means you could have a Change Management system by EOD for no additional cost to the business. If by chance, you are using and paying for any product that is not working for you and you find this solution meets your requirements, a bullet point under “savings” (in the thousands) could be on your next Powerpoint.

If you combine a few concepts out of DevOps (DevOps the product, not DevOps the practice…thanks, Microsoft), you can have a feature-rich solution for Change Request (CR) or Request-for-Change (RFC) intake, documented approvals, and much more. I have included links to the official Microsoft DevOps articles below ; I have always found them very informative and helpful.

I need to provide one disclaimer before you read this whole article: What I outline below does not have automated approval workflows. It might be possible with some advanced customizations, but I will stop short of those so this solution is achievable the same day it is started. I contend that if an automated approval workflow is the only feature lacking from a system, but you gain visibility and legitimate traceability into your changes, you should take a look at this solution and coordinate approvals by talking to each other about proposed changes before your Change Advisory Board (CAB) meeting. Talking more to each other is not a bad thing. A few seconds might be saved with an email click-approval, no argument here. Without that feature, there might be 2–3 more clicks…(oh, the humanity!).

So, what are those concepts that combine to provide a reasonable Change Management system in DevOps?

1. Access : People need to be able to access a system, clearly. DevOps allows unlimited “Stakeholders” from your organization, with no additional subscription level needed to see or create work items. Simply add anyone in your organization’s active directory that would need to see, create, or approve CR’s with $0 additional licensing. DevOps is already in the cloud, so no software installs needed.

2. Custom Work Items: With proper permissions (at least Project Collection Administrator), the DevOps organization’s “Process” can be modified. Both Microsoft and I recommend creating an “inherited process” that your organization customizes and uses. In the list of User Stories, Tasks, Bugs, and others, custom work items can be created. This new work item becomes the CR form people fill out. Call the new work item something like “Change Request”, “RFC”, “Change Item”, or whatever makes sense for your team.

Create a custom work item in DevOps and you have an input form for tracking changes.

3. Add Custom Fields to Work Items: Regardless of which process your organization works within in DevOps (Agile, Scrum, CMMI, etc.), custom fields are needed to capture the Deployment plan, the Post Change Validation Plan, the Rollback plan, the list of affected servers or resources, and more. Use the terms your I.T. organization prefers. I will list the ones I use later in the article. I prefix the custom fields with “Change_” to make it clear and obvious which fields apply to this system and to steer clear of other fields in the system. Not only will queries for your CAB dashboard use these fields exclusively and having them together in the list of fields can save time, it can also be less confusing to the rest of the organization.

4. Modify “State” values for your new work item: Work items can have custom State values (“State” is the same as “Status”), such as “Ready for Team Lead Approval”, “Ready for CAB Approval”, “Ready for Implementation”, and “Completed”. These, of course, can be whatever you feel is proper for your team. Modify the states for your new work item and no other work item states are affected. (more on this below)

5. Templates: Many people do not know that you can easily use any work item with completed data to generate a template. There are many functions that the “three dots on the upper right” of a work item provides, creating a template being one of those functions. Templates are stored at the Team level in DevOps next to the Area and Iteration configuration, provides an easy way to establish the value of any field on that work item, and creates a unique URL for each template. Since URLs can be easily bookmarked, a new “Schema Change” CR template is just a click away in a browser or on a dashboard. This can save plenty of keystrokes, especially those repeatable rollout and rollback plans…just type once and then template it. The industry leaders have templating for CR’s, and DevOps’ version may be even easier.

Templating is very easy in DevOps. Capture the field values (highlighted), name the template, and DevOps provides a URL that prefills the fields.

Templates are easy to modify field by field, each with a unique URL to bookmark for quicker entry “next time”.

6. CAB Dashboard : A Change Advisory Board (CAB) dashboard can be created that shows all open changes by Planned Date and State. This could be the literal “same page” that shows everyone’s changes (past, present, and future). If you have never created a DevOps dashboard, you typically create one or more shared queries. Create a query for upcoming changes and one for past changes (or combine them, it’s up to you). Dashboards are made up of widgets, and the widgets typically reference your shared queries (the “query results” widget lists your query results in list form). One could use the query interface itself as the dashboard and that might have advantages that widgets don’t have (queries can easily show the parent/child relationship better than widgets, and including the “Parent” field is better in queries than in the query results widget, etc.). If you wanted a query showing only CAB approved items, the DevOps query is straightforward : Work Item Type = “Change Request” AND State = “CAB Approved”, Sort by Change_Planned_Date_Time (sort is found in the sorting side of the “column options”). The dashboard could include any of the information above and also links for creating a new CR or for any templates (I use the “Markdown” widget for adding custom links).

The following features, in addition to the ones mentioned above (access, templating), are also already built into DevOps, and are generally part of required features of a Change Management system:

· Auditing! If there is any question about the “CAB Approved” status being legitimately obtained (you never know…), the work item History tab has every update to every field. Transparency!

Every work item has a “History” tab that shows who changed what field to what value and when.

· Each DevOps work item is automatically assigned a unique number for reference. This is a small point, but handy for reference in CAB meetings or in “Change Starting/Ending” emails.

· DevOps, commonly being integrated into a company’s Active Directory, allows fields for requestors, approvers, implementors, and additional notifications to be “Identity” field types, rather than a free-form name or email entry. This is very user-friendly and helps avoid typos.

· “Discussion” with email notifications are built into DevOps. Any comments, questions, and answers may be captured on the work item for reference and leverages the “@ tagging” notifications built into DevOps.

“@” tagging sends emails of send friendly reminders about approvals or other actions. Pretend that I wasn’t notifying myself for this demo.

· Once developed, it is easy-to-maintain custom dropdown values for custom fields. DevOps made it easy to initialize a dropdown list of values and just as easy to update it. Your organization may prefer to add “Standard” (the repeatable, low-risk changes) or “Expedited” to your change types, not simply “Normal” and “Emergency”.

· “Development” and “Related Work” links are part of every work item type, allowing numerous User Stories or other work items to be associated with this new Change Request. This feature provides visibility into the entire chain-of-command from a change’s requestor, developers, QA, test scripts and results, deployment plan, approvers, and even the lines of code associated with the change (if the organization references a repository with branching, pull requests, etc.). Future audits expecting to see chain-of-command will be much less painful. This could be a distinct advantage over the expensive Change Management software that would require additional integration efforts to tie CR’s to associated lines of code with such little effort. Bonus feature: have you ever looked at a work item on its own or in a backlog and wondered if it has been implemented or not? Once you add the item as a “Related” link (NOT a Parent or Child link) to a CR, the item reciprocally shows the CR as a related link. The answer to the implementation question is clear. DevOps for the win. While Service Now is very configurable, the instances I have seen simply don’t have the straightforward traceability this solution provides.

On the CR, add a link to a “related item” (or items) for this deployment and have instant traceability, down to the line of code if your organization follows that practice with your User Stories and code repository. Don’t be confused by my initials also being CR.

Work items show the related CRs, answering the question of when it will or when it did go into Production. Someone in the future will thank you (maybe yourself) for this.

· Attachments are built into all work items (attach scripts or other documents related to the change).

All work items (even custom ones) automatically an have attachments tab and functionality.

· Using queries with this new work item type, CAB meetings can use the list of changes that have already been approved (or not) and update the fields “live” on the call as needed, see the changes in planned date order and which approval state they are in, and more.

· DevOps has a built-in “send this query in an email” feature that can be leveraged any time (especially following CAB meeting) to send the planned and approved changes. People can click through to see whatever level of detail about the change they need to see (great feature for Release Managers).

· DevOps has a date & time field type, making things like “Planned Start Date/Time” easy to add. Some solutions (Excel or home-grown especially) might require date and time fields to be split apart, and that can be “clunky”.

· A change that is “Deferred to Later” and then ready to be implemented can be copied (those three dots in the upper-right again). The new copy can then be reset to re-establish the approvals while the original remains as an historical record. I recommend this approach, as it would be easier to look at the previous planned date as it was versus fishing through the item’s entire history tab looking for it.

Work items can be easily copied.

Those features are enough for a solution that beats chaos or Excel by a mile!

Here are some more technical suggestions based on my experience, in case you find them useful:

The “Assigned To” field should be reserved for the person performing the change. If a third-party not in the company’s active directory is performing the change, leave it blank and indicate that third-party in the “Team” drop-down.

Updating the “State” values for your “Change Request” work item:

Microsoft considers these higher-level categories of your work items for backlog filtering and other purposes: Proposed, In Progress, Completed, and Removed. You can add States within those higher-level categories.

1. Proposed -> New (no change on this one)

2. In Progress -> Seeking Team Lead Approval, Seeking CAB Approval, CAB Approved, Implementation in Progress

3. Completed -> Closed (no change on this one)

4. Removed -> Canceled, Deferred Until Later

Modifying the Change Request “States” to apply to Change Management

Create a new “Overview” tab (1 of 3):

Add the following “custom fields”:

1. Change_Requested_by (can use built-in “Requested by”)
2. Change_Team (drop-down: Security, Data Engineering, Development, CRM, Infrastructure, a partner, etc.)
3. Change_Type (drop-down: Normal, Emergency, Expedited, Standard)
4. Change_Planned_Start_Date_Time
5. Change_Planned_End_Date_Time
6. Change_Actual_Start_Date_Time
7. Change_Actual_End_Date_Time
8. Change_Resources (as a text box), not as robust as a CMDB
9. Change_Description (text box, meant to be high-level for discussions)
10. Change_Systems_Affected (multiple select or check all that apply, helps to identify other potentially impacted systems)
11. Change_Outage_Risk (text box)
12. Change_PreChange_Validation (text box) — what steps were taken or will be taken to certify the change for production and mitigate the risk identified in the previous field

Create an “Implementation” tab (2 of 3):

1. Rollout Plan (or “Implementation Plan”) (text box)

2. Validation Plan (text box)

3. Rollback Plan (text box)

Create an “Approvals” tab: (3 of 3)

These fields are all “Identity” fields, and are meant to be updated by the approvers themselves, not by the creator of the RFC. The History/Audit tab shows the truth. An ideal solution (found in other solutions that come with the $xx,xxx pricetag) would have built-in logic to automatically notify the next person to approve based on the implementation team’s pre-set approval workflow (whew, a mouthful!). This is not that solution (see earlier disclaimer). Perhaps a “win” for the expensive software, but sometimes people click-approve without properly reviewing everything as they should. Customize the approval fields below to fit your needs, as sometimes more people (multiple IT Team leads or business stakeholders) need to document their approval.

1. Change_Team_Lead_Approval
2. Change_Additional_Approval 1
3. Change_Additional_Approval 2
4. Change_CAB_Approval
5. Change_Business_Approval_1
6. Change_Business_Approval_2
7. Change_Business_Approval_3
8. Change_Business_Approval_4
9. Change_Business_Approval_5

Custom tabs created for Overview, Implementation, and Approvals

Advanced concepts could include:

· Making certain fields “read-only” prior to or after a certain state or level of approval has been reached is straightforward. It can be both a feature and a point of confusion, though, so consider both sides of that coin. For example, a “rule” can be created so that When State=New, make each approval field “read-only” . (In the interface, you indicate each field individually.) It can be a feature to prevent someone unfamiliar with the process from indicating approval improperly, but can be a nuisance when a team lead creates the RFC and also needs to approve it. The learning curve for the team lead would be that it would need to be saved as New, then changed to an alternative State value prior to adding the approval. You can choose what is right for your organization and change it if there is gnashing of teeth with your first choice.

· There are more possibilities for “Rules”, but there is a point where there is increased processing overhead as more rules are applied. It might not be worth the time and effort to overthink and overapply rules. (It’s up to you, though!)

In closing…

I believe in incremental improvement. Google “Kaizen” if you aren’t already familiar with the idea. I contend that if you are in need of a solution and already use Azure DevOps, you can have Change Management software by the end of the day without spending another dime. I have taken this approach with other custom work items types in addition to Change Requests, including Service Requests (tickets) and even Access Requests towards improved I.T. General Controls, maintaining approval logs suitable for smoother audits.

Please remember that habits and routines have inertia. People are trying to remain productive as you introduce something new (like a Change Management system in DevOps). Give people time to adjust and just keep reinforcing good, new habits. Be positive and remember that the point is for us to communicate and to be coordinated with our changes. If that is happening in any capacity, acknowledge the progress, appreciate the positive effort & attitudes, and continue to encourage good discipline.

If this helps you in any way with a Change Management solution, I would love to hear your story! And remember to “Have a Great Time Doing Great Work!”

Chris on LinkedIn

DevOps Support Links:

Create an inherited process

Create a custom work item type

Add a custom field to a work item type

Customize the web layout for a work item type

Capture a work item as a template (Alternatively, define the URL of a work item)

Traceability and linking

Quick query reference

Apply rules to workflow states (advanced)