When experimenting with things, building labs, constructing demos, the tendency is to go quick and dirty and create resource directly in the Azure Portal, then delete and forget about it forever. This approach is not perennial and is hardly repeatable, and countless times I’ve found myself rebuilding something I already built thrice before.

This post aims at presenting a few things I’ve been doing to help reuse, distribution and automate repeated tasks for ephemeral workloads.

Repositories organization

I’m using Azure Devops to store code rather than GitHub. The main driver is that I use several projects to segregate intent:

  • Preliminary Pudding contains repos that are purely in the domain of experimentation
  • Above Butter contains what I need to share with specific people. I’m using this project as a publishing platform: everything there is also in Preliminary Pudding and I’m pushing it only when it’s ready
  • Useful Mosquito contains scripts I build to help automation, and is in my PATH variable
  • Human Babushka are “products” that I intend to develop long-term - mainly tools.

Naming convention

Inside those projects I create repositories. All have a naming convention appropriate to their use:

  • Scripts and utilities are named with something I can remember easily - gh for the github CLI, git-init-repo for Git repository initialization, k8s-switch-namespace, etc.
  • Ephemeral workloads are named accordingly:
    • Experiments are things I build for my own R&D. They are all prefixed by exp, then contain an indication regarding the technology I’m experimenting with and the topic of the exp: exp-functions-actors is an experiment with Azure Functions to implement actors with them
    • Demos are things I build to show, either during presentations to customers, on this blog, or conferences. They are prefixed by demo and usually indicate what concept is demonstrated (demo-storage-valet-key-pattern), or a generic demo type that can be used for other purposes (demo-aspnet-core is containing a generic dotnet website I can use to show deployment somewhere else)
    • PoC are things purpose-built, to demonstrate usability of a technology in a certain context, usually for customers. (E.g. poc-aadb2c-wso2 is trying to connect AAD B2C with WSO2 for a customer`)
  • Most “products” have a stupid name built with codename.feval.ca to spend time on coding rather than thinking about a name.

Repository initialization

I found that most of the time something didn’t end up in a repo was due to the marginal cost of creating the repository. To remediate to that, I created a script that does that for me.

The tool is:

  • Creating a repository on Azure Devops (unless otherwise specified, I can also create on GitHub with the same script), using a default project (Preliminary Pudding, where most of my stuff is ending up, unless otherwise specified), using the name of the current folder as the name of the repo (unless otherwise specified).
  • Download a base .gitignore for Visual Studio (unless otherwise specified, I can skip or specify any GitHub default .gitignore instead)
  • Add the devops repo as the origin remote (unless otherwise specified)

What I’m doing is then simply:

  • Create a repository following the convention exposed above, start coding.
  • Run that command: git-init-repo
  • Add code to Git the same way I always do: git add, git commit, git push.

I found that just this simple script is making the marginal cost of saving my code low enough that all and everything arrives on Devops. This tool is available from this repository.


The next step is with provisioning resources on Azure. Most the things I do require creating some resources ; and I also need a way to manage the resources I created. I built up this provisioning tool to help with that. It basically generates a provisioning script that I can push to my repository. This way, if I ever need to reuse a demo, or if I need to share it with a customer, I just need to run ./provision.sh, and everything from resource groups to service principals gets provisioned.

It also generates cleanup.sh script that I can call to get rid of the assets I generated, and uses some degree of randomization so that I can have the resources generated on my subscription at the same time as my customers.

The point is to reduce friction with generating standard provisioning scripts. I set the basic resources in a provision.yml file:

    - type: storageaccount
    - type: webapp

And then run provision -f provision.yml, which generates the .sh that I can version control.

This tool is not exhaustive and doesn’t intend to be, but it’s giving me a baseplate from which to build those provisioning scripts.