I want to make a pipeline (or azure workflow of any kind) that deploys a snapshot of my software to somewhere for User Acceptance Tests, then having people approve this User Acceptance Test and after successful approvals deploy the very same snapshot to the final production place.
Having "Approvals & Checks" configured for an environment and making a YAML-Pipeline with a "Production"-Stage which is assigned to that environment solves the problem.
But only if I had one group of approvers.
In my case there need to be 3 groups of approvers with different rules each that should be able to have their approval process at the same time (to make it as fast as possible):
Change Advisory Board when one more than 50% of the assigned Change Advisory Board members give approval
Tech Review when anyone of the assigned people gives approval
Design Review when anyone of the assigned people gives approval
Any idea how to do that?
Related
I've been looking at organisation and project settings but I can't see a setting that would prevent users from creating work items in an Azure DevOps project.
I have a number of users who refuse to follow the guidelines we set out for our projects so I'd like to inconvenience them and the wider project team so that they find it better to follow the guidelines than not - at the moment we've got one-word user stories and/or tasks with estimates of 60-70 hours which isn't reflective of the way that we should be planning.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
The Azure DevOps Aggregator project allows you to write simple scripts that get triggered when a work item is created or updated. It uses a service hook to trigger when such an event occurs and abstracts most of the API specific stuff away, providing you with an instance of the work item to directly interact with.
You can't block the creation or update from, such a policy, Azure DevOps will inform the aggregator too late in the creation process to do so, but you can revert changes, close the work item etc. There are also a few utility functions to send email.
You need to install the aggregator somewhere, it can be hosted in Azure Functions and we provide a docker container you can spin up anywhere you want. Then link it to Azure DevOps using a PAT token with sufficient permissions and write your first policy.
A few sample rules can be found in the aggregator docs.
store.DeleteWorkItem(self);
should put the work item in the Recycle Bin in Azure DevOps. You can create a code snippet around it that checks the creator of the work item (self.CreatedBy.Id) against a list of known bad identities.
Be mindful that when Azure DevOps creates a new work item the Created and Updated event may fire in rapid succession (this is caused by the mechanism that sets the backlog order on work items), so you may need to find a way to detect what metadata tells you a work item should be deleted. I generally check for a low Revision number (like, < 5) and the last few revisions didn't change any field other than Backlog Priority.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
I am afraid there is no such out of setting to do this.
That because the current permission settings for the workitem have not yet been subdivided to apply to the current scenario.
There is a setting about this is that:
Project Settings->Team configuration->Area->Security:
Set this value to Deny, it will prevent users from creating new work items. But it also prevent users from modify the workitem.
For your request, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions.
We are developing a complex system using scrum methodology with 1 week sprints and a team of 6 developers.
We continuously update the source code on every developer machine when the changes are tested and integrated on the development branches, and the developers daily integrate the changes to a test common server.
But the production system is critical enough for any issue or downtime to cause much $ lost, and the deployment process is slow, hard and delicate. Even if the system changes are tested and even deployed to a test server, sometimes problems arise when we try to publish the whole week progress as a lot. Thus, we have chose to have a previous deployment process which happens after all the week development is completed and deployed to the test server. We run full feature tests on the whole week changes on the test server, then publish the week work lot to a preproduction server, then sometimes everything goes fine but sometimes some new problems arise on the deployment process or the published changes, then we plan the highly delicate production process and execute it on the next night we can, avoiding any downtime for the customer work.
Now, we are having discussions with the customer since he defends this is not scrum because he isn't gettint the sprint result on the scrum day, but three days later. But obviously we can't start the pre-release and release process until the sprint completes totally - so, next day - and then the system complexity and criticality forces us to secure the deployment process to the top, and the customer production usage requires also some special operation scheduling.
Are we working against the scrum guidelines? Where is the deployment process on the scrum methodology? Is scrum appropiate for this project?
the deployment process is slow, hard and delicate.
When a deployment process is hard, it tends to mean organisations deploy less frequently. If they deploy less often then releases become bigger, more difficult and more critical. This tends to mean that there is even more reluctance to release.
This negative cycle works against Agile as it means organisations struggle to respond to change.
The best thing you can do is try and break out of this cycle by improving the release process. This may be difficult and consume time and resources, but the benefits are significant.
If you can automate your releases then you tend to reduce the risk. With the risk lowered then releasing more frequently becomes possible. Frequent releases means that the size of releases is reduced and you can quickly fix bugs if necessary.
Frequent releases also make the customer happier as they get more opportunities to provide feedback. The more feedback they give, the sooner the product will be what they want.
Perhaps a good place to start would be to automate the releases you currently make to the common test server. Once you have been doing this for a while you should have the confidence to use the same process on production.
Barnaby has the ideal answer. In the meantime, one possibility is to have a repeating story each sprint to release the approved stories from the previous sprint. Per the Scrum Guide, a team only delivers "a potentially releasable Increment of (a) 'Done' product at the end of each Sprint." The key word is "potentially." In addition to the problem you face, I have been in companies that only released once a quarter because that is what the customers wanted. If your customer wants a release every sprint, great, but nothing in the guide requires that to happen in the same sprint the stories are accepted in.
To clarify based on the comment, let's assume a team is using a traditional Dev-Test-Stage-Production architecture. The customer would review the changes in Stage (during the Demonstration Ceremony if not before). Accepted stories go into the release, which moves to Prod as part of the recurring "Release" story in the next sprint.
In Azure, you can limit deployments with gates and approvals. Gates are usually some sort of status or health check. Approvals require a certain user or group to manually approve the deployment.
Is it possible to combine the two?
For example, I'd like for a deployment to require an approval but only if it's before 8 am or after 5 pm.
Another example would be to require an approval if the application is not live (liveness would be determined by a REST call).
No there is no way to create "conditional approvals" this way. You can schedule Gates and/or approvals but can't make one dependent on the other. The only thing you can configure is to ignore the gate and still ask for approvals or ask for approvals and then run the gates.
But what you can, using a custom release gate (Azure Function for example), is to do the required check and then use the Azure DevOps REST API to edit the release instance. An azure function with the right permissions could either enable or disable the approvers on the environment or override an approval.
An example of how to do this can be found here:
https://abelsquidhead.com/index.php/2017/12/25/creating-async-custom-automated-release-gates-in-vsts-with-rest-api/
https://github.com/Microsoft/azure-pipelines-tasks/blob/master/docs/authoring/gates.md
https://github.com/Microsoft/azure-pipelines-extensions/tree/master/ServerTaskHelper/DistributedTask.ServerTask.Remote.Common
From this link it appears that Agents have been renamed to Pipelines. https://www.visualstudio.com/en-us/docs/setup-admin/team-services/get-more-build-or-load-testing-vs
It also states that "Private agents are now free and unlimited." From Build & Release, Resource Limits, I show one free Pipeline.
We tried to add a second private agent to our VSTS and received the error:
"No more private agent slots available, please purchase more. For more information visit: https://go.microsoft.com/fwlink/?LinkID=623705 Current max: 1 Xaml Controllers: 0 Build Agents: 1"
From the link above it'd appear we did what we needed to do and should be able to add aditional agents. Any idea why we can't add an additional agent and Current max is 1?
Thanks for reporting this. It looks like there is a problem with the logic so the engineering feature team is going to deploy a fix that should fix this problem. You are right: you can have unlimited agents and concurrent pipelines is what we are transitioning to charging for where pipelines can leverage multiple agents if needed.
We have not switched from the agent-based model to pipeline model yet in Team Services. As we are still in the agent-based model, you will see this error if you have not purchased enough agents. We plan to switch to the pipeline model late January or early February.
I have created and added some workflows to CRM 2011 RU13, through the UI
Through not fault of my own my development environment is completely air gapped from my production environment.
I added these workflows to my solution and exported the solution as managed and given the solution to the production admin.
When he deploys it fails with this message.
The workflow cannot be published or unpublished by someone who is not it's owner
How do I fix this. There is no way to not give workflows an owner. or say that the owner is the solution.
The production admin gets that message because he is not the owner (inside the target CRM environment) of one or more active workflows included in your solution.
This happens in these situations:
First time you give your solution to be imported, is USER_A to
perform the operation and all the workflows are assigned automatically
to him. If later USER_B try to import an updated version of the
solution he gets the error message because is not the owner of the
workflow(s).
First time you give your solution to be imported, is USER_A to
perform the operation and all the workflows are assigned
automatically to him. Meanwhile one or more workflows are assigned to
USER_C. If later USER_A try to import an updated version of the
solution he gets the error message because is not the owner of the
workflow(s).
Before a workflow can be updated must be first deactivated, and only the owner can deactivate a workflow. This is by design.
In your case the production admin must be the owner of the processes (he can assign temporarily the workflows to himself, import the solution and after assign back to the right user) or needs to be the owner of the workflows to import the solution (if he has the rights)
A couple of additional points for clarity for the OP:
The owner of the workflows in your dev environment is not relevant, the importing user in prod will become the owner (this does not contradict Guido, I'm just making sure you don't follow a red herring). It is quite right for their to be an "air gap" between dev and prod.
If you know which workflows are in your solution, assign those in prod to yourself, then import, then if and only if you need to, reassign them to the original owner(s).
You may not need to if that owner is just an equivalent system admin user, but if it is a special user (eg "Workflow daemon" so users can see why it updated their records) you will want to re-assign.
Note that after re-assigning them, that user has to activate the workflows. You cannot activate a workflow in someone else's name (or users could write workflows to run as admins and elevate their priviledges).
If the workflows have not actually been changed in this version of your solution, take them out of the solution and ignore them - often I find that a workflow has been written, carried across to production in the original "go live" and is then working perfectly fine, but is left in the solution which is constantly updated and re-published (ie export / imported).
Personally I often have a "go live" solution (or more than one, but that's a different thread...) and then we start all over again with a new solution which only contains incremental changes thereafter. This means that all your working workflows, plugins, web resources etc do not appear in that solution so this avoids confusion as to versions, reduces solution bloat, and avoids this problem of workflow ownership. If a workflow is actually updated, then you need to deal with the import, but don't make this a daily occurrence for unrelated changes.