After setting up the app registration and role assignment, now it is time to look into obtaining some storage.

The Let’s Encrypt application will run as a Web Job, and as a web job it needs a storage account to store the required information. So head over to the Storage accounts menu and click on the + Create button.

The storage account can be set with the cheapest configuration since the job will just run in the background without affecting the performance of your web site visitors. It can be set to standard performance, locally redundant storage, and hot access tier.

Once filled in, click on the Review + create button, and the review screen will come up. Go ahead and click on the Create button.

Wait until the new storage account is deployed, then hop over to the Access keys section and make a note of the storage account connection string.

We will then use all of the connection settings that we have collected so far in the last step. Just be patient and keep them safe.

In the previous post, we have configured an app registration to give us the means to identify the Let’s Encrypt app during automatic jobs. Now we will give access to the app so that it can manage the resources inside the web application for us.

Go to the resource group that contains the web app where the SSL certificate will be installed. Click on the Access control (IAM) menu:

On the right-hand side of the page, you should be able to see the role assignment widget. Click on the Add button inside it:

And in the role assignment window, add the Let’s Encrypt app registration as a contributor to the resource group as shown below. To find the correct app registration, use the search functionality inside the Select field. When searching for the app name, the search results will be shown below the Select field. Once clicked in the result, the app registration will then also be shown in the Selected members list.

Click the save button to finalise granting the rights to the application. Now technically, the Let’s Encrypt app has the necessary rights to modify our resources inside the selected group.

Before we conclude this step, since we are already inside the Resource group page, take note of the subscription ID as indicated above. We will also need this later, together with the client secret and client ID which we had copied during the first step. Then in the next step, we will set up a storage account.

As reported in Microsoft’s Identity Platform Blog, the user experience for Azure App Registrations has changed, and the choice to use the legacy editor will not be available after March 1st. The end result is that some things in Azure Active Directory(AAD) have been moved around. So I decided that it’s time to do another series of blog posts to describe how to configure your Azure Web App with a free Let’s Encrypt certificate because AAD is an essential part of the process.

In this first post, I will go through the process of creating an App Registration inside Azure Active Directory. By the end of the series, we will have a Let’s Encrypt extension running beside our web app. Since the generated certificates will expire every three months, this extension will renew SSL certificates automatically for us.

We need a way to give the Let's Encrypt extension access to our Azure resource group so that it can manage the resources automatically for us. An Azure App Registration will enable us to create an authentication account that the extension will use to log into our Azure Active Directory.

So without further ado, let’s start our journey to make our site secure. From the Azure Portal dashboard, click on Azure Active Directory:

Then further down look for the App registrations menu, and click the + New registration button:

This will open a new window to register the app. Here we need to provide any name which we will use to identify the application (I opted to name it Let's Encrypt). The supported account type should be ‘Accounts in this organizational directory only (Default Directory only - Single tenant)’ and the redirect URI filled in with the web app’s URL.

Click the Register button and wait for the app registration to be created.

Now we need to create the actual login. Once back to the app registrations page, click on Certificates & secrets, and then + New client secret:

Give it a descriptive name and the desired expiry time.

After the secret store is created, its value will be displayed. Make sure to copy the value by hovering on the field and clicking on the copy icon as shown below. For security reasons, this value will be hidden when you try to view it in a future session (otherwise it wouldn't be a secret anymore). We will then use this secret once when configuring the Let’s Encrypt extension during the last step and dispose of the information immediately after.

Back inside the app registration window, we also need to make a note of the application id for later.

In the second step, we will give the Let's Encrypt account that we just created access to our Azure resources.

In this tutorial, we will see how to create a YAML build pipeline from an existing pipeline built with the classic editor. Creating a YAML build pipeline from scratch may be intimidating for novice users, but if you have an existing one in the classic editor, switching over is easier. You don’t need to be a YAML guru.

Once logged in Azure DevOps, head over to your existing pipeline. This can be accessed from the build pipelines section as shown below.

In my case, I have a pipeline to build this website’s code. Click on the job name, then we will have the option to view it in YAML form.

This will open a popup window showing the existing job in the YAML format. Click the ‘Copy to clipboard’ button. We will need to paste this code into a new file soon.

We now need to copy the code and store it inside a text file in our repository. This can be done directly from the Azure DevOps portal. From your repository, create a new branch and then a new file right afterwards. Put this new file in the Pipeline folder, so that it will not be stored directly beside your code.

Paste the copied YAML into the new file.

Before you commit, it is important to check if you need to specify the image name of the build agent. When you run your build on an Azure-hosted agent, you need to add the vmImage parameter, as I did with windows-2019 below. If you have a private agent instead, just the name of the agent is enough.

Now we can go back to the build pipelines page and click on the button to create a new pipeline.

On the next step, click on the repository name.

And on the Configure step, we will select an ‘Existing Azure Pipelines YAML file’.

Then choose the filename that we just saved a few steps back.

On the final review step, we can now add the required variables. The generated YAML file contains comments about the variables that the build expects so that it can run successfully.

Click on the Variables button so that we can add them and then just add each one individually. We can look the existing classic pipeline if we need to verify the values of the variables.

We can now click the Run button to test the pipeline.

Once the job finishes, we can check the outcome.

So now we now that the build has run successfully, we can set it to be triggered automatically whenever any code is committed into the master branch. Go back to edit the YAML file and add the trigger as shown here.

And there’s no better way to test it than creating a pull request on the YAML file so that it can be integrated into master and automatically trigger the build. Create a new pull request and choose to merge the new branch into master.

If this triggers the build, then we have confirmed that we have really managed to set up everything successfully.

Last time we left off by triggering the NuKeeper build pipeline that we had just created. Today, we will edit the pipeline configuration with a schedule to run regularly and so we can get on with the rest our work safe in the knowledge that automation is taking care of the updates.

To start, click on the pipelines icon and choose Edit from the context menu of the existing pipeline.

Choose the triggers tab and then click on the Add button to create the schedule. Enter the day of the week and the time when you wish the build to run. Make sure to uncheck the option to ‘Only schedule builds if the source or pipeline has changed’ because otherwise, NuKeeper will only check for updates whenever you also change the source code.

Once happy with the setup, save your changes.

And enter a comment which describes the modification.

You’re all set now. NuKeeper will check for nuget package updates depending on the schedule. However, we can go one step further. Let’s modify the branch policy so that reviewers are added automatically when NuKeeper creates a pull request. Click on the icons as shown below:

And add the code reviewers as required. You can include individual users or groups of users. In the latter case, any group member will be able to approve the update. When a pull request is created, all the reviewers listed here will receive a notification. We can also specify a file path, since we know that NuKeeper will only modify the csproj files.

Lastly, we can also talk about configuration. The full details of the configuration options are described on the NuKeeper site, but let’s pick up a few of the most popular. These configuration options can be added to your pipeline as arguments in the NuKeeper task.

By default, the only argument is -m 3, which means that the task will update up to three packages at any one time. We can also set the age of the packages that we want to update (with the -a argument), which will be seven days if not specified. In this way, we will wait for the package to be tried and tested in the wild for any problems before we automatically attempt to add it into our solution. However, this value can also be specified in hours or disabled completely so any new package will be picked up immediately.

Another popular argument is the c argument (which stands for change). Here we can specify the level of the version changes we want NuKeeper to include; patch, minor, or major. Some major changes can potentially include breaking changes and some teams may choose to apply these updates manually, or otherwise plan for them.

If indeed we know that there are packages with breaking changes, we can then use the exclude argument (e) so that NuKeeper will leave them alone. The consolidate argument (n) will combine all the updates into a single pull request, otherwise by default, the task will create a pull request for each package. The useprerelease argument (no shortcut for this one) will specify if we want to include alpha or beta package releases or not, and the nice thing is that by default it is set to update to a newer pre-release version only if you are already using a pre-release version of a package. I will let you explore the rest of the options, but by using the above you will already gain a big advantage with a lot of flexibility.