0

We currently use the Visual Studio Release Management tool to manage the release phase of our code. At the moment, we are using the action based, old templates, that require a dedicated deployment agent installed on each target machine. In the future, we plan to use the Desired State Configuration approach, but I stumbled on a problem that I could not answer myself now. I suspect this will apply to the DSC pipeline too, but I'm focusing now on the action/component based one.

In RM, you can only place actions and components in machine scopes. You have servers which have the deployment agent installed that are selectable in the pipeline, and they are the base entity in the workflow. Everything goes inside of these machine scopes.

But we now have a release requirement that is not an installation per se. One of the actions we would like to automate is the publishing of an android apk in google play, but this does not depend on any particular machine, since it does not install anything. It needs the apk itself, which is in our drop folder, but it does not need to copy it to any of our machines.

Since RM does not allow one to place actions and components outside of machine scopes, what is the strategy to run machine independent release actions inside the tool? I thought about installing the deployment agent in the same machine as the RM server and using another machine scope, "localhost", to do this, but it seems very convoluted.

What I wanted is very similar to how TFS Build works. When the build workflow starts, it is running on the build controller, and you can place any activity at that scope. Then, at some point of the workflow, it starts running tasks in the build agent. Is there something similar to "run on the controller itself" for RM?

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
julealgon
  • 7,072
  • 3
  • 32
  • 77

1 Answers1

1

Your approach is the one I generally use... I call it a "springboard" server. I use this for things like provisioning virtual machines to serve as deployment targets via DSC, or for running integration tests against a freshly-deployed environment. It's not ideal, but it's functional and minimally invasive.

I would recommend making your springboard server a fairly low-powered but dedicated VM. You don't want someone to accidentally mess up your RM server's IIS installation!

DSC probably won't have this issue; at least in the implementation present in Update 3, you can place actions outside of a machine scope. With DSC, you can specify an additional "Configuration" script that contains associative arrays full of target nodes, allowing you to keep your node configuration separated from the desired state script.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
  • I don't get it, how exactly are you automating this kind of task with the DSC pipeline? The only available actions there are the DSC/Chef ones. Using these configuration systems to perform imperative, machine independent work seems very out of place and not well suited to the purpose of the tools. I mean... I can't even express the google play apk deployment as a DSC configuration at all oO. I'm seriously thinking about not migrating to the new DSC pipeline at all and instead creating my own action that manually invokes the Start-DSCConfiguration cmdlet, and then using that in the old pipeline – julealgon Oct 22 '14 at 00:36
  • And by the way, you can't even _create_ machine scopes with the update 3 templates... it's really hard to understand some of the decisions the tooling guys make sometimes... why on earth the pipelines need to be mutually exclusive anyways? I'm quite curious to see your pipeline now... could you perhaps update your post with a simple screenshot of one of your stages? – julealgon Oct 22 '14 at 00:40
  • I don't use the vNext features right now -- just like you're considering, I use the "old style" release templates in conjunction with a deployer installed on a dedicated 'springboard' server to invoke DSC via PowerShell scripts I wrote myself. It's janky but it works well enough. – Daniel Mann Oct 24 '14 at 16:05