One common way to do this in BuildMaster v4 is to use two pipelines; a "blue" and a "green" pipeline. Another thing is to have a "Blue" and a "Green" environment, and then a pipeline like: Int > Test > Blue > Green Then, basically skip Blue or Green depending on the workflow. You can also have operation groups / action groups with predicates like "if $BlueGreen = Blue". You can certainly use the Set-Release operation (or ACtion in v4) to set configuration variables on a release.

Hi Alana, Thanks for your reply. I ended up submitting a bug Ticket which I need to respond to. But in response to your comment, The Agent and the runtime user are both the same account. Aside from the simple script above, I also tried to get it to return the value, and it would only return 's' in once case, error in another , or indicate the value was part of a Dictionary, which I'm guessing is meaning its within an array. Tod Hoven is my contact for the issue that I will be working with, but at the moment my BuildMaster instance is offline, so I will be following-up once our environment is back online. I'll try and remember to update this thread with the fix once we have it... -Trent

Thanks for response. I created a new API Key. My environment IDs are as follows: Development = 1, Testing = 2, Production = 3, Build = 5 If I run the API call you provided above for Build environment, doesn't it mean I will need to resequence the rest of the environments too?

Further troubleshooting seems to have helped. I rebuilt everything on SQL Express 16 instead of the included version 5 included with the installer and everything appears blazing fast at the moment with the more complex setup in place. I'll keep toying with it, but any insight you may have is appreciated. Thanks!

The problem here is that there is not exactly 1 environment in context. I'm guessing this is an orchestration plan? Configuration plans will already bring in the environment context if there is exactly one environment. The way this will be solved (targeted for v1.6, but may appear earlier in a v1.5.X maintenance release) is by the following rules: Context will solely be determined from environment associations of servers (this changes the current behavior which relies on orchestration jobs being targeted at an environment in order to bring the environment into context) Parent environments will only be considered for user permissions and variable resolution If there is not exactly 1 environment applicable to the current server in context, $EnvironmentName will result in an empty string (so the same as you're seeing now) We will add @EnvironmentNames which will resolve to a list of all environment names in context (including an optional parameter for including/ignoring parent environments)

There is no built-in variable function to do that, but it could be done with a custom variable function that does a lookup for the configuration variable based on the environment. Like $EnvironmentVariable(envName) or something. Let me know if you run into troubles, I can probably help! I don't know how easy it would be for us to generalize a lookup function, because there are so many different types of configuration variables (env, server, app, etc), and one might be desired for SErver, Role, etc.

We've published the BuildMasterBeta extension v4.5 which contains a fix for this. You can install this extension from the Admin->Manage Extensions page. This fix will also be included in the next maintenance release of BuildMaster, which will be 4.6.3. Thanks for the bug report!

This sound like it's just a tough process to model. No matter what you do, you can't have it both ways such that you could deploy to either a subset of DevX servers to an arbitrary subset of QAX servers. The options you'll have to decide on are either: use different workflows and different environments to separate Dev1 from Dev2, which will force releases to use a specific set of servers after a build is created for it use abstract environments (Dev, QA) with server variables that resolve to different server groups (e.g. DevSet1, DevSet2, or whatever), and select the result either at release, build, or promotion time so it provides historical context with the release/build In BuildMaster, the idea of an Environment (i.e. a different stage of testing) is meant to be abstracted from a Server (i.e. a physical/virtual machine), so whatever follows most closely to this paradigm would be the way to go.

"Agents" and "Servers" are generally synonymous, but there is a subtle difference. Servers represent actual (physical or virtual) servers that BuildMaster can orchestrate. Actions can operate against Servers, files can be transferred from one Server to another, etc. A "Server Group" is a set of servers that can be treated as a single server. Agents are the mechanism that BuildMaster uses to communicate with servers, and are tied to a specific protocol (SOAP/Binary/SSH) and/or operating system (Windows, Linux, etc). Environments are on a "higher level" than Servers and Server Groups; they describe a stage of testing that your application is currently in, e.g. "Integration", "QA Testing", or "Production". Server groups are a way to simplify deployment to clusters, if necessary. Environments can consist of any number of servers and server groups. To make matters more confusing... you can still work with other servers without an agent, but you're limited to whatever you can do in a normal Windows environment. For example, you can transfer files over UNC paths so long as permissions are set-up, etc. installing an agent and hooking it up to BuildMaster (via External Servers) allows a higher degree of control.