Use Azure DevOps Release Gates to check for website availability and automate stage flows

Modern deployment patterns rely on automation, everywhere. A common request in this space is to automatically verify if a web resource is up and running before proceeding with the deployment.

Instead of having a script that runs within a Stage, why not leveraging Release Gates? At the end of the day they are designed with automation in mind.

To make this example generic enough, I created an Azure Function (code here) based off the HttpTrigger sample that checks for a URL availability. If the code is not 4xx or 5xx it returns a simple JSON output:

It is not the coolest or cleanest code, but it works 😁 Now, once this Function is up and running, we can leverage it within a Release Gate in a Pre-deployment condition:

Set the Completion event to ApiResponse, and check the value of the output as a Success criteria. If IsUp is true, then the website is up and running:










You can actually make it even smarter by checking for both IsUp and the code:

This would be enough to have the check in place, and automate the gatekeeping of your stage flow.

Did you know? Changing default and comparison branch in Git from Azure DevOps

This was one of those things you never realise until you actually look at it:





Have you ever thought that many people just leave that at the default setting (both Default and Compare on master) without too much thought?

Well, it is easy to change for both.

Compare:

Right click on any other branch, and select Set as compare branch.





















Default:

From the Repository settings, right click on any other branch and select Set as default branch.










Now, you might wonder why you might want to change these settings.

The Compare branch is a user setting - you might want to use it to set your development branch as a baseline branch to see how far master is ahead or behind compared to develop, for example.

On the other hand, the Default branch is for Pull Requests - it identifies


the default branch for merging code into when creating a new Pull Request.

A quick reflection on git reset

This is fairly quick, but I haven't realised how important it is up to now - a friend made up such a mess of his repository adding and changing files before committing that he wanted to delete the folder and start from scratch.

Is it worth it? Not really, you can move around Git's history with this command:

git reset --hard <SHA of the target commit>

Why do I say it is an important thing to keep in mind? Think of it this way: if the user comes from TFVC, this is equivalent to a local Undo All and to Get Specific Version and Get Latest Version (with HEAD instead of the SHA) commands.