CHUVASH.eu

CHunky Universe of Vigourous Astonishing SHarepoint :)

Tag Archives: pipeline

Git Merge develop to main in an Azure DevOps Release

This post is a techy one. It’s about running git commands in Azure DevOps Releases in order to finalize a deployment job to production.

Let me first describe our scenario:

We use Azure DevOps for code and for deployment. Our branch strategy a simplified Gitflow model, where all the current work is merged to the “develop” branch. The code from the “develop” branch is then built and released to staging environments and production. After a release to Production and regression tests the develop branch needs to be merged into the “main” branch (or “master”). So simply put, the git merge into main is what we mean by finalizing a production release.

The “Finalize” stage in a release definition consists of one step: a bash script. But before you can run git commands you need to configure a couple things. Let’s go through them:

Step 1: Permissions

Step 2. New Stage

Next, create a new stage, call it “Finalize Production Deployment” (or other name of your choice). On the Build Agent step, enable “Allow scripts to access the OAuth token”

Add a step: Bash, call it “Git – merge changes to main”. Paste this git code.

git config –global user.email "azuredevops@microsoft.com"
git config –global user.name "Azure DevOps"
REPO="$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_git/$(Build.Repository.Name)"
EXTRAHEADER="Authorization: Bearer $(System.AccessToken)"
git -c http.extraheader="$EXTRAHEADER" clone $REPO
cd $(Build.Repository.Name)
MAINBRANCHNAME=$(git rev-parse –abbrev-ref HEAD)
git config http.$REPO.extraHeader "$EXTRAHEADER"
echo — Merge $(Build.SourceBranchName) to $MAINBRANCHNAME
git fetch origin $(Build.SourceBranchName) –prune
git merge origin/$(Build.SourceBranchName) -m "merge $(Build.SourceBranchName) to $MAINBRANCHNAME" –no-ff
TAGNAME=$(Release.ReleaseName)
echo — Create tag named $TAGNAME
git tag -a -m "$(Build.SourceBranchName) installed to production" $TAGNAME
git push origin $MAINBRANCHNAME
git push origin –tags

That’s it, the code is pretty universal. Let me know if something does not work.

You can stop reading unless you want more details 🙂

More details

A neat list of all available variables

When I started working I found this very useful: The built-in “Initialize job”. Click on that:

There you can find all the built-in and your variables in a nice list. Pretty useful for building a bash script:

Here is how I construct the repo url, neat, isn’t it?

Pipelines vs. Releases

If you run this code in a classic Release Definition, you won’t get the repo. You need to clone it first. Why Release and a Pipeline. Well, due to reasoning described in my other blog post, we still run Releases: Azure Key Vault vs. Pipeline Variables. But Pipelines should work, too.

Dry-run

I found it useful while mickle-mackling with the finalize step, disable all the other steps and commenting out the actual push to origin. That way I could run it fast and focus on the steps I needed to fix first.

Authorization

Before you can configure the authorization header, you need to clone it first and cd into that directory. In order to clone it you need to have the extraheader. Tough luck? No, not at all, you just need to add in two places, when cloning and and then in the git repository for all the following commands:

User Identity

Using git config you can define any user identity. Use something that makes sense and is easy to recognize.

main vs. master

If your repos main branches are both main and master, no worries, you don’t need to guess or create a variable. All you need to do is to check the current branch after you have cloned it. NB: it’s different in case you use a Pipeline.

Further reading and links

Azure Key Vault vs. Pipeline Variables

Using Azure Key Vault in a Pipeline is cool, but it is less secure.

The Key Vault setup

Have you tried the Key Vault Step in an Azure DevOps Pipeline? If you haven’t, please follow these awesome guides:

The steps described in these guides are easy, but that effort made me think about the first pair of pros and cons.

A pipeline variable is faster to configure

A variable in a pipeline takes zero time to set up. Also, A secret variable remains as a secret, since no one can read it in plain text. To configure the Key Vault way of getting secrets requires admin time. Unless you have Admin rights in your Azure Active Directory and your Azure Subscription, you might need to request and argument for one or more of the following:

  • A service principal (an App registration) with a secret.
  • An Azure Key Vault (and maybe a resource group) with an Access Policy for the service principal
  • A service connection in your Azure DevOps Project

Of course, most of it is one-time-job. But still, in many organizations it will require good preparation. The pros for an Azure Key Vault secrets in a pipeline is that

  • Admins can manage the secrets centrally from Azure
  • It is easier to audit the Key Vault Access.
  • Set it up once and let Azure DevOps people use it and re-use it in many pipelines, but still you need to set up a new Service Connection in every Azure DevOps Project

The fact that it is easier to reuse lets me think of my second pair of pros and cons.

A pipeline secret variable is more secure

Let’s say you need a password to a service account that will upload something important, e.g. an account that will upload a new SPFx package to the SharePoint App Catalog.

Doing it the pipeline variable way means that it remains as a secret on that particular release pipeline. Only release administrators of that project can alter the pipeline steps. No one else.

A tip for productivity: Use Group Variables to share the secrets within a project in Azure DevOps.

Doing it the Key Vault way, means that you must watch out on every part of that chain:

  • Users who have access to the Key Vault in Azure.
  • Service Principal that can read the secrets through access policy. Who has access to the secret?
  • Service Connection in an Azure DevOps Project. Who can use this Service Connection – to add and modify release pipelines? By default, all Release Administrators can do that. To do it more secure, you need to limit the count of Release Administrators. But it means less flexibility in a team and more admin effort for the allowed Release Administrators.

Also, the service principal used for getting the secrets and in the service connection, should not be reused across projects in Azure DevOps. Dedicated Service Principals will make it more secure because misuse can be more easily discovered and stopped – and thats on a project level, not for all service connections.

Summary

In flat small organizations, using a Key Vault for using secrets in Azure DevOps Pipelines is great, it saves you time. But it is less secure, and requires time and effort for an appropriate security.

Daniel Chronlund Cloud Tech Blog

News, tips and thoughts for Microsoft cloud fans

Вула Чăвашла

VulaCV - Чăвашла вулаттаракан сайт

Discovering SharePoint

And going crazy doing it

Bram de Jager - Architect, Speaker, Author

Microsoft 365, SharePoint and Azure

SharePoint Dragons

Nikander & Margriet on SharePoint

Mai Omar Desouki

PFE @ Microsoft

Cameron Dwyer

Office 365, SharePoint, Azure, OnePlace Solutions & Life's Other Little Wonders

paul.tavares

Me and My doings!

Share SharePoint Points !

By Mohit Vashishtha

Jimmy Janlén "Den Scrummande Konsulten"

Erfarenheter, synpunkter och raljerande om Scrum från Jimmy Janlén

Aryan Nava

DevOps, Cloud and Blockchain Consultant

SPJoel

SharePoint for everyone

SharePointRyan

Ryan Dennis is a SharePoint Solution Architect with a passion for SharePoint and PowerShell

SharePoint 2020

The Vision for a Future of Clarity

Aharoni in Unicode

Treacle tarts for great justice

... And All That JS

JavaScript, Web Apps and SharePoint

blksthl

Mostly what I know and share about...