If you need information from one of your blueprint components to complete the provisioning of another component, you can draw an explicit dependency on the design canvas to stagger provisioning so the dependent component is not provisioned prematurely. Explicit dependencies control the build order of a deployment and trigger dependent updates during a scale in or scale out operation. Software components are required to be ordered in a blueprint.

When you design blueprints with multiple machines and applications, you might have properties you need from one machine to finish an application installation on another. For example, if you are building a Web server you might need the host name of the database server before you can install the application and instantiate database tables. If you map an explicit dependency, your database server starts provisioning when your Web server finishes provisioning.


Software components must have an ordered dependency in the blueprint. Unordered software components can cause blueprint provisioning to fail. If there is no actual order dependency for the software components, you can satisfy the blueprint ordering requirement by adding a faux dependency between the software components.

To map a dependency on your design canvas, you draw a line from the dependent component to the component you are depending on. When you are finished, the component you want to build second has an arrow pointing to the component you want to build first. For example, in the Controlling the Build Order by Mapping Dependencies figure, the dependent machine is not provisioned until the primary machine is built. Alternatively, you can configure both machines to provision simultaneously but draw a dependency between the software components.

Figure 1. Controlling the Build Order by Mapping Dependencies

Mapping build order dependencies on the blueprint canvas.

If you are designing blueprints to be scalable, it is a best practice to create single layer blueprints that do not reuse other blueprints. Normally, update processes during scale operations are triggered by implicit dependencies such as dependencies you create when you bind a software property to a machine property. However, implicit dependencies in a nested blueprint do not always trigger update processes. If you need to use nested blueprints in a scalable blueprint, you can manually draw dependencies between components in your nested blueprint to create explicit dependencies that always trigger an update.