For most use cases, deployables are mostly a "vestigial" feature; they were very important in v4 and earlier , in that they permitted partial deployments and cross-application orchestration (dependencies, artifacts, etc). Moreover, as organizations are moving towards a "microservice" architecture, the concept of a large application with many depoyables is becoming rarer. In an v5/OtterScript plan, you can do this: for deployable web-application { ... operations ... } In this case, the "current deployable in context" will be web-application, and if that deployable is not included in the release, then the block is skipped. You can also add variable key/value pairs to a deployable. When a deployable is context (as the case above), that variable will be evaluated. With "cross-application deployables", you can have one application reference a release of another application. When doing this, it's changing the release number in context. So, for example, if web-application was imported from another application, then $ReleaseNumber would resolve to that application's number. All that said... all of these things are more intuitively accomplished through variables, and for most users that's just fine. In a new application you create will not have any deployables.

It would appear this isn't currently supported, you're right; we will add this in a future release!

First of all, Thanks for your answer. I know it, but the problem is that I have more than one deployable in an application, sometimes the new builds has no need to re-build all of them, but in the last step of my deploy plan, I need to update a sql table with the versions of all the deployables included into the build deployed. For that reason I need to access an specific deployable, and then, of course, I will use the $referencedBuildNumber function. "$ReferencedBuildNumber : Returns the build number referenced by the imported deployable in the current scope." Thanks

You could use a different workflow (or in v5, "pipelines" as they will be called)... and then have a different build importer/feed on each. Alternatively, you could not use the build importer, and just have a build step download the package and incorporate it as an artifact.

Yes, I believe that does make sense. If I want to be able to control order of execution, it sounds like I should turn my deployables into their own separate child applications. Then I can specify order of deployment of each child application within whatever "master" application I am deploying.

Predicates in combination with variables (e.g. the Set Variable Value action, $BackupDB = true, then check for that later as necessary) are a good idea for the meantime. We've had requests that imported deployables should be allowed to be dependencies and that feature is scheduled for a future version.

Just to follow up, got some help from the inedo folks and we discovered that the server hosting the sql server database had its system clock slightly off which was causing the delay till the start of execution.

In general, we recommend going with a "business context friendly" name for your application. There are several reasons for this, but it mostly goes back to the fact that it's a lot easier to share/consume friendly names. There are times, however, when it makes sense to match name/code/scm/etc., and this is usually when there's a "conventions" approach. For example, our extensions (see BuildMaster Implementation Specifics) use the application name to determine a lot. But this usually only makes sense when you have a lot of "cookie cutter" componentized applications (such as in our case). So for your example, I would say name it "Awesome", and then have multiple deployables within that application. I wouldn't use the word "solution" unless it's actually part of the business name. For us, the application name is "BuildMaster" not "BuildMaster Solution"... even though our codebase has a "BuidMasterSolution" folder and a "BuildMasterUbserSolution.sln" file.

Hi Jeff, Great questions. We try to deal with complex situations as simple as possible, but complex things can get complex. So, of course, "it depends". We're starting to document some of these in our specifics section ( http://inedo.com/specifics ) -- it's a work in progress, but we hope it gives some idea. The first step is to "translate" your organizational specific terminology to BuildMaster's terminology. We model software development as a whole, so we can implement really any structure process... it's just about figuring out what should be a deployable, what should be an application, etc. The "Release Management Done Right" whitepaper discusses the terminology we use. With only the information you provided, it's difficult to give specific advice, but from what it sounds like, the question is between Applications and Deployables. There's a KB article on the topic - http://inedo.com/support/kb/1032/the-difference-between-deployables-and-applications - that discusses differences. Dependencies are defined at the deployable level (AppX depends on EntFramework) and used at the release level (AppX 3.2 depends on EntFramework 2.0). This enables all sorts of complex patterns we've seen implemented. Feel free to contact us ( http://inedo.com/contact ), and we can discuss this in more detail and possibly help build a proof of concept. Best, Alex

Yes we seem to have an older version. I will update this and let you know. Thanks Chris

Ah. Currently on 2.6. Will upgrade immediately!

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.

It is working now that I set the Action Group to "all deployables". I still can't use the specific deployable though. I copied the named deployable through my steps and it fails... but the generic works just fine.