Creating a release

Modified on Mon, 20 May 2024 at 03:31 PM

This short guide explains how to release a new version of Mail & Deploy.

Locate & Tag Release Commit

Find the git commit which will be used to create the release. Typically this will be a recent commit - usually the latest - on the main branch here:

You will likely see something like this:

Click the three dots ... at the end of the row containing the commit you wish to release:

Enter the release name for both the Name and Description fields. Typically this will be of the form e.g.:




But it's also fine to create a release for example for a certain customer to try out a fix to an issue. So for example you could incorporate the ID of a fresh desk ticket:


Or a descriptive name:


In this example we use 3.5.0:

Branch Releases

Although generally new releases are made from main, it can happen that for example we re already working on the next version on main but need to patch a recent version. This happened with 3.5.0 where we had already started using the 3.5.0 version on the main branch but needed to release patches for 3.4.X.

The way this is done is to create a branch for 3.4.X updates, in this case we created the branch named:

Which can be seen here:

With this, any fixes to 3.4 are then made via a PR merging into the releases/3.4.8-and-above branch (and also applying the same change to the main branch so that 3.5.0 gets it too if needed) and the tags from the above step are created on that branch.

Publish Release

Once you have done this go to the build and release pipeline here:

And click "Run pipeline":

Locate the tag you created above and then make sure the following options are checked (note here we use another tag to illustrate as 3.5.0 is not yet created:

Now click "Run":

You should see a job start which you can navigate to and watch running. It may take around 15 minutes to run but when it is finished you should see the steps successfully run:

And you should see here there are artifacts published:

The above are not directly accessible by end users but if you selected the options above the relevant files with have been copied to a public s3 bucket. The paths to these files can be found in the 'release-notes' file:

Related Tasks


Create a page for the new version which captures the changes since the last version. For example:

Looks like this:

You can use the git history in Azure devops to know exactly what has changed since the last release, for example here we can see what has changed between 3.4.8 and 3.4.9. This can be used to generate the help content (although it might need improved wording).

Note though that there are likely commits in here which should not be reflected in the release notes, for example tests, readme updates, refactoring which does not change product behaviour, certain saas changes for example related to metrics.

Releases Page

Update the 'Release 3.4 and higher' post in:

Doesn't seem to be a permalink to this but it looks something like this:

Generally it is just a case of adding a new row to the main table. But note when this is changed and saved anybody subscribed to it will get an alert so try to only do this once when everything else is in place.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article