1
votes

I have a build pipeline in Azure Devops, and have set it to trigger whenever 'develop' branch is updated. In my release pipeline I use the same build artifact in Staging and QA environments, using Pipeline variables to set my configs in each environment.

How does it work in Production releases though where the timing is different? I plan to have the release in manual trigger, but what artifact do I use? I only have one build which depends on develop branch. Dev team always creates a release branch, does that mean I create a separate build for the release branch? I understand that the mantra for DevOps is "build once, deploy to many environments", in practice how do you do that when you have a separate branch for production releases?

1
As you've noted, you shouldn't have a different artifact for a different environment. The branching model isn't a good fit for CI/CD, instead try using tags to trigger promotion to other environments.jonrsharpe

1 Answers

1
votes

Creating a new artifact introduces the risk that an unexpected change is introduced and an untested version of your application goes to production.

Microsoft's documentation on branching strategy is well worth a read, the main point is to keep things as simple as possible. You therefore may even consider removing the production branch from your workflow.

I can see some merits of keeping a production branch, it provides an instant visual representation of what's in production from your git client and therefore easy to pick a branching point for hotfixes for example. If you'd like to keep your production branch I would suggest a change in philosophy, rather than manually merging to the branch when planning a deployment to production, merge to the production branch after a deployment to production, automatically if possible.

If using multi-stage yaml pipelines you could achieve this with a task in your production deployment stage, either merging to the production branch or alternatively tagging master, for example:

- script: |
      git --version
      git -c http.extraheader="AUTHORIZATION: bearer $(system.accesstoken)" tag $(build.buildNumber)
      git -c http.extraheader="AUTHORIZATION: bearer $(system.accesstoken)" push origin $(build.buildNumber)
    displayName: Git Tag

There are some permission changes to carry out if you want your pipeline to be able to perform git commands.