Managing dependencies

4 minute read

Today’s business applications are generally built by integrating third-party applications or microservices with in-house applications or microservices. CloudBees Flow lets you model and manage dependencies across applications or microservices such as these in your product. With the dependency information captured, CloudBees Flow enforces these dependency rules to ensure quality deployments.

Key Benefits

Capturing and using application or microservice dependencies has the following benefits.

Easier Deployments

With dependencies, CloudBees Flow can help construct your deployment plan. For example, if a dependency is captured as A > B > C > D, then CloudBees Flow can enforce these dependency rules at runtime.

More Reliable and Safer Deployments

Captured dependencies make safe deployments by preventing you from making mistakes that violate the dependency information that was captured.

Application or Microservice Dependency Rules

Dependency rules can be captured at two levels:

  • At the application or microservice level—Application- or microservice-level dependency rules let you capture simple dependencies between applications or microservices. For example, a marketing application might require just a version of a deployed user authentication application to exist in order for it to function.

  • At the application or microservice version level—An application or microservice version in CloudBees Flow maps to a snapshot name. A snapshot stores the state of the application or microservice at a point in time. You can use the application or microservice snapshot names to create complex version dependency rules.

You can also use regular expressions with the dependency rule configuration. For example, version ‘ms1’ (a snapshot) of a marketing application depends on versions ‘uas2’ and ‘uas3’ (snapshots) of a user authentication application.

Application or Microservice Dependency Rule Examples

Rule Parent Application or Microservice Version Child Application or Microservice Version Notes

1

A

Any

B

Any

Application or microservice A depends on B. This is a very generic rule.

With only this rule, you can deploy any version of application or microservice A as long as any version of application or microservice B is deployed (rule 1).

2

A

1.2

B

1.1.5

Application or microservice A version 1.2 requires application or microservice B version 1.1.5.

If you try to deploy application or microservice A version 1.2, the system ensures that application or microservice B version 1.1.5 (rule 2) is deployed.

3

A

1.2

B

1.2.0

Application or microservice A version 1.2 depends on application or microservice B version 1.1.5 or 1.2.0.

If you try to deploy version 1.2 of application or microservice A, the system ensures that application or microservice B version 1.1.5 (rule 2) or 1.2.0 (rule 3) is deployed.

4

A

2.*

B

1.8.*

Any 2.* version of application or microservice A requires any 1.8.* version of application or microservice B.

If you try to deploy version 2.2 of application or microservice A, the system ensures at least one 1.8.* version of application or microservice B (rule 4) is deployed.

5

A

2.*

C

3.*

Any 2.* version of application or microservice A depends on any 3.* version of application or microservice C.

If you try to deploy application or microservice A version 2.2, the system validates to ensure at least one 1.8.* version of application or microservice B is deployed (rule 4) and at least one 3.* version of application or microservice C is deployed (rule 5).

If you try to deploy version 4.0 of application or microservice A, then the system checks to ensure at least one version of application or microservice B is deployed (rule 1).

6

A

2.7

Note: application or microservice A version 2.7 is created on 05/21/2017

B

1.9.2

You can use an effective_date attribute such as EFFECTIVE_DATE 05/20/2017 on the dependency rule. This is an advanced feature that is not available from the UI.

Specifying an effective date applies these rules only to versions that are created on or after the date.

If you try to deploy application or microservice A version 2.7 on 5/25/17, then the system checks to ensure that version 1.9.2 of application or microservice B is deployed. This is true for all versions of application or microservice A created after 05/20/2017 (rule 6) and at least one 3.* version of application or microservice C is deployed (rule 5).

If you try to deploy application or microservice A version 2.2 (or any version created before 05/20/2017), the system validates to ensure at least one 1.8.* version of application or microservice B is deployed (rule 4) and that at least one 3.* version of application or microservice C is deployed (rule 5).

Example of How to Create Application or Microservice Dependencies

Navigate to the application or microservice architecture page and select Dependencies from the menu. The following example shows the menu option for an application:

application dependencies menu option

A dialog appears in which you can create the dependency rules.

In this example, you create a dependency rule for a FaceTime application that has a dependency on the iCal application that manages the calendar information. The rule specifies that FaceTime version 1.0 requires iCal version 3.1 to be deployed.

You can also specify dependency rules based on regular expressions while setting up the dependencies. For example, you can enter 4.* for the iCal version as part of the second rule shown above.

Once all the dependencies are captured, then at application or microservice deployment time, you can enforce these dependencies or ignore them. By default, dependency checks are enforced. This means that if the dependency validation fails, then the deployment errors out. You can disable this behavior by toggling the Dependencies option. When enforcement is disabled, then violations are treated as just warnings, and deployment will proceed.

If the user tries to deploy the Facetime application version 1.0, it will error out because of a missing iCal version dependency.

Application or Microservice Dependency Configuration in a Pipeline

You can enable a dependency check while defining the App Process or Service Process pipeline stage task definition. For example:

application depend enable in pipeline

Application or Microservice Dependency Configuration in a Release

Similarly, while setting up a release, you can configure a dependency check for each application or microservice in the release. Once the dependency checks are configured, the deployer ensures that dependency requirements are met before deploying each of these applications or microservices in the release. The following example shows how to configure dependency checks for a release that contains one application:

application depend enable in release