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
Related
Our team uses Azure Dev Ops for our source control and release pipelines. The release pipelines are not included in our source control and are created through ADO UI. These can be very complex; I exported one release and it was 7500 lines of json. I would like these pipeline definitions to be in the same source control as our source code for easy maintenance and review.
I see that there are tools for exporting the pipeline definition to json and an option in the UI to create a pipeline by importing json. Is there a pattern to use automation to leverage these import/export functions and have a pipeline that is updated based on the definition in my repo?
We are currently just using the UI to update the pipelines without any additional version control or review controls. I'm expecting some functionality like GitHub Actions where the pipeline definition is contained within the repo and automation picks up the files.
If you want to version control your pipelines, I suggest that you start using the yaml pipelines that exist in Azure Devops.
These can handle both build and release pipelines. The "Releases" tab in the GUI becomes obsolete, as all pipelines (both build and release) instead show up in the "Pipelines" tab. For release pipelines, use the deployment job type, which gives you access to automatic artifact handling and environment management.
Edit: So to answer the actual question, I do not know any way to version control the GUI (classic) pipelines. My strong recommendation is to migrate to yaml pipelines.
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.
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.
I have an ASP web application that I have building in an Azure DevOps Build Pipeline. That is all fine.
I want an external organisation to be able to define their own Azure DevOps Release Pipeline to consume the build artifacts produced by our Build Pipeline. I need the access of that external organisation to be restricted with some sort of credentials (i.e. I don't want the project to be public to everyone). The external organisation should be able to deploy the latest version.
I thought this would be a relatively simple process using only Azure tools (particularly with reference to Feeds), but have tried a number of different approaches based on the documentation but all have failed. I don't want to publish to GitHub - I just want to keep everything inside Azure. I have tried using Universal Packages with Feeds, but the Release Pipeline can only pull a specific version from the feed rather than LATEST.
Does anyone have any recommended approaches I should take?
There is Latest option in the feed of your Release Pipeline:
Goal:
We have a Translation Management System project with a set of string translations, which can be exported as iOS, Android, and web formats. This can be done via its API, CLI, or manually with the UI. We need to integrate with our git-based repository, which lives in DevOps, so that when changes are made to the TMS translations, the code base is updated automatically (preferably a PR would be created with the changes).
What I Have Tried:
I am a mobile developer with little web hook experience, but it seems that they are the key to the solution. I can configure the web hook on the TMS side, but need to provide a URL with a listener. Going through the Azure DevOps service hooks settings and reading documentation extensively, I can't find any leads on a way to set up a custom listener to subscribe to another service's web hook, consume its payload, and trigger an action in DevOps.
I'm aware this may be limited by the capabilities of the TMS and DevOps, but how would this be tackled viewing it from a high level perspective? It doesn't seem like there's any built-in solution, so what would a custom solution entail? If something along the lines of what I'm looking for isn't possible, I would like to know that as well.
Thanks in advance!
So that when changes are made to the TMS translations, the code base
is updated automatically (preferably a PR would be created with the
changes).
Sorry but as I know it's not supported scenario in Azure Devops Service.
1.The service hooks option in azure devops service is that when something(event) happens in Azure Devops Service, it runs task(action) on target service. But what you want is when something happens in external service, it runs task(action) in azure devops service. For now this behavior is not supported.
2.And different service in Service Hooks has different supported actions. Let's take Jenkins service(one service hooks) as example, see step5 in trigger Jenkins: Azure Devops can trigger Jenkins build.
As for Web Hooks(another service hooks), it can't trigger actions like the code base is updated automatically. It just sends the Json representation.
So the scenario you want is not supported for now by Azure Devops Service.
In addition: Not sure about how your TMS works, but you can consider using Azure Devops Rest API to trigger actions in Azure Devops Service. (These rest apis can be used to queue build, release or do git-related actions )
When changes are made to your TMS translations, you may call corresponding Azure Devops rest api to manage git repos in Azure Devops if your TMS supports this kind of behavior.
Hope all above resolves your puzzle why your scenario is not supported by Web Hooks in Azure Devops:)
When you Authorize your GitHub repo through the devops settings, webhook will be automatically created on your repo with configurable hook events.