One of the principles of the twelve-factor app methodology is strict separation between code and config, where config means everything that is likely to vary between deployments, and code is everything that doesn’t. Historically, was not a good fit for .NET Framework applications, which relied on tools such as web.config transformation and Slow Cheetah to apply build-time transformations to application configuration files. These transformations are based on environment-specific config files stored alongside the application code in the source repo.

There are many tutorials on the web that describe more or less automated ways of deploying packaged software to Azure Web Apps. For this particular one I’ve decided to use the popular Content Management System WordPress. What many such applications have in common is that there is an initial installation procedure, consisting of copying files to a web host and configuring database access, followed by a web-based graphical installer that sets up all of the application configuration.

There are a couple of different ways to store secret variables in an Azure Pipeline. Secrets that are only needed by one pipeline can be created at that scope using the web UI: Creating a pipeline-scoped secret variable Secrets that are used by more than one pipeline can be added to a variable group: Creating a secret variable in a variable group Variable groups can also be linked to an Azure Key Vault.

A short post which might be of use to some, as it took me a while to figure it out. I’ve been making a few changes to this site lately, one of which was to move from having the images remotely hosted in AWS S3 to having them locally in the repo. This was prompted by the availability of the Hugo page bundles feature, which I think was introduced several years ago without me noticing.

For users migrating from the “Classic” VSTS/Azure DevOps release experience, it is not entirely obvious how to set up what used to be known as Pre-deployment approvals as part of a multi-stage YAML pipeline. Pre-deployment approvals in a classic release pipeline . The documentation about this is rather unclear, not least because it mixes together concepts from the “Classic” Release Management experience with concepts from the multi-stage YAML experience.

In the context of Azure Network Security Groups, it’s often useful to be able to specify security rules that only apply in certain environments. For example, we might have some kind of load testing tool that should only be permitted to connect to our testing environment, or we might want to restrict our public facing load balancer so that it is only able to connect to our production environment. I’ve long been of the opinion that when faced with complicated code of uncertain semantics - and ARM Templates for networking certainly tick both of these boxes - that a good way to understand the behaviour of the code is to write tests.

Prompted by some discussion on the SQL Community Slack, I thought I’d revisit this old post on the SSDT Team Blog which outlines how to filter specific objects from a dacpac deployment using the Schema Compare API. In the past, I’ve used Ed Elliott’s filtering deployment contributor for this kind of thing, but in the interest of experimentation I thought I’d have a look at what comes “in the box”, not least because deployment contributors can, ironically, be a bit of a pain to deploy.

It may have been a while coming, at least compared to Jenkins Pipeline, Travis-CI, and friends, but VSTS now offers the facility to specify your build pipeline as YAML, meaning it can be version controlled with your application code. YAML Release Management Pipelines are “on the way”, but not yet publically available. YAML Build Definitions are currently in public preview, so you’ll need to ensure you have the feature enabled for your account.

Config as environment variables I’m a big fan of the Twelve-Factor App “methodology”1 for building and deploying applications, and whilst much of it is geared towards web apps in Heroku-esque environments, I think the principles - or “factors” - are well worth bearing in mind when considering the delivery of other types of application. Factor 3 of the 12 reads as follows An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc).

This came up in a question after a recent talk about database unit testing; I’ve done something similar on a client project in the past, and it was in my “old” talk about testing. I thought I’d write it down here in case it’s useful to anyone, not least the person who was asking the question. A .zip file of the complete solution can be downloaded from here. For many years, Visual Studio Database Projects - in SSDT as well as in its predecessors - have included an additional template for generating SQL Server Unit Tests.