DocsFeaturesService Dependencies

Service Dependencies

Understand Service dependencies, their effects, and configuration.

Lifecycle has different controls for selecting Services and ordering their deployment:

  • environment.defaultServices and environment.optionalServices select the Environment’s starting catalog.
  • services[].requires includes a service dependency.
  • services[].deploymentDependsOn orders deployment of Services in the Environment.

environment.{defaultServices,optionalServices}

These lists select the Services offered by the current repository’s Environment:

  • Lifecycle selects defaultServices initially.
  • Users can select optionalServices.

They do not rewrite the default or optional lists in a different repository, and they do not change an existing static Environment.

services.requires

If a selected Service must include a different Service from the same lifecycle.yaml, use requires. For example, an API can include its database:

Selecting api includes database when a different repository references api as a default or optional Service.

⚠️

requires resolves only one level. If api has a direct requires entry for database, and database has one for storage, selecting api does not include storage automatically.

For a deeper dependency, add a direct requirement to the selected Service. You can also list the dependency explicitly in the consuming Environment.

services[].deploymentDependsOn

When one selected Service must finish before a different Service starts, use deploymentDependsOn. Its values are Service names:

Lifecycle deploys services at the same dependency level in parallel, then moves to the next level. A dependency cycle marks the affected deploys as deploy_failed with a cycle error.

⚠️

requires does not guarantee deployment order. If the API needs the database included and must wait for it, use requires and deploymentDependsOn. Each name must match a selected Service.

Reference a Service from a different repository

A consuming repository can select a Service defined elsewhere:

Lifecycle reads api and its direct requires entries from that repository. The consuming repository does not have to duplicate those direct dependencies. It must list each dependency that requires does not resolve.

Check the graph

After changing dependencies:

  1. Validate lifecycle.yaml.
  2. Examine the selected Service set in Mission Control.
  3. Check that the selected Service set contains all direct requirements.
  4. Check that deployment starts in the order declared by deploymentDependsOn.

If a Service is missing, check for a direct requirement. Then, check for an unsupported transitive dependency. If deployment starts before its dependency, add deploymentDependsOn. Do not add a requires entry only for ordering.