Hey David, thanks for the reply!
My request was more for infrastructure changes at as a whole, not relating to code (our team has that covered with the appropriate usage of devops
)
While a project would technically work, it would work for initial changes only…
A literal example of what I am using Azure DevOps in an absolutely horrible way for (yes, that’s my orgs issue not yours, but sympathize please!)
Asset - SQL Server (Specifically Azure with Networking whitelist):
Change 1: Dev 1 needs direct access for some asinine reason (not my problem to say no, but my problem to track)
Change 2: Dev 2 decides he needs this, do the same thing
Change 3: Remove those IP whitelists
We do not run infrastructure as code (nor does it look like we will get there in the near future) so changes like this can run amok. It is not feasible to create a project for each asset and continuously add tasks, that seems like a backwards way of using that feature. Plus, that would absolutely get in the way of our actual projects, making that area extremely cluttered.
With the way I am suggesting, I would have one parent object (the asset) and multiple ‘changes’ (like a review) made on that asset. Whether it be installing an additional service on a server, whitelisting an IP, disabling a registry setting, installing a major upgrade on a system that is not linked to code…you get the picture.
And I have also considered using asset reviews to do this as well, but again I run into the issue of it cluttering up with our actual audits.
My absolute ideal process on this would be:
- Asset has CM
- CM is stored much like reviews are
- Risk assessments can be made based off of the CMs if necessary
All of that tied into a nice little bow seems a lot nicer than a glob of projects.
Thank you for your consideration!