Hi Chris, If you haven't already, make sure to check out KB#1118: Legacy Plans in BuildMaster 5.0 to see how to import plans and how the concepts differ. The technique for handling this scenario would be.. foreach deployable in @DeployablesInRelease { «operation1» «operation2» «operationN» } That being said, the @DeployablesInRelease function is not available in v5.0.4, and this specific translation is not handled by the importer, which is a bug in v5.0.4. We will fix this in 5.0.5 and will ship this quite soon (by end of week).

Waiting might be best for me. <-not so good with object oriented languages. I think it would be a great additions to be able to access the many types of Variables. (application, release, build are the 3 types I use, not sure about the rest of your client base) I expect my end result would look like: $ReleaseVariable(${ReferancedApplicaitonID, ,${ReferancedReleaseNumber, FolderNumber) Wow that just got crazy. Think it can handle passing in functions to find a variable? I am not in a rush, I just want to reduce the risk of problems. And because 4.3 did a major change to the database my built-in-house reports would have to be redone, so I am being lazy with updates. Also this solution would be able to consolidate some of my shared plans that each call different variables, if I instead ask for a variable by passing in the environment like this: $Appvar(${AppID}, ${EnvName}Server) I can have the same task work on all my environments. Thanks, Dan

It sounds like this is a bit of a hack; when an application component is deployed to a production environment, it's status should be represented as "Deployed". You can purge releases if needed using the Releases_PurgeReleaseData API/Sproc method.

The dependencies in BuildMaster don't quite work like, say, NuGet dependencies or something. It's more meant for sharing artifacts and the like. But, check out the "Create Build" or "Promote Build" actions.

The linked action groups are more about "code reuse" than anything else. But you may want to check out the Promote Build and Create Build actions; those come in handy when dealing with dependencies like this. Usually, you'll see a promotion of ESB trigger the MainApp.

For future reference, this was happening because the application attempting to be built was including an imported deployable, and there was no active build in the referenced application. The error message will be clarified in the next version of BuildMaster (v3.2.2).

It appears you've discovered a bug in our variables engine that will be fixed in the next maintenance version v3.1.5 (scheduled on or before 5/25/12). Thanks for the report.

Yes. This is what “imported deployables” are used for; on the deployables screen, just add an imported deployable, and then you will be able to create an action group that can deploy that artifact. The “framework recipe” demonstrates this usage somewhat.