I have an Azure DevOps instance where I am trying to control and monitor who is doing releases. So, who pressed the button to do the release and what releases have happened.
I tried in Audit options, but it is not satisfying my requirement.
What is the best way to get what I am looking for?
Thanks in advance…
It's a little unclear what you mean by CONTROL
If you are needing to tighten control of which users are allowed to initiate releases outside of a CI/CD pipeline, this is something you would use the built in object permissions for release pipelines.
I've organized our release pipelines into folders
Each of these folders is treated as an object upon which permissions can be set.
For MONITORING the release pipelines
Again, I tend to just use the All Pipelines folder which gives a list of the releases that happened ordered by date. That view lists the pipeline and gives the users Avatar, which is enough to know who created the release.
Also
There are some out-of-the-box widgets that you can put on your dashboard, but I've found them to be unhelpful on the whole. Not to mention that if you have 100's of pipelines you will want to have something reading from your list of pipelines via REST api and pushing those widgets onto the dashboard via the REST api so that you don't need to manage them all "by hand" through the UI. Then if you're going to get into using the REST api, you might as well write your own tool to report the information you need (and possibly turn it into a widget others can consume from the marketplace). I haven't found anything very effective on reporting/summarizing the collection of release pipelines from the marketplace, but there may be something squirreled away in there somewhere.
Related
Enviroment:
Azure DevOps
Action required:
To duplicated a custom Work Item to be rehused for others that requires that exact same lyout
Detailed description:
For a new Team Project is required a very specific setup, that was not easy to anchieve and needs to be replicated across all the rest of Work Item types like User Stories, Tasks, Fetures and so on and it would consume to much time do it manually (we are system engineer so there is always a better way ;) ) so for that reason is required duplicate the Taylored work item
I am afraid there is not such a feature to duplicate a custom work item tpye in azure devops currently. You may have to manually duplicate the work item types.
You can click here to submit a feature request to microsoft development team. Hope they will consider implementing this feature in the feature sprint.
I use Azure DevOps to track work items and bugs for a project. I'd like to grant certain people external to the project a read-only view of work items that are related to them (eg. tagged Person X), but without having to grant them access to DevOps. I have been toying with the idea of setting up a flow in Power Apps to continuously update a shared excel spreadsheet based on work items in DevOps, but I fear I might be missing easier/better options. How would you provide a limited read-only view of a backlog to externals?
I'd like to grant certain people external to the project a read-only
view of work items that are related to them (eg. tagged Person X), but
without having to grant them access to DevOps.
For this issue , I am afraid that this is unachievable in azure devops. At present, there is no such permission setting in azure devops to restrict external people can only read work items with specified tag.
You could add your request for this feature on our UserVoice site , which is our main forum for product suggestions.After suggest raised, you can vote and add your comments for this feedback. The product team would provide the updates if they view it. Thank you for helping us build a better Azure DevOps.
I need to refactor a .Net Web API, I'm considering moving to serverless and I'm trying to understand the best option to migrate the code to Azure Functions.
As far as I understand the correct approach to reduce costs and cold start time is to split the API: it is much better to have many small web api than a single one with all methods. Small api consume less memory and cold start quicker.
Having more Functions in the same Project does not resolve the problem as they would be all deployed in the same Function App so one dll, high memory, slow cold start.
So I should create several Azure Function Projects and deploy each of them in a different Function App.
If all the above is correct we finally got to the problem:
I would structure the code and the repo so that I have one Solution containing several Azure Function Projects. How can I have a CI/CD (Azure DevOps) so that when I push the repo ONLY the Azure Function Projects updated/modified/new are deployed? I need to deploy only the modified Azure Function Projects so not to have all the Function Apps (also the ones whose code is unchanged) goes cold.
This is less important but I'd also need to have one URL for all APIs, so https://myapi.azurewebsites.net/api/Function1, https://myapi.azurewebsites.net/api/Function2, etc and not https://myapi1.azurewebsites.net/api/Function1, https://myapi2.azurewebsites.net/api/Function1, etc. Is this possible using the above structure?
You need to have multiple CI/CD pipelines with trigger limited only to specific folder:
trigger:
paths:
include:
- function-a/*
exclude:
- '*'
for this you will get pipeline triggered only if changes are done in function-a folder. To limit a work needed to develop pipelines you should consider using templates. You can find more info about this here:
Template types & usage
Build templates on Azure DevOps - this is my ow blog
In this way you will avoid repeating yourself.
EDIT
To unify your API you can use Azure Functions Proxies
With this feature, you can specify endpoints on your function app that
are implemented by another resource. You can use these proxies to
break a large API into multiple function apps (as in a microservice
architecture), while still presenting a single API surface for
clients.
I'm using Azure DevOps Server, Update 1.1. I'm working in a collection that's using the Inheritance process model.
I'm demonstrating a CMMI process template project to my product owners. For any one work item (e.g. a Change Request), I want to show them the overall state-transition workflow. For example, JIRA has a feature that lets you view the overall state-transition workflow for a work item (see screen shot below).
I'm not looking to edit or customize the workflow. I just want to see the overall state-transition workflow for a particular work item
Is there something equivalent to the JIRA feature in Azure DevOps Server?
You can find this in documentation:
While working on a single Azure Data Factory solution with no Source Control. Is it possible to work parallelly for a team of 3 or more developers, without corrupting the main JSON?
Scenario:
All developers are accessing the same ADF and working on different pipelines at the same time. One of the developer publishes his/her updates, does it somehow overwrites or ignores the changes other developers are publishing?
I tested and found that:
Multiple users can access the same Data factory and working with
different pipelines in same time.
Publish only affect the current user and the current pipeline which
user is developing and editing. It won't overwrites other pipelines.
For you question:
Is it possible to work parallelly for a team of 3 or more developers, without corrupting the main JSON?
Yes, it's possible.
One of the developer publishes his/her updates, does it somehow overwrites or ignores the changes other developers are publishing?
No, it doesn't. For example, user A only develop with pipeline A, then publish again. The Publish only affect the current pipeline, won't overwrite or affection other pipelines.
You could test and prove it.
Update:
Thanks #V_Singh for share us the Microsoft suggestion:
Microsoft suggested to use CI/CD only, otherwise there will be some disparity in code.
Reply from Microsoft:
"In Live Mode can hit unexpected errors if you try to publish because you may have not the latest version ( For Example user A publish, user B is using old version and depends on an old resource and try to publish) not possible. Suggested to please use Git, since it is intended for collaborative scenarios."
Hope this helps.