Today’s business applications are generally built by integrating third-party applications with in-house applications. CloudBees CD/RO lets you model and manage dependencies across applications such as these in your product. With the dependency information captured, CloudBees CD/RO enforces these dependency rules to ensure quality deployments.
| Dependencies are applicable to traditional applications only. |
Key benefits
Application dependency rules
Dependency rules can be captured at two levels:
-
At the application level: Application-level dependency rules let you capture simple dependencies between applications. 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 version level: An application version in CloudBees CD/RO maps to a snapshot name. A snapshot stores the state of the application at a point in time. You can use the application 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 dependency rule examples
| Rule | Parent Application | Version | Child Application | Version | Notes |
|---|---|---|---|---|---|
1 |
A |
Any |
B |
Any |
Application A depends on B. This is a very generic rule. With only this rule, you can deploy any version of application A as long as any version of application B is deployed (rule 1). |
2 |
A |
1.2 |
B |
1.1.5 |
Application A version 1.2 requires application B version 1.1.5. If you try to deploy application A version 1.2, the system ensures that application B version 1.1.5 (rule 2) is deployed. |
3 |
A |
1.2 |
B |
1.2.0 |
Application A version 1.2 depends on application B version 1.1.5 or 1.2.0. If you try to deploy version 1.2 of application A, the system ensures that application 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 A requires any 1.8.* version of application B. If you try to deploy version 2.2 of application A, the system ensures at least one 1.8.* version of application B (rule 4) is deployed. |
5 |
A |
2.* |
C |
3.* |
Any 2.* version of application A depends on any 3.* version of application C. If you try to deploy application A version 2.2, the system validates to ensure at least one 1.8.* version of application B is deployed (rule 4) and at least one 3.* version of application C is deployed (rule 5). If you try to deploy version 4.0 of application A, then the system checks to ensure at least one version of application B is deployed (rule 1). |
6 |
A |
2.7 Note: application A version 2.7 is created on 05/21/2017 |
B |
1.9.2 |
You can use an Specifying an effective date applies these rules only to versions that are created on or after the date. If you try to deploy application A version 2.7 on 5/25/17, then the system checks to ensure that version 1.9.2 of application B is deployed. This is true for all versions of application A created after 05/20/2017 (rule 6) and at least one 3.* version of application C is deployed (rule 5). If you try to deploy application 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 B is deployed (rule 4) and that at least one 3.* version of application C is deployed (rule 5). |
Example of how to create application dependencies
Navigate to the application architecture page and select Dependencies from the menu. The following example shows the menu option for an application:
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 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 dependency configuration in a pipeline
You can enable a dependency check while defining the app process pipeline stage task definition. For example:
Application dependency configuration in a release
Similarly, while setting up a release, you can configure a dependency check for each application in the release. Once the dependency checks are configured, the deployer ensures that dependency requirements are met before deploying each of these applications in the release. The following example shows how to configure dependency checks for a release that contains one application:
