In Azure DevOps we only want that Release Pipelines are allowed to being manually triggered for deployments by engineers outside business hours, anything within business hours needs to be rejected unless there is a critical issue.
Is there a way to restrict deployments for Classic Release Pipeline deployments in Azure DevOps?
This is supported out of the box with YAML pipelines and environments. Environments support adding checks that run before a deployment can run there, one of which is business hours.
There is nothing equivalent for classic release pipelines.
For classic release one might try using gates to reject releases that are outside allowed time ranges. The gating logic itself implemented in an Azure function or external service.
Related
I'm wondering about the wiseness of using only Azure Boards without using Azure Repos (we use another Git service) and without Azure Pipelines (our CI/CD is defined somewhere else). Specifically, I am having trouble seeing how to define releases and mark work items as belonging to a specific release, because the doc seems to point that it would be done naturally using Azure Pipeline Builds and Releases.
I suppose we can just manually add tags to work items to specify which release they belong to, but that would mean no release dashboard/report to monitor release development.
Is it possible to use Azure Boards without handling build/deployments in Azure Pipelines without greatly reducing the usability of Azure Boards regarding release management, and how?
Option 1 - integrations
This depends on the specific service you use. For example, you can use Azure DevOps Boards and GitHub repo: https://learn.microsoft.com/en-us/azure/devops/boards/github/?view=azure-devops.
However, the number of integrations is quite limited.
Option 2 - calling DevOps API
Tag the work items by calling the Azure DevOps API in your pipelines (wherever the pipelines are running, as long as they can call an API). E.g. to update tag on a work item:
PATCH https://dev.azure.com/fabrikam/Fabrikam-Fiber-Git/_apis/wit/tags/18090594-b371-4140-99d2-fc93bcbcddec?api-version=6.0-preview.1
{
"id": "18090594-b371-4140-99d2-fc93bcbcddec",
"name": "my-first-tag",
"url": "http://dev.azure.com/fabrikam/Fabrikam-Fiber-Git/_apis/wit/tags/18090594-b371-4140-99d2-fc93bcbcddec?api-version=5.1-preview"
}
source: https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/tags/update?view=azure-devops-rest-6.0&tabs=HTTP
Context
I'm deploying multiple apps using Azure Pipelines to app dedicated namespace in a single AKS cluster.
Problem
Since my ADO Environments is assigned to a single AKS cluster, and when I add Approvals and cheks for that environment, then every Deployment that points to that environment will need approval. This is problematic when you deploy multiple apps per environment because all deployments will be guarded by this policy.
Question
Besides of creating approvals for Environment per app. Is there a way of setting up a granularity of approvals within ADO Environments?
Short Answer
"No". At the moment of writing this answer, an environment in DevOps supports only one approval -maybe it will change in the future.
Solution
There is a workaround for this problem. You can set approvals for individual service connection instead.
When you deploy an application to an individual namespace, a service connection is automatically created for that namespace. It might look like this <aks-cluster-name>-<k8s-namespace>-<long-intiger-id> e.g. my-aks-dev-we-sandbox-1654784698962. You just need to find this service connection in ADO's Project settings, click it, and then click on three dots (located in right upper corner) and choose Approvals and checks. This way, you will be able to control who should do the approvals.
How do I customize the "Pipeline" tab in Azure Devps (Image 1) so that it is renamed to "Builds" (Image 2)?
Rename “Pipelines” to “Builds” in ADO
Sorry for any inconvenience.
This behavior is by designed and is not an issue. There is no way to fix it at present.
Azure devops team working on an updated user experience to manage our pipelines. These updates make the pipelines experience modern and consistent with the direction of Azure DevOps.
Moreover, these updates bring together classic build pipelines and multi-stage YAML pipelines into a single experience. It is mobile-friendly and brings various improvements to how you manage your pipelines.
You could check the document Azure DevOps Pipelines – Multi-Stage Pipelines and YAML for Continuous Delivery for some more details.
Since Multi-Stage Pipelines and YAML for Continuous Delivery introduced, Builds are no longer just a single build as before, but also include the CD part. At this time, Builds are no longer suitable as tabs, so they are changed to Pipelines.
This is a modification of product update progress.
First i need to know why we use environments under pipelines in Azure devops
and Is there any Monthly/Yearly limitation in creating build or releases in Azure DevOps?
Anyone Please HELP !
Here is a doc about the advantages of using environments.
1.Deployment history
2.Traceability of commits and work items
3.Diagnose resource health
4.Permissions
whether there exist any limit on the number of builds that can be made
There is no limit. You can create hundreds or even thousands of pipelines for no charge. You can register any number of self-hosted agents for no charge.
But as you said, they have build time limit and parallel job limit.
You could refer this doc for more detailed information.
I'm trying to configure Azure DevOps Release pipelines for our projects, and I have a pretty clear picture of what I want to achieve, but I'm only getting almost all the way there.
Here's what I'd like:
The build pipeline for each respective project outputs, as artifacts, all the things needed to deploy that version into any environment.
The release pipeline automatically deploys to the first environment ("dev" in our case) on each successful build, including PR builds.
For each successive environment, the release must have been deployed successfully to all previous environments. In other words, in order to deploy to the second environment ("st") it must have been deployed to the first one ("dev"), and in order to deploy to the third ("at") it must have been successfully deployed to all previous (both "dev" and "st"), etc.
All environments can have specific requirements on from what branches deployable artifacts must have been built; e.g. only artifacts built from master can be deployed to "at" and "prod".
Each successive deploy to any environment after the first one is triggered manually, by someone on a list of approvers. The list of approvers differs between environments.
The only way I've found to sort-of get all of the above working at the same time, is to automatically trigger the next environment after a successful deployment, and add a pre-deployment gate with a manual approval step. This works, except the manual approval doesn't trigger the deployment per se, but rather let an already triggered deployment start executing. This means that any release that's not approved for lifting into the next environment, is left hanging until manually dismissed.
I can avoid that by having a manual trigger instead of automatic, but then I can't enforce the flow from one environment to the next (it's e.g. possible to deploy to "prod" without waiting for successful deployments to the previous stages).
Is there any way to configure Azure DevOps Release Pipelines to do all of the things I've outlined above at once?
I think you are correct, you can only achieve that by setting automatic releases after successful release with approval gates. I dont see any other options with currect Azure DevOps capabilities.
Manual with approval gates doesnt check previous environments were successfully deployed to, unfortunately.
I hope this provides some clarity after the fact. Have you looked at YAML Pipelines In this you can specify the conditions on each stage
The stages can then have approvals on them as well.