0

I'm doing a graduation project where I'm supposed to automate the deploy cyclus within the company I'm working. The tool they want to use is Microsoft Release Management.

However, when i look further into the features that Release Management has, it raises more questions than answers.

Some background information.

All the environments the company has are going to be moved to a data center and are going to run on virtual machines (VMware). They can use the tool vCloud director to create and manage the VMs.

To keep things simple for now there are going to be four enviroments: 1 dev, 2 testing and 1 acceptence. The four environments are always running, so i suppose Release Management has no problem connecting to these server and I can make release templates without problems.

Now comes the tricky part. At the same time a deployment is done to the dev environment they want to create a new VM (with powershell scripts, some sort of copy of the dev) and do the same deploy to this environment. This script needs to communicate with a third-party tool or to the REST API that the hosting provider provides. I know the script needs to run within a server component in a release template. So i know 2 known workarounds for this. i can run this script in my release template when i deploy to the dev or i can use a dedicated server to run all the scripts, to create the new VM.

The thing is how can i deploy to this new environment without telling release management manually that there is a new server? This process needs to be completely automated.

BaCaRoZzo
  • 7,502
  • 6
  • 51
  • 82
bart088
  • 1

1 Answers1

0

Bottom line: Release Management does not currently have a native, easy way of provisioning new VMs and deploying to them. I've hit this limitation myself. You're not going to be able to do it using deployers. You can, however, work around it.

The approach I've taken is to use Desired State Configuration and use a "springboard" server (rm-dsc-launcher) in conjunction with a custom PowerShell script I wrote. In my case, it was Azure. In your case, it's VMWare. Regardless:

  1. I created a Desired State Configuration script and any custom DSC resources necessary to configure my environment and install my software. This is checked into source control and pushed to the build drop so it's available at deployment time.
  2. I created a custom tool/action called "Provision Environment" that takes all of the necessary parameters to make a new VM.
  3. I created a custom tool called "Execute DSC script", and used this within a Component for my application's binaries. One of the parameters is the path to the deployment script. You can access the path to the binaries/scripts by passing in the value $(PackageLocation) as a parameter to a component.

It's not the prettiest solution in the world, but it is functional.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120