Resilient Builds With Can-I-Deploy

The pact CLI tool, which is used to interact with PactFlow via the CLI, has a command named can-i-deploy. This command is used as part of application deployment to check if there has been a successful verification. This successful verification happens between existing application versions and the application version you’re about to deploy. A successful can-i-deploy check indicates that the application being deployed is compatible with the applications it integrates with, making it safe to deploy.

The can-i-deploy command may also indicate that the verification results are unknown at the time the check is performed. This indicates the verification process is still executing. Since the verification result is not yet available, we cannot tell if it's safe to deploy and the build, meaning the deployment process could fail.

Why Are The Results Unknown?

When performing consumer driven contract testing, a typical flow would include a webhook that kicks off a new provider application build when a consumer application publishes an updated pact file. This provider application build will verify the pact, which generates the result can-i-deploy needs to check. If the provider build has not finished verifying the pact when the check is performed the result is unknown.

Bi-directional contract testing makes the can-i-deploy step less dependent on the provider application build, as PactFlow can compare the updated consumer pact file with an already published OAS file. However, complex OAS and pact files take time to compare, and the results can also be unknown the first time the can-i-deploy check is called due to the speed of the automated testing pipeline. In either case, the build can be blocked.

What Can I Do To Make My CI/CD Pipeline Resilient?

Polling

The can-i-deploy command can be configured to poll for results. This allows the command to wait a short time and retry so that it can get the complete results rather than failing. This command works for standard contract testing AND bi-directional contract testing. By using the retry-while-unknown and retry-interval flags you can configure the number of retries to attempt and the number of seconds before each retry to suit your needs.

Factors to consider when configuring these flags:

How long does your provider build take to perform the verification step for consumer driven contract testing?
How large and complex is your OAS file for bi-birectional contract testing?
How long are you willing to have your pipelines run before failing?


pact-broker can-i-deploy --pacticipant Foo \ 
                         --version 617c76e8bf05e1a480aed86a0946357c042c533c \ 
                         --to-environment production \
                         --retry-while-unknown 5 \
                         --retry-interval 3

Branches and Environments

Bi-directional contract testing is not dependent on running a separate provider build to complete pact verification. Instead, PactFlow generates comparisons with the OAS files from integrated applications to verify compatibility with each version of each integrated application.

PactFlow uses branches of applications and deployed environments to determine which verification results are most likely to be required in future can-i-deploy checks. These specific verification results are then pre-generated whenever a new pact is published, allowing the can-i-deploy command to quickly access the pre-generated results in most cases.

Utilizing both strategies will improve the resilience of your CI/CD pipeline and prevent unnecessary build failure so that you can always deploy with confidence. For a more detailed breakdown on how to use the can-i-deploy CLI tool in CI/CD check out the PactFlow docs on the subject here.