Ask HN: How to track tickets across DevOps | Hacker News Reader

Ask HN: How to track tickets across DevOps

2 pointslbriner5 comments

I am not sure if I should be trying to do this but currently, our Task tickets are set to Done as soon as the commit(s) are merged. Backlog Items (PBIs) are manually set to "Ready" once all the tasks are done and when manually deployed to production are manually set to "Done".

In the name of automation and visibility, it seems to me that Tasks or Backlog Items (and maybe bugs and features) should have a status that maps to a number of CI/CD statuses, ideally automatically. Perhaps the task is set to "Done" as per Scrum but then the PBI should somehow track perhaps "Merged", "Built", "SystemTest", "Production" or equivalent which gives the PO easy oversight of where things are and when they are ready to test etc.

The problem I am having is that there is no obvious correlation between the fact that a build might only contain a subset of tasks and will not have any concept of the PBI or when it is completed by all tasks being finished so it would only ever be able to set task statuses. If I tried to build something based purely on the status of tasks, then that sounds like it would break the concept of a Task being "Done" as soon as it is merged and would potentially be complicated e.g. when all tasks are set to Built or above, set the PBI to built.

Am I misunderstanding? Should I be trying to track my backlog into Production or is it better to assume that things are Done as soon as the CI starts and any failures/deployments/releases should be tracked separately? I am using Azure Devops if that is relevant.

I read this over a few times and am having trouble understanding the workflow you are trying to achieve. PBIs are Pending Backlog Items?

I think where you are going wrong is that you are saying Tasks or Backlog Items should map to CI/CD statuses. This is not always the case. Depending on the actual task (or feature) you may not always have a status in your CI/CD pipeline.

The "Done" state of a task is something I've had conversations about in many organizations as they try to mature their processes. In many cases it needs to be broke out more (waiting for QA / done but waiting for internal verification / etc).

Sorry for the confusion. I guess the simple question is do I either a) Set as task to Done as soon as the code is merged or b) Only set it to done after it is deployed to production.

If b) how can I map CI/CD tooling back to tasks so that they can track and update these tasks.

PBI = Product Backlog Item as distinct from a Bug. 1 PBI = 1 or more tasks.

This really feels like a workflow issue where you have to discuss with your team how to best categorize the work. I've seen below categories with state transitions work well..

* TODO

* In progress

* On hold

* Awaiting feedback

* Pending Release

* Done

This sounds correct but I cannot find articles that talk about how these are automated in real life to avoid someone having to manually watch for the various deployment stages and update tasks or PBIs manually.

It seems like something that everyone would try and automate in a devops organisation so I am not sure how to search for e.g. "Tracking and automating task updates in Devops".

Maybe it is simply a question of basic webhooks but most tools seem to track commits rather than tasks so it might be quite messy trying to reverse engineer the task numbers for each commit so that the CI/CD tool can update the task.

I never bothered to automate anywhere I worked... it is a <1 min task done once a day, which is usually more useful if it comes with a higher level human description.

The automations I've had is to link jira to gitlab or perforce based on regex from the comments so that people can easily click around code and discussion.

Reply on news.ycombinator.com