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.
