You have developed a microservice in .NET Core 2 and want to host it as a Docker Container in Kubernetes. Your Microservice contains settings, some appsettings or connectionstrings for example. These settings differ over environments. You can treat this configuration for Kubernetes on different ways. This blogposts shows you how to handle settings over environments prepared for Continuous Delivery.
The Create SAS Token task creates a SAS Token which can be used to access a private Azure Storage Container. The task also gets the StorageUri. Both variables can be used in subsequent tasks, like the Azure Resource Group Deployment task. This is the first task of the Infrastructure as Code serie.
25-8-2016: Update because the UI to create a Service in VSTS changed
When you want to access Azure from VSTS there are multiple possibilities. It’s for example possible in VSTS to configure an Azure Classic Endpoint and after that configure the endpoint with credentials or with a certificate. The ARM way is to add an Azure Resource Manager Endpoint. To configure this you will need the settings of an Azure Service Principal. This blogpost tells you how to create both the Service Principal in Azure and the ARM Endpoint in VSTS.
The Azure WebApp Configuration task reads VSTS variables and adds those as AppSettings and ConnectionStrings to an Azure WebApp. The task also supports Slot Settings. The task can be linked to a web.config to validate if all AppSettings and ConnectionStrings in the web.config exists as VSTS variable.
Maybe you’ve read about Git for a long time and use it for your private projects. Maybe you want to migrate your project’s TFS Version Control to Git, either with TFS Git or elsewhere, but don’t know how. Or maybe you’ve read Dennis Doomen’s post about ‘Why you should abandon TFS and adopt Git’ and though: ‘I really need to move over right now, but how?’ If you are using TFS you will probably have a history that you want to have in Git also.