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:
Related
we are using Azure Pipelines to build and deploy various projects. We are using Enterprise Github service connection as our git repository source which we are using as part of the build pipelines that are running on on-prem AzureDevops build agent. We are then using on-prem hosted DevOps agents to deploy the service on our on-prem servers.
If we trigger a build we then receive an email notification about all the new commits which are included in the build. Is the same information (what commits are part of the build) included somewhere in the Azure DevOps UI? I was not able to find it and it's really difficult to then determine what I'm actually deploying our various environments as I'm not always the one who triggers each build.
Thanks
I am new to Azure Build Pipelines.
I've seen many posts and videos about how to create a simple pipeline using the Azure Devops UI (no YAML), with one Web Application project, but I have 2 applications, an asp.net Core Web Application (WebUI) and an asp.net Core Web API. For some reason, the artifact published from my build pipeline is only containing the WEBUI. I would expect that both projects be published as Artifacts.
Any suggestion on what I should do to have both artifacts as results from my build pipeline?
Thanks
I actually found my issue. I had a checkbox in the Publish Task called "Publish Web projects".
Once I unchecked it, both my artifacts were created.
Traditionally we have to deliver our applications on the test and pre-production platforms one by one (usually by hand using setups). Applications like the front end javascript SPA UI are linked to backend services and their delivery sometimes goes together.
Each service and each application has its own git repository. (we are using on premise TFS 2018 for now )
Then when it is necessary to go into production, we deliver all of the front end services and applications at once that have been validated at once.
We would like to automate our process but we don't know if Azure Devops is suitable.
From what I understand with Azure Devops, we can make an independent artifact for each microservice and each front end application. We can also deliver them independently.
It seems to me that Azure Devops by default allows you to manage the delivery cycle for a particular microservice but not for an assembly making up a complete system, right?
But is it possible to deliver a set of projects each with a particular version? For that, must all of our projects be in the same solution or the same git repository?
Yes, you can use multiple artifacts from different sources (build artifacts, repositories, package feeds, github, docker hub, Azure Container Registry, ++) within a single pipeline or release definition. That's true for both the classic release definitions and the modern multi-stage pipeline implementation.
For example you can define a pipeline or release definition that consumes a front-end web app from a build artifact sourced from RepoA, a back-end service artifact consumed from a container registry originally from RepoB, and say a script library in the form of a Git artifact from RepoC. From there you could deploy each of those artifacts together, or in parallel stages, in sequence, partially, with approvals, conditionally, etc, all from the same pipeline.
The full configuration as code YAML multi-stage pipelines are still in preview, so there are some workflow orchestrations that are a little tougher to implement. But there is enough feature parity with the classic release definitions that I would default to using multi-stage for any net new needs.
I've recently been working on switching from On premise TFS to Azure DevOps, and trying to learn more about the different pipelines and I think I may have had my Build pipeline do too much.
Currently I have my Build Pipeline do
Get Source code from Repo
Run database scripts/deploy dacpacs
Copy files over to virtual machines that have web application set up already
Run unit/integration tests
Publish the test results
I repeat these steps closely multiple times, one for develop branch, one for current and previous release branch.
But if I want to take advantage of the Releases and Deployments areas what would that really get me?
It looks like it would be easier to say yes this code did make it out to this dev/beta environment.
I'm working with ColdFusion code that includes some .NET webservices within the repo, would I have to make an artifact that zips up the repo and then deploys it, or is there a better way to take advantage of the release pipeline?
It's not necessary to make an artifact that zips up the repo and then deploys it. There are several types of tools you might use in your application lifecycle process to produce or store artifacts. For example, you might use version control systems such as Git or TFVC to store your artifacts. You can configure Azure Pipelines to deploy artifacts from multiple sources. Check the following link for more details:
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops#sources
I'm looking for a pre-made option to take 2 builds, and compare the work items or PRs completed between them. i know there are REST API options in order to find out this information ( https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/get%20work%20items%20between%20builds?view=azure-devops-rest-5.0 ) , but i would rather not build my own app for this if one already exists. Is there something built into azure devops that shows this information, preferably in an exportable format? Is there possibly an existing devops extension in the store? Any searching i do just brings up the REST API call and nothing else unfortunately.
They seem to have changed it in Azure DevOps. We are using Azure DevOps Server (on-prem). In it, the old TFS-like work items comparison between the builds is possible when you actually deploy (execute a release) in a stage:
(in the screenshot below the right popup pane is showing the work item "diff" between the build currently deployed in TEST and the one which is about to be deployed now)
If you are open to it being generated at build time, you could look at using the Generate Release Notes Build Task from the marketplace.