It has been a while since I have felt the will to write something down. In the meantime I have found some time to play a bit with the Power Platform, so I want to show you how to get started with a developer account so that you can take advantage of the platform as well. Everyone can join in building business apps!

If you are unfamiliar with Microsoft's Power Platform, you can view it as an introductory software development tool for budding software developers. It allows you to quickly build applications to get your digital side of your business rolling. You will still fall into the same pitfalls that beginners of any other software language fall into, but the barrier for entry is much lower. Everything runs on the cloud over a subscription, so you don't need to learn how to install development tools or database servers (if you don't want to).

To start learning about building business applications, you can create a developer account right now for free. The journey starts from https://developer.microsoft.com/en-us/microsoft-365/dev-program. Once there, click on the Join Now button and you will be asked to log in or to create a new account.

In the new account window, you can use an existing email address or even create a new @outlook.com address. Once signed in, you will be greeted by the Microsoft Developer welcome screen.

We now need to proceed to the Microsoft 365 Developer Program registration. Click the Microsoft 365 tile and on the next page click on 'Learn More' and then 'Join Now'.

If you have created a new account and have not set up your personal details yet, you will get a warning and then redirected to another page to fill them in.

Just enter your first and last name as shown in the example below and you are good to go. Note that it may take some time before your details are successfully picked up by the registration page.

Proceed through the next steps by entering your company information, the reason you are joining, and the platforms you will be working with. These are used to keep you updated with product and learning suggestions for your areas of interest.

You are now officially a developer, and this entitles you to a free E5 subscription. With this you will be able to use the suite of Microsoft applications, which you can combine with your processes inside the Power Platform.

You only need to choose an account name and a tenant name. This will generate an account in the form of account@tenant.onmicrosoft.com. You can use your name as the account name and the company name as the tenant. Finally, don't forget to choose a strong password.

In less than a minute, the subscription will be activated for 92 days. You can then perpetually keep renewing the free subscription for a further 92 days after the original 92 days have passed.

The final step we need to complete before we can start building apps is to set up a Power Apps Community Plan. To do this head to https://powerapps.microsoft.com/en-us/communityplan/ and then click the Get Started Free button.

Use the same account that you created for the E5 subscription in the previous step and we will be all set. We now have developer accounts for building apps and processes on the Power Platform. And it can also interact with the suite of Microsoft 365 apps.

If you've been following this blog, you will remember that I covered how to manage your secrets during development a few weeks back. And it all started with keeping your secrets out of source control as the first precaution.

Now we also want to have a safer process when hosting web applications on Azure, and thus avoid leaking secrets. So let's say I have a typical scenario as shown in the image below where I need to set an important secret.

Storing secrets in the App Settings is already a step in the right direction, but the above password is available to any person in the team who has access to the app configuration. And with bigger teams, it already starts to sound like a bad idea. Which it absolutely is.

The first suggestion you will be given in this case is to move the secret password into an Azure keyvault. And this is where most developers start scratching their head, because to access the keyvault you need a password. And if you have the keyvault password, you can access the hidden secrets within. So we would not have solved the problem in this way, only just made it more annoying.

The answer lies in using managed identities. Let's try it!

Create a Key Vault inside your favourite resource group by clicking the +Add button.

Search for and choose the Key Vault option.

Then click the Create button.

Next, make sure to give your keyvault a nice name that can help you associate the keyvault with its purpose in the future. The region should be in the same region as the application that is going to access the keyvault. What with latency and all. Finally, the pricing tier gives you an option to store the secrets inside the keyvault using Hardware Security Modules. It's a tradeoff between additional peace of mind and costs.

Feel free to take a look at the other settings, but for this tutorial you can jump to Review + create, and then confirm by clicking the Create button. You may paricularly want to take a look at the extra security given by the networking option, but that's something for another post.

While the vault is being created, let's go back to the web application settings. Just below the app configuration menu, we have the Identity menu. We want to create a System Assigned Managed Identity, so flip the switch to the on position and save.

You will get a prompt to confirm this. So what are we really doing here? In simple terms, we are creating an identity for the web application. An identity is the Active Directory account that the web app will use to log into the keyvault. And the best part is, the Azure platform will handle the account for us. No one will ever know the login details for the web app to access the key vault. It will just work.

So let's do this and click Yes. The keyvault deployment should be ready by now, so let's go there and click on the access policies menu.

You should now have a + Add Access Policy button. Go on, click it!

This is where need to give the app acess to get secrets from the keyvault.

When it comes to selecting the principal, click on the link that says 'None selected', then search for and select the identity we have just created in the previous step. When searching you can use the app name, or the managed identity's object id.

That's it. All we need is those two values and we are good to go.

Once added, we should be able to confirm it looks good right away.

We can move the secret password to the keyvault now. Click on the Secrets menu and + Generate/import.

Then enter the secret.

Once created, you can click on the secret and copy the secret identifier in the details page by clicking on the copy button.

Back in the application settings, replace the previous value with @Microsoft.KeyVault(SecretUri=<secret identifier>). Use the secret identifier you just copied instead of <secret identifier>.

That's it. Once you save your changes, the web app will be restarted. If everything was successful you should see a green checkmark next to the app setting.

If there are any issues, check the error to learn what went wrong. It's very easy to forget saving at any particular point in the process, so if this is the case go back and check that everything is there.

Once the app setting is accepted, also make sure that you check whichever secret you moved into the keyvault is still working as expected or your visitors will be disappointed.

I was recently asked to start sending an email at the end of every sprint, listing the details of our official stable builds. The problem is that I don’t like writing emails, so I wrote a release pipeline PowerShell script instead.

I will show you how to get all the relevant information for the release summary, but will not go into the details of sending the email itself here. I’ll leave that as an exercise for you, perhaps you can try to use SendGrid for that and tell me how it goes.

Our starting point is that I have two products, each of them with an existing build pipeline. For the purpose of this tutorial, I just created two blank builds for two fictional apps. However, I want you to notice the different version number for each app in the screenshot below.

Those version numbers are the ones we need to publish to our stakeholders at the end of each sprint cycle. Let’s head over to the release pipelines now and click on the ‘new pipeline’ button.

Start with an empty job:

Which should produce the following result:

Now we need to add the two artifacts that are produced by the builds we saw earlier. Click the +Add button:

Select any one of them, and more configuration options will be shown.

Most of the time you would want to always use the latest build, but you have various options for selecting an earlier or a specific version. Note that you will be prompted to confirm the build version anyway when you actually run the release pipeline at the end of this tutorial. For the source alias, I chose a simpler name like BlueYonder, since long names and spaces have caused issues for me in the past.

We can now click the Add button, and proceed to do the same procedure for the other app. Once ready, we should end up with two artifacts.

Add this point, just save and create a release. I know we are not ready yet, but trust me just go ahead and create it.

We can now see that the release is created.

Soon it will be queued and run.

Click on the release link as shown above, and then on the next screen, click the Logs button to view the logs. Some mouse-hovering ninja tricks are required to see the Logs button.

On the next page, select the job initialisation log:

This will show us, amongst other things, all the environment variables that were initialised for this job. Here I can find the variables that are holding the build information that I need. Look, there’s even my name down there. Isn’t that lovely! I can now sign the summary with the name of the person who triggered this release. So make a note of all the variables you need, or just keep it in another tab for further reference.

We are now ready for the next step and add some code. Go back to the release configuration page and click on the link that says ‘1 job, 0 task’. This will open the Tasks configuration window.

Note that here I already changed the stage name, which means I am at peace with my inner self and can proceed to add the agent job with the click of the + button. This will allow me to select the job type from the panel on the right.

Type ‘powershell’ to filter the results, and click on the Add button. You actually need to hover on the PowerShell job for the button to magically appear.

Configure the script as an inline script. Then enter the code shown below. Make sure to change <Your_Azure_DevOps_Organisation> and <Your_Azure_DevOps_Project> with your own organisation and project ids accordingly.

Write-Host "Hi,"
Write-Host "Today we are pleased to announce the latest stable release of our awesome apps!"
Write-Host "WingTip Toys Collectors App v$(Release.Artifacts.Wingtiptoys.BuildNumber): https://dev.azure.com/<Your_Azure_DevOps_Organisation>/<Your_Azure_DevOps_Project>/_build/results?buildId=$(Release.Artifacts.Wingtiptoys.BuildId)&view=artifacts&type=publishedArtifacts."
Write-Host "Blue Yonder Flight App v$(Release.Artifacts.BlueYonder.BuildNumber): https://dev.azure.com/<Your_Azure_DevOps_Organisation>/<Your_Azure_DevOps_Project>/_build/results?buildId=$(Release.Artifacts.BlueYonder.BuildId)&view=artifacts&type=publishedArtifacts."
Write-Host "Best regards,"
Write-Host "$(Release.RequestedFor)"

Save and create another release, and this time we should see the summary with all the juicy details.

So here we are. I just showed you how we can obtain all the required information, which means we can go to the next step and send it as an email. However, this post is already quite long, and as I said at the beginning will leave it as an exercise for you.

Header image adapted from GalleryBritto / CC BY-SA (https://creativecommons.org/licenses/by-sa/4.0)

When setting up a new .NET Core project, one must be careful about where to store secret information, such as passwords and connection strings with sensitive data. Nowadays, it is very easy to start a new project and share its source code with the whole world, and likewise, it is very easy to share your secret information if you are not careful. It is of utmost importance that secrets are kept that way.

Azure makes it easy to store secrets on production websites and keeping them safe, but it’s mostly in their own development environment where most beginners struggle. If the software that you are building needs a password to connect to a database, the tooling will lead you down the path to storing it directly in the application settings. But then it would end up in the source code. Storing secrets inside source code has to be avoided at all costs!

The next best thing, and equally cheap at the price of free is to store your secrets in your own personal folder and retrieve them from there when needed. Luckily Visual Studio can do this out of the box. One important fact to be aware of before we continue is that this method does not encrypt the secret data in any way. It just stores it in your own personal folder, which is definitely safer than storing it in source code online but can still be compromised by someone who has access to your computer.

Start by right-clicking the project name inside the Solution Explorer window. The context menu will have an option to Manage User Secrets.

Once you choose this option, Visual Studio will create an empty file named secrets.json inside your user folder. Now you can add as many secrets as you need inside this file. Each secret is stored as a key-value pair.

{
  "passwordForLifeAndEverything": "42"
}

All you need now is to read the value inside your code. This can be simply done by using the Configuration API.

string mySecret = Configuration["passwordForLifeAndEverything"];

When running the solution inside Visual Studio, it will automatically fetch the required data from your secrets file. Remember that this will only work for you on your own machine, and the other developers need to configure a similar setup on theirs. But the added advantage here is that everyone can have their own secrets, which is also better than sharing the same secrets with the whole team.

Secrets can also be grouped together by nesting JSON objects inside one another, such as the following secrets for a fictional mailing service.

{
    "MailService": {
        "Account": "dumdedum",
        "SecretKey": "SomethingLike8TGRKC4L71..."
    }
}

Then you can refer to each key individually by using the colon character to symbolise the hierarchical relation between the keys, for example:

string mailAccount = Configuration["MailService:Account"];
string mailKey = Configuration["MailService:SecretKey"];

You can also read them together as a group, for example in the ConfigureServices method you can add

services.Configure<MailSettings>(Configuration.GetSection("MailService"));

where MailSettings would be a class with the two mail service properties which will be automatically bound at runtime.

Secrets management is definitely an underestimated Visual Studio feature that tackle one of the most rampant credential dissemination issues inside the open-source world. This feature is also available as an extension in Visual Studio Code.

Azure DevOps provides a solution for visualising the test result history of your projects through the Dashboard. Let’s see how we can set up some charts.

Start by clicking the dashboard icon in Azure DevOps’ main menu.

You can create a new dashboard if you wish, but in this case I will show you how to edit an existing one. So click on the Edit button.

On the right-hand side of the screen, you should now see the Add Widget window. In the search box, type ‘test’ so that we can filter out the other widgets. Choose the Test Results Trend widget and click the Add button.

This will add the widget, ready to be set up.

Click on the cog icon to open the configuration window.

Set it up as shown above. The important part is the selection of the build pipeline that is running the tests. Clicking the save button will produce the following chart.

As you can see, it shows both the number of passed/failed tests as well as the test run duration. You can hover your mouse pointer over each column to get more information about the specific test run.

Let’s add another widget. This time we’ll choose the ‘Test Results Trend (Advanced)’ widget instead. This widget allows us to view the trend over a particular period of time as opposed to the trend by build which we just saw with the other widget.

Again configure the widget as shown below.

This produces the following chart, which is not particularly interesting when tests are running smoothly. Note that in some widgets, you can expand the view by clicking on the expand icon to get a larger view of the chart.

This is an example from another project where there are occasional failures.

That is how test charts can be added to your dashboard so that the whole team can keep an eye on the test results. Don’t forget to save the dashboard layout by clicking the ‘Done Editing’ button.