Menu
I am using VSTS build to run a CI build. This build definition is the same for all my git branches (master, develop, features, etc).
I am now trying to implement a deployment pipeline using VSTS release management. I plan to have two distinct release definitions. One for feature branches and one for the more important branches like develop and master. The release definition for feature branches would be more lightweight.
I think this is pretty basic and usual. In fact, that's pretty much what is documented in Microsoft's typical use case for Release Management.
For both of these pipelines, I want to configure them to start automatically using the 'Continuous Deployment' trigger. When I select this trigger, I must select an artifact source.
Unfortunately, an artifact source takes all artifacts (regardless of the branch) coming from a given build definition (my CI build). Since I use the same CI build definition for all my branches, it looks like I can't configure my two release pipelines in 'Continuous Deployment' and still use the same build definition as an artifact source.
Anybody knows how to share the same build definition for multiple release definitions but only start a release for a specific branch? Anybody knows of a way to filter by branch when we define an artifact source?
422
Publish Artifacts is not supported in release pipelines. It is only supported in build pipelines, yaml pipelines, and multi-stage pipelines. You can publish your Artifacts at any stage of your pipeline using YAML or the classic editor.
Select trigger: Set the trigger that will start the deployment to this stage automatically. Select "Release" to deploy to the stage every time a new release is created. Use the "Stage" option to deploy after deployments to selected stages are successful. To allow only manual deployments, select "Manual".
A release is a collection of artifacts. An artifact is a deployable component of your application. Release Management can deploy artifacts that are produced by a wide range of artifact sources, and stored in different types of artifact repositories.
To trigger a pipeline upon the completion of another pipeline, configure a pipeline resource trigger. The following example configures a pipeline resource trigger so that a pipeline named app-ci runs after any run of the security-lib-ci pipeline completes. This example has the following two pipelines.
If you wish to map an artifact source to trigger a specific stage, the recommended way is to decompose the release pipeline into multiple release pipelines. You have your application build (such as TFS, Azure Pipelines, TeamCity, Jenkins) published as a package to Azure Artifacts and you want to consume the artifact in a release.
A single release pipeline can be linked to multiple artifact sources, of which one is the primary source. In this case, when you create a release, you specify individual versions for each of these sources.
A number of artifact variables are supported for external TFS sources. Azure Pipelines cannot show work items or commits for external TFS sources. By default, External TFS artifacts are downloaded to the agent. You can configure an option in the stage to skip the download of artifacts.
Build branch filters allow you to trigger a release only for a build that is from one of the branches selected here. You also have the option to specify branch tags. If you do so, a release will be triggered only if a new build tagged with the keywords specified here, is available.
98
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
