Anatomy of implemting a REST Api endpoint – Part Three

This writing is about how Azure DevOps can support software delivery.

So far there is a feature ticket about Dimension Structures CRUD functionality, and listing and adding new functionalities already implemented. Let’s see how Azure DevOps implement transparency in software delivery.

Dimension Structure CRUD ticket can display that to how many chunks (story tickets) this job was splitted and the status of these tickets. This way possible to track the progress of implementation without being distracted by lower level, development related information. Beside these you can use deadlines, risks and effort fields to track your progress, but, since I’m the only one working on this project I don’t use these.

Screenshot 2020-01-15 at 17.19.20

A story, attached to a feature as child, can show all the delivery related details you need to know to be able to see what happened. In my case the folowing data is displayed in a story ticket:

  • On which branch the implementation happened.
  • Build related information. There are two types of builds, one is just build, the other one is “Integrated in”.  You can attach multiple from both. I use the first type to mark the build where the full implementation successfully built on the server. Test results are displayed on the build page. In case of bigger projects it might be overkill. For me works fine. I use the “Integrated In” links to mark the build where the particular implementation went in to master branch. Master is the release branch.
  • Tasks for tracking different development related activities, and where you can track your time and remaining time. At this level also possible to mark a build where this job was completed/integrated. It is useful in case of bigger team where multiple developers work on a story. In my case, it would be overkill, however, builds automatically attached to the task.
  • Pull Request, which contains all the info needed to be able to review and merge the code change into master or other branches.
  • Test related stuff, I can’t use this part of Azure DevOps because I don’t use VS so I don’t know yet how to connect test cases in a dll to test cases in Azure DevOps. However, it is a really powerful feature and increases transparency.

Overall, when I put the delivery manager hut on my head and I want to know what is the status of the team deliveries then a well managed board can help a lot, especially when the tool, in this case Azure DevOps, does the majority of the work for you.

The master branch looks like this. Clean and lean…

Screenshot 2020-01-15 at 18.06.03

Feel free to dig the tickets in my Digital Library project.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s