Skip to content

feat: update to use record-deployment instead of tagging as prod #13

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
bethesque merged 1 commit into from
Jul 8, 2021
Merged

feat: update to use record-deployment instead of tagging as prod #13

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 6 additions & 9 deletions Makefile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
PACTICIPANT := "pactflow-example-provider"
GITHUB_REPO := "pactflow/example-provider"
PACT_CHANGED_WEBHOOK_UUID := "c76b601e-d66a-4eb1-88a4-6ebc50c0df8b"
PACT_CLI="docker run --rm -v ${PWD}:${PWD} -e PACT_BROKER_BASE_URL -e PACT_BROKER_TOKEN pactfoundation/pact-cli:latest"
PACT_CLI="docker run --rm -v ${PWD}:${PWD} -e PACT_BROKER_BASE_URL -e PACT_BROKER_TOKEN -e PACT_BROKER_FEATURES=deployments pactfoundation/pact-cli:0.46.1.0"

# Only deploy from master
ifeq ($(TRAVIS_BRANCH),master)
Expand Down Expand Up @@ -49,22 +49,19 @@ test: .env
## Deploy tasks
## =====================

deploy: deploy_app tag_as_prod
deploy: deploy_app record_deployment

no_deploy:
@echo "Not deploying as not on master branch"

can_i_deploy: .env
"${PACT_CLI}" broker can-i-deploy --pacticipant ${PACTICIPANT} --version ${TRAVIS_COMMIT} --to prod
"${PACT_CLI}" broker can-i-deploy --pacticipant ${PACTICIPANT} --version ${TRAVIS_COMMIT} --to-environment production

deploy_app:
@echo "Deploying to prod"
@echo "Deploying to production"

tag_as_prod:
"${PACT_CLI}" broker create-version-tag \
--pacticipant ${PACTICIPANT} \
--version ${TRAVIS_COMMIT} \
--tag prod
record_deployment: .env
@"${PACT_CLI}" broker record_deployment --pacticipant ${PACTICIPANT} --version ${TRAVIS_COMMIT} --environment production

## =====================
## Pactflow set up tasks
Expand Down
4 changes: 2 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,11 +30,11 @@ To ensure that a verification is also run whenever a pact changes, we create a w
* If we are on master:
* Check if we are safe to deploy to prod using `can-i-deploy` (ie. do we have a succesfully verified pact with the version of the consumer that is currently in production)
* Deploy (just pretend!)
* Tag the deployed application version as `prod` in Pactflow so Pactflow knows which version of the provider is in production when the consumer runs `can-i-deploy`.
* Record the deployed application version in Pactflow so Pactflow knows which version of the provider is in production when the consumer runs `can-i-deploy`.
* The target `ci_webhook` just runs the pact verification step, and is used when the build is triggered by the webhook.

* In [src/product/product.pact.test.js](src/product/product.pact.test.js):
* When the `$PACT_URL` is not set (ie. the build is running because the provider changed), the provider is configured to fetch all the pacts for the 'example-provider' provider which belong to the latest consumer versions tagged with `master` and `prod`. This ensures the provider is compatible with the latest changes that the consumer has made, and is also backwards compatible with the production version of the consumer.
* When the `$PACT_URL` is not set (ie. the build is running because the provider changed), the provider is configured to fetch all the pacts for the 'example-provider' provider which belong to the latest consumer versions tagged with `master` and those currently deployed to an environment. This ensures the provider is compatible with the latest changes that the consumer has made, and is also backwards compatible with the production/test versions of the consumer.
* When the `$PACT_URL` is set (ie. the build is running because it was triggered by the 'contract content changed' webhook), we just verify the pact at the `$PACT_URL`.
* Pact-JS has a very flexible verification task configuration that allows us to use the same code for both the main pipeline verifications and the webhook-triggered verifications, with dynamically set options. Depending on your pact implementation, you may need to define separate tasks for each of these concerns.
* When the verification results are published, the provider version number is set to the git sha, and the provider version tag is the git branch name. You can read more about versioning [here](https://docs.pact.io/getting_started/versioning_in_the_pact_broker).
Expand Down
2 changes: 1 addition & 1 deletion src/product/product.pact.test.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ describe("Pact Verification", () => {
const fetchPactsDynamicallyOpts = {
provider: "pactflow-example-provider",
//consumerVersionTag: ['master', 'prod'], //the old way of specifying which pacts to verify
consumerVersionSelectors: [{ tag: 'master', latest: true }, { tag: 'prod', latest: true } ], // the new way of specifying which pacts to verify
consumerVersionSelectors: [{ tag: 'master', latest: true }, { deployed: true } ], // the new way of specifying which pacts to verify
pactBrokerUrl: process.env.PACT_BROKER_BASE_URL,
enablePending: false,
includeWipPactsSince: undefined
Expand Down