This is part 6 of the DevOps with VSTS series
By leveraging the ability in VSTS to create custom WorkItem Types, feedback flows that don't already have a supporting WorkItem can be easily created.
VSTS already supports different flows of feedback, like feedback about a bug that can be tracked in the Bug WorkItem type.
This post will show how to set up the following items:
To be able to add custom WorkItem Types, first a custom Process Template needs to be created.
To do this, browse to the Settings => Process tab, select any of the existing Process Templates and select Create inherited process.
The Agile process template already has a lot of the features that are applicable to a DevOps approach, so it's best to select that process as the template to inherit from.
After selecting the Create inherited process, name the new template DevOps and give it a meaningful description.
When done, select Customize DevOps to start adding custom WorkItems.
A Live Site Incident (LSI) will be used to track any issues there are on the production system.
The LSI will be used to have a detailed timeline of an issue, what the consequences are of that issue what caused the issue and how it was resolved.
Using this data, recurring issues can be identified and can be used to determine parts of the system that need to be more resilient.
To start adding a custom WorkItem, click Add new work item type and name it Live Site Incident.
In the WorkItem Type edit form, browse to the Layout and rename the Details page to Summary.
In the Summary page the details and timeline of the incident will be placed by the Engineer working on the issue.
In case it is a LSI generated by an automated detection, some of the fields will be automatically filled in.
A automated detection method will be described in Monitoring The Picklists in the details group contain the following:
The Impact page will be used to describe what the impact of the issue is.
This will contain something like: Customers unable to complete payment when paying with creditcard.
The Mitigation page will be used to describe how the issuer was mitigated.
This mitigation will help tremendously in determining the Root Cause Analysis and to help other engineers if a recurring incident happens.
The Root Cause Analysis page will be used to describe the root cause of the incident.
Analyzing every incident and determining the root cause of an incident will help in determining whether certain parts of the system aren't resilient enough and need improvement.
The last step to complete the LSI type is to modify the states. Modifying these states makes sure that the status are more clear then when the default states are used.
Browse to the States for the LSI and change them as followed:
A Live Site Change Request (LSCR) is used to keep track of all manual changes on the live system.
In a LSCR detailed steps to execute the change are recorded, as well as the steps needed to validate if the change was successful.
Add another new work item type and name it Live Site Change Request.
Again browse to the Layout section and change the existing page.
The final step is to start using the newly created DevOps in a project.
When creating a new project, the DevOps template can obviously selected.
But it's also possible to use ith with an existing project.
Only projects that are currently using the original parent template (Agile) can be converted to the new DevOps template.
To convert them, browse to the Process settings page, right click the DevOps template and select Change team project to use DevOps.
The next post Monitoring will look into getting feedback about the system and show a way to automate parts of providing this feedback.