Versioning : Dev/Test Lab Management in the Cloud.

A Dev/Test environment evolves overtime. It evolves due changes on different sites of its lifecycle. It can have changes due to architectural refactoring on the development site, but it also evolves due to OS updates, hardware updates and other configuration artifacts updates. To keep close to the immutable systems pattern is a must to have a proper versioning configuration for your Dev/Test Lab Environments. Some thoughts and practices.

Dev/Test Lab Artifacts.

A Dev/Test Lab Environment not only contains the definition (ARM for Azure) but also scripts (PS), packages and images (default Azure or custom made images).

A GIT repo for example can host the scrip files, resource and environment definitions.


Common Packages, ISO's and installer packages which needs to be available on the system can for example live in an Azure Files location.


And the custom images together with data disc's will exist in a Azure Blob.


All these artifacts make a Dev/Test Lab environment and should be consistent per version and evolve together. Managing this dependencies for different versions is a though job. Specially because not all can be in the same versioning system.

Tool support challenge.

The version control system GIT works great for maintaining the scripts and definitions for your Dev/Test Lab environment.

For the Azure Resource Manager starter templates GitHub is used as the landing page.



Although there are GIT plugins to maintain large files, it is completely useless (I didn't even try it) to put an Azure image in GIT. Beside that it probably won't work, you also won't get the version control benefits like merge and diff. This difference in versioning for the different Dev/Test Lab artifacts brings some challenges. Due to this versioning limitation there is a disconnection between the different Dev/Test Lab artifacts which have a dependency and which isn't maintained by a tool for us.

It is a start to administer this dependency manually. For example have naming rule for Azure Images (with a versioning number) and keep that in sync with the definition and scripts. Errors can easily happen which can result in validating the wrong system or tests can't be run because the environment can't be created. Annoying.

Another solution is to use the default Azure images and script everything for the Dev/Test Lab images.


At provisioning the complete needed system software and configuration with default libraries and the system under test is created from script. It is a preferable solution above the custom images, because you don't have to maintain the 'disconnected' image. It is not always possible or desirable from a provisioning point of view (installing and configuring the whole system can take a long time).

Also the installer packages and generic company packages evolve overtime and also they don't live in a versioning system. When you script the creating and configuring of a the whole environment versioning of packages still need to be handled carefully.

GIT and ARM.

Using GIT for you environment definitions simply works great, the good thing… there are many different client tools out there for the many different roles who are involved in your Dev/Test Lab.


Visual Studio 2015 (with the Azure SDK) for team members who are happy to author ARM templates in a rich IDE, a PowerShell GIT package for the bluescreen addicts, SourceTree for a rich GIT view and (the just out of beta) GIT for Windows to control you commits from the command line or windows explorer.

Most GIT tools also have an add in for GitFlow, a great branching model and a must have support for your multidisciplinair Dev/Test Lab team .


Dev/test Lab Environment Solution setup.

Your Dev/test Lab Environment realization project comes with multiple artifacts who are related to each other, to keep it in control and reusable it is preferable to get a proper structure / setup of these artifacts. A practice, see image.

  1. A Dev/test Lab Environments project for your solution.


  1. Scripts, these contain actions in PowerShell performed on machines. Used via a custom extension. See:
    1. Deploy a Windows VM and execute a custom PowerShell script
    2. Custom Script Extension workaround, I cannot add another extension to a VM to run a script on the last node of the cluster
  2. Azure Resource Manager resource definitions.
    Vm's definition and other resources which are part of your Dev/test Lab environment. They are better to reuse, maintainable and discoverable when keeping them separate from the Dev/Test lab environment definition. Finally they can be linked with Dev/Test lab Environment definitions (4). These resource can have a reference / dependency with the script files (2). See:
    1. Create a template deployment

  1. The environment definitions for you Dev/Test Lab.
    I prefer to name it according the need, for example a UI test can / will be another definition than an acceptance test environment or a developer environment.
    1. Dev/Test Lab Management on Azure, what is your test infrastructure

  1. Packages.
    A Dev/Test Lab environment will probably have additional software installed next to the operating system. For example a developer machine will have Visual Studio 2015 and some other development tools. A Test environment can have company packages which are needed for the system under test to be tested.
    1. Managing Developer VMs in Azure with a Chocolatey Twist
    2. Introducing Microsoft Azure File Service (also interesting the comparison with Azure Blob Storage)
  2. Images and Data Discs.
    In a Blob projects can have images (custom image) with pre-installed software. Making a custom image makes the versioning live harder but will speed up the provisioning of your Dev/Test lab environment. Data discs are interesting for several reasons, you can put the Iso's and packages on it for configuring the environment, when Azure files isn't enough. Or, data with test date.

Reusable components.

For Enterprise scenario's reusability is important. Reuse the scripts, resource definitions, images etc. Creating a 'generic' project with the same structure of Dev/Test lab artifacts and use the GIT capability to create submodules, is a direction to go for the definitions and scripts. Packages, Images and Discs needs to maintained and reused in a different (copy past) way.



To stay in control and make as much benefit of the created Dev/Test artifacts it is advisable to have strategy for your artifacts, relations between them and the version.

Pingbacks and trackbacks (2)+

Add comment

Şarkı Sozleri