これまでの話の流れが追えていればcan-i-deployの仕組みはなんとなく想像がつくと思います。基本的な仕組みとしては想像通りで、コンシューマが契約を更新後に、更新された契約を引き続きプロバイダ側が満たしているかをブローカー経由でチェックしに行きます。 注意すべき点は、コンシューマがデプロイ可能かどうかを判断するためには、現在のプロバイダのデプロイバージョンに対して確認する必要があるということです。かつ、本番環境・開発環境など、一般的に複数のデプロイ環境があります。デプロイしようとしている環境が開発環境であれば、開発環境にデプロイされているプロバイダのバージョンに確認する必要があります。 そうなってくると、Pactブローカーに現在どのバージョンがどの環境にデプロイされているかという情報を予め教えてあげる必要があります。これを、record-deploymentといいます。 というわけで、can-i-deployの前準備として、一旦現在デプロイされているコンシューマ・プロバイダに対して手動でrecord-deploymentを実行してみました。 <pre><code>~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant auth0-next-custom --version 445fec738b5a4761bda6379ca37286062d079401 --environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

No environment found with name 'dev'. Available options: production, test

~/work/auth0-next-custom$&nbsp;</code></pre> dev環境がないと言われました。production, testはそのまま使えるようですが、それ以外はまず環境自体を定義してあげる必要があるようです。対応するアクションは、 create_environment です。 <pre><code>~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker create-environment --name dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Created dev environment in the Pact Broker with UUID xxxxxxxxxxxx

~/work/auth0-next-custom$&nbsp;</code></pre> 無事作成できました。それでは再度record-deploymentを実行してみましょう。 <pre><code># コンシューマ

~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant auth0-next-custom --version 445fec738b5a4761bda6379ca37286062d079401 --environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Recorded deployment of auth0-next-custom version 445fec738b5a4761bda6379ca37286062d079401 to dev environment in the Pact Broker.

~/work/auth0-next-custom$&nbsp;


# プロバイダ

~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant google-login-back --version f042bc78690b272fed7ab6735bcacd4a39bccf15 --environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Recorded deployment of google-login-back version f042bc78690b272fed7ab6735bcacd4a39bccf15 to dev environment in the Pact Broker.

~/work/auth0-next-custom$&nbsp;</code></pre> 今度は成功し、コンシューマとプロバイダの両方のデプロイバージョンをブローカーに記録できました。record-deploymentした後の"Pact Matrix" (コンシューマ x プロバイダのバージョン一覧表) は以下のようになりました。緑タグでデプロイ環境が示されていますね。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/946b7d6e38b94d2aaef7267c5e5d3b9f/Pasted%20image%2020241002223539.png" alt="">

record-deployment

それでは試しに、ローカル環境でcan-i-deployを実行してみましょう。 <pre><code># コンシューマ

~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant auth0-next-custom --version 445fec738b5a4761bda6379ca37286062d079401 --to-environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Computer says yes \o/&nbsp;

CONSUMER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| C.VERSION&nbsp;| PROVIDER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| P.VERSION&nbsp;| SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | 445fec7... | google-login-back | f042bc7... | true&nbsp;&nbsp;&nbsp;| 1&nbsp;&nbsp;&nbsp;&nbsp;

VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/611750a58c1c1b4697e602671bf23021bbe60df7/metadata/Y3ZuPTQ0NWZlYzczOGI1YTQ3NjFiZGE2Mzc5Y2EzNzI4NjA2MmQwNzk0MDE/verification-results/319 (success)

All required verification results are published and successful
~/work/auth0-next-custom$&nbsp;

# プロバイダ

~/work/auth0-next-custom$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant google-login-back --version f042bc78690b272fed7ab6735bcacd4a39bccf15 --to-environment dev --broker-base-url http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com --broker-username xxxxxxxxxxxx --broker-password xxxxxxxxxxxx

Computer says yes \o/&nbsp;

CONSUMER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| C.VERSION&nbsp;| PROVIDER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| P.VERSION&nbsp;| SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | 445fec7... | google-login-back | f042bc7... | true&nbsp;&nbsp;&nbsp;| 1&nbsp;&nbsp;&nbsp;&nbsp;

VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/611750a58c1c1b4697e602671bf23021bbe60df7/metadata/Y3ZuPTQ0NWZlYzczOGI1YTQ3NjFiZGE2Mzc5Y2EzNzI4NjA2MmQwNzk0MDE/verification-results/319 (success)

All required verification results are published and successful
~/work/auth0-next-custom$&nbsp;</code></pre> コンシューマ・プロバイダのどちらもデプロイバージョンに対して検証が成功していることが確認できました。 それではいよいよ、can-i-deployをCI/CDに組み込みましょうと言いたいところですが、ここで少しThinking Timeを挟みました。というのも、プロバイダのパイプラインにcan-i-deployを組み込む意味があるのか？という疑問が生じたためです。結論としては、プロバイダのパイプラインにも組み込む必要があるとの思いに至りました。理由としては、以下の2点が挙げられます。 理由の1つ目：現状プロバイダのパイプラインで契約の検証を行っていますが、それは常に最新の契約に対して行っており、現在のコンシューマのデプロイバージョンに対してではありません。ということは、コンシューマのデプロイバージョンの契約をプロバイダが満たしていなかったが、契約が更新され、最新の契約をプロバイダが満たすようになった場合、現状のテストは成功するため、契約をサポートしていないプロバイダがデプロイされてしまいます。 理由の2つ目：そもそも、マイクロサービスにおいて特定のサービスがプロバイダとしてしか振る舞わないという保証はない気がします。例えば、投稿バックエンドサービスは投稿フロントエンドのプロバイダですが、投稿バックエンドサービスからメール通知サービスを呼び出す場合、同サービスはコンシューマとしても振る舞います。現状役割がプロバイダだけだったとしても、将来的にコンシューマになる可能性を残しておいたほうがいいと考えます。そうなってくると、プロバイダもコンシューマと同じフローにしておいたほうが良さそうです。

ローカル環境でcan-i-deployしてみる

それではいよいよ、can-i-deployをCI/CDに組み込みましょう。デプロイ前にcan-i-deployするだけでなく、デプロイ後にrecord-deploymentするのもお忘れなく。デプロイ環境はCodeBuildで指定した環境変数で動的に切り替わるようにしておきます。 コンシューマ<pre><code>diff --git a/app/api/microposts/service.ts b/app/api/microposts/service.ts
index 6bf857f..e94b165 100644
--- a/app/api/microposts/service.ts
+++ b/app/api/microposts/service.ts
@@ -1,5 +1,4 @@
&nbsp;import axios from "axios";
-import { NextRequest } from "next/server";
&nbsp;
&nbsp;export default function MicropostService(baseUrl: string) {
&nbsp; &nbsp;const ping = async (): Promise&lt;{message: string}&gt; =&gt; {
diff --git a/buildspec.yml b/buildspec.yml
index 7d35759..71b2f6b 100644
--- a/buildspec.yml
+++ b/buildspec.yml
@@ -9,8 +9,10 @@ phases:
&nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp;commands:
&nbsp; &nbsp; - npm run test
-&nbsp; &nbsp;- npm run publish
+&nbsp; &nbsp;- npm run pact:publish
+&nbsp; &nbsp;- npm run pact:can-i-deploy
&nbsp; build:
&nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp;commands:
-&nbsp; &nbsp;- aws amplify start-job --app-id xxxxxxxxxxxx --branch-name main --job-type RELEASE
+&nbsp; &nbsp;- ./deploy.sh
+&nbsp; &nbsp;- npm run pact:record-deployment
diff --git a/deploy.sh b/deploy.sh
new file mode 100755
index 0000000..89ee0a5
--- /dev/null
+++ b/deploy.sh
@@ -0,0 +1,28 @@
+#!/bin/bash -e
+
+# Amplifyアプリのパラメータを設定
+APP_ID="xxxxxxxxxxxx"
+BRANCH_NAME="main"
+JOB_TYPE="RELEASE"
+
+# デプロイジョブを開始
+JOB_ID=$(aws amplify start-job --app-id $APP_ID --branch-name $BRANCH_NAME --job-type $JOB_TYPE --query 'jobSummary.jobId' --output text)
+
+echo "Started job with ID: $JOB_ID"
+
+# ジョブの状態を監視
+while true; do
+ JOB_STATUS=$(aws amplify get-job --app-id $APP_ID --branch-name $BRANCH_NAME --job-id $JOB_ID --query 'job.summary.status' --output text)
+
+ echo "Current job status: $JOB_STATUS"
+
+ if [ "$JOB_STATUS" == "SUCCEED" ]; then
+&nbsp; echo "Job completed successfully"
+&nbsp; break
+ elif [ "$JOB_STATUS" == "FAILED" ]; then
+&nbsp; echo "Job failed"
+&nbsp; exit 1
+ fi
+
+ sleep 10
+done
diff --git a/package.json b/package.json
index e3b09ed..677ada9 100644
--- a/package.json
+++ b/package.json
@@ -8,7 +8,9 @@
&nbsp; &nbsp;"start": "next start",
&nbsp; &nbsp;"lint": "next lint",
&nbsp; &nbsp;"test": "jest",
-&nbsp; "publish": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest publish ${PWD}/pacts --consumer-app-version=$(git rev-parse HEAD) --branch=$(git branch --contains | cut -d ' ' -f 2) --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}"
+&nbsp; "pact:publish": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest publish ${PWD}/pacts --consumer-app-version=$(git rev-parse HEAD) --branch=$(git branch --contains | cut -d ' ' -f 2) --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}",
+&nbsp; "pact:can-i-deploy": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}",
+&nbsp; "pact:record-deployment": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}"
&nbsp; },
&nbsp; "dependencies": {
&nbsp; &nbsp;"@auth0/nextjs-auth0": "^3.5.0",</code></pre> package.jsonとか汚くてすいません。この辺綺麗にするのは今後の課題とさせてください。 注意すべき点は、record-deploymentを行うタイミングです。このパイプラインではamplifyのstart-jobを行うことでデプロイを開始していますが、start-job実行後にそのままrecord-deploymentを行ってしまうと、amplifyのjobが失敗した場合に本来デプロイされていないはずのものがrecord-deploymentされてしまい不整合が生じてしまいます。そのためstart-jobするだけでなく定期的にget-jobにより状態を監視することで、デプロイが成功した場合のみrecord-deploymentを行うことを実現しています。 プロバイダ<pre><code>diff --git a/buildspec.yml b/buildspec.yml
index 68e505c..6f1d138 100644
--- a/buildspec.yml
+++ b/buildspec.yml
@@ -18,12 +18,14 @@ phases:
&nbsp; &nbsp; - sleep 5 # 起動待ち
&nbsp; &nbsp; - docker compose run python ./test.sh
&nbsp; &nbsp; - docker compose stop
+&nbsp; &nbsp;- docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant google-login-back --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
&nbsp; &nbsp; - aws s3 cp s3://xxxxxxxxxxxx/google_login_back/dev.json .chalice/deployed/dev.json || true
&nbsp;
&nbsp; build:
&nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp;commands:
&nbsp; &nbsp; - chalice deploy
+&nbsp; &nbsp;- docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant google-login-back --version $(git rev-parse HEAD) --environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
&nbsp;
&nbsp; post_build:
&nbsp; &nbsp;on-failure: ABORT</code></pre> こちらも汚くてすみません。こちらはコンシューマとは違い同期的にデプロイされるため、そのままrecord-deploymentを行って大丈夫です。

can-i-deployをCI/CDに組み込む

それではパイプラインが実装できたので、実際にいくつかのケースにおいて期待通りの挙動をするか確認してみましょう。まずは、契約の互換性を保った状態でプロバイダを更新してみます。 具体的には、投稿一覧取得APIにおいて各投稿につけられたlike(いいね)の数も取得する、という想定とします。実際にはそもそも投稿保存APIでいいねの数も保存しなければいけないところですが、CI/CDの挙動を確認したいだけなので一旦ランダムな自然数を返します。 現在の投稿一覧取得APIに関する契約は以下です。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/a4bda8a8685b46e18ab17c91cc72ab2b/Pasted%20image%2020241003223938.png" alt="">まだいいねの数に関して契約が更新されていないので、今のところ各投稿はcontentとpostedAtしか含まれないようになっています。現状コンシューマ側でcontentとpostedAtしか使っていなかったとして、プロバイダ側でlikeも返すようになったとしても、コンシューマにしてみれば必要なものはちゃんと返しているので挙動的には問題ないと考えられます。なので、契約の互換性は保たれていると考えました。 それでは、プロバイダ側の修正を行います。<pre><code>diff --git a/app.py b/app.py
index cfc1d9a..a05a689 100644
--- a/app.py
+++ b/app.py
@@ -7,6 +7,7 @@ from datetime import datetime, timedelta, timezone
&nbsp;from chalicelib.models import Microposts
&nbsp;from chalicelib.utils import login
&nbsp;import jwt
+import random
&nbsp;
&nbsp;
&nbsp;app = Chalice(app_name="google_login_back")
@@ -177,7 +178,7 @@ def get_micropost_for_auth0():
&nbsp; &nbsp; &nbsp;return Response(body=None, status_code=401)
&nbsp;
&nbsp; &nbsp;posts = Microposts.query(payload.get("sub"))
-&nbsp; res = [post.to_simple_dict() for post in posts]
+&nbsp; res = [{**post.to_simple_dict(), "like": random.randrange(1000)} for post in posts]
&nbsp; &nbsp;return Response(body=res, status_code=200)</code></pre> ローカルでAPIを実行し動作確認を行います。各投稿にランダムなlikeが振られていることが確認できました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/307c8275ae954ac68243432ea5b38675/Pasted%20image%2020241005172459.png" alt=""> プッシュ前のPact Matrixは以下です。これがプッシュ後はどのように変わるでしょうか。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e8741356a1424a859a29741a1d30d9a3/Pasted%20image%2020241003224105.png" alt=""> プッシュ後<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/65df48d337d34c879c43e4e2d058216a/Pasted%20image%2020241003224649.png" alt=""> 無事デプロイが成功し、プロバイダのdev環境タグが最新のコミットのバージョンに移動しました。プロバイダのCI/CDが通ったことで、契約はちゃんと守られているとPactが判断したことがわかります。

契約の互換性を保った状態でプロバイダを更新する

ひとつ上のセクションでは、契約の互換性を保った状態でプロバイダを更新しました。それの続きで、今度は更新したプロバイダに合った形で契約を更新してみます。 具体的には、投稿一覧取得APIで各投稿にいいねの数を含めるようにしたので、契約もそれに合う形で各投稿にいいねの数を含む形に修正しましょう。結果はどうなると思いますか？もちろん、テストが成功し正常にデプロイされると思いますよね？それでは、実際にやってみます。<pre><code>diff --git a/app/api/microposts/service.ts b/app/api/microposts/service.ts
index e94b165..a1bac9f 100644
--- a/app/api/microposts/service.ts
+++ b/app/api/microposts/service.ts
@@ -10,7 +10,7 @@ export default function MicropostService(baseUrl: string) {
&nbsp; &nbsp; &nbsp;return res.json();
&nbsp; &nbsp;}
&nbsp;
-&nbsp; const getAll = async (accessToken: string|undefined): Promise&lt;Array&lt;{content: string, postedAt: string}&gt;&gt; =&gt; {
+&nbsp; const getAll = async (accessToken: string|undefined): Promise&lt;Array&lt;{content: string, postedAt: string, like: number}&gt;&gt; =&gt; {
&nbsp; &nbsp; &nbsp;const response = await axios.get(`${baseUrl}/auth0/microposts`, {
&nbsp; &nbsp; &nbsp; &nbsp;headers: {
&nbsp; &nbsp; &nbsp; &nbsp; "Authorization": `Bearer ${accessToken}`,
diff --git a/app/microposts/page.tsx b/app/microposts/page.tsx
index eef1672..f2d9a7e 100644
--- a/app/microposts/page.tsx
+++ b/app/microposts/page.tsx
@@ -10,7 +10,7 @@ import { useUser } from '@auth0/nextjs-auth0/client';
&nbsp;export default withPageAuthRequired(() =&gt; {
&nbsp; const router = useRouter();
&nbsp; const { user, error, isLoading } = useUser();
- const [microposts, setMicroposts] = useState(Array&lt;{content: string, postedAt: string}&gt;);
+ const [microposts, setMicroposts] = useState(Array&lt;{content: string, postedAt: string, like: number}&gt;);
&nbsp; const [content, setContent] = useState("");
&nbsp;
&nbsp; useEffect(() =&gt; {
@@ -46,6 +46,7 @@ export default withPageAuthRequired(() =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;Image className="w-12 h-12 rounded-full mr-2" src={user.picture ?? ''} alt="facePicture" width={600} height={600} /&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;div className="flex-grow"&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;h3 className="m-0 text-lg"&gt;{micropost.content}&lt;/h3&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p className="my-1 text-sm text-gray-700"&gt;{micropost.like} いいね&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{user.name}&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{dayjs(micropost.postedAt).format('YYYY-MM-DD HH:mm:ss')}&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/div&gt;
diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
index 44d123d..0c2d5b9 100644
--- a/tests/api.pact.spec.ts
+++ b/tests/api.pact.spec.ts
@@ -2,7 +2,7 @@ import MicropostService from "@/app/api/microposts/service";
&nbsp;import { MatchersV3, PactV3 } from "@pact-foundation/pact";
&nbsp;import path from "path";
&nbsp;
-const {eachLike, string, regex, timestamp} = MatchersV3;
+const {eachLike, string, integer, timestamp} = MatchersV3;
&nbsp;
&nbsp;const provider = new PactV3({
&nbsp; &nbsp;dir: path.resolve(process.cwd(), 'pacts'),
@@ -50,6 +50,7 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;body: eachLike({
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;content: string('Hello, World.'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;postedAt: timestamp('YYYY-MM-DD HH:mm:ss', '2024-08-21 23:01:01'),
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; like: integer(123)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp;});
@@ -57,9 +58,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp;await provider.executeTest(async (mockserver) =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp;const service = MicropostService(mockserver.url);
&nbsp; &nbsp; &nbsp; &nbsp;const response = await service.getAll('hoge');
-&nbsp; &nbsp; &nbsp; expect(JSON.stringify(response)).toStrictEqual(
-&nbsp; &nbsp; &nbsp; &nbsp; JSON.stringify([{content: 'Hello, World.', postedAt: '2024-08-21 23:01:01'}])
-&nbsp; &nbsp; &nbsp; );
+&nbsp; &nbsp; &nbsp; const {content, postedAt, like} = response[0];
+&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123);
&nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp;});</code></pre> ローカルで実際に画面を開いてみます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/dcb3efb332024901b8daf5ec35097fd8/Pasted%20image%2020241003225411.png" alt="">無事にいいねの数が表示されました。 それではデプロイします。 プッシュ前<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/d8011d117a944e9f8fc91ad1a24b4e37/Pasted%20image%2020241003224649.png" alt=""> プッシュしたところ、パイプラインでエラーが発生しました。<pre><code>&gt; auth0-next-custom@0.1.0 pact:can-i-deploy
&gt; docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}


Computer says no ¯\_(ツ)_/¯


CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|-----------|----------|--------
auth0-next-custom | 87ad0f7... | google-login-back | ???&nbsp; &nbsp; | ???&nbsp; &nbsp;|&nbsp; &nbsp; &nbsp;


There is no verified pact between version 87ad0f757d72fca441573927194c097da1850b9c of auth0-next-custom and the version of google-login-back currently deployed or released to dev (9a796efc330c87c243e62bc44ecbc53d02e21081)


[Container] 2024/10/03 14:08:27.936109 Command did not exit successfully npm run pact:can-i-deploy exit status 1
[Container] 2024/10/03 14:08:27.941294 Phase complete: PRE_BUILD State: FAILED_WITH_ABORT
[Container] 2024/10/03 14:08:27.941316 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: npm run pact:can-i-deploy. Reason: exit status 1</code></pre> プッシュ後のPact Matrixは以下です。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/47f1bd3fad7d4cf8a4daa3a5dec3369e/Pasted%20image%2020241003231110.png" alt=""> 最初は意外でしたが、考えてみたらそりゃそうだわなって話です。我々からしたら、更新後の契約をプロバイダが満たしていることは明らかですが、Pactブローカーからしたら、まだ検証していないので満たしているかどうかはわかりません。なのでやるべきことははっきりしていて、コンシューマ側のCI/CDで契約が更新されたら、更新された契約に対してプロバイダ側の検証を行う必要があります。 Pactのドキュメントを漁っていたら、<a href="https://docs.pact.io/pact_broker/webhooks#example-cicd-and-webhook-configuration" target="_blank" rel="noopener noreferrer">こんな</a>シーケンス図がありました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/6256ea5e83fa45fbb7837394188e79a5/Pasted%20image%2020241003232519.png" alt="">次のタスクとしては上の図のようなフローを実現したいです。

コンシューマ側で互換性を保った形での契約の更新

今やプロバイダ側での契約検証はプロバイダのCI/CDに組み込まれているので、コンシューマ側での契約発行をトリガーにプロバイダのCI/CDを動かせば良いです。 Pactには契約が更新されたことを通知するwebhookがあるみたいですが、APIを呼び出す形なので実現するためにはそのためのリソース(API Gateway, Lambda, IAM Role等々)も作成しなければならず作業量が増えてしまいます。 なので今回は単純にコンシューマ側のパイプラインの中でプロバイダのパイプラインを呼び出す形でできないか検討しました。つまりCodePipelineを外部からトリガーできればよいです。それには以下のAWSコマンドの実行で実現可能です。<pre><code>aws codepipeline start-pipeline-execution --name PIPELINE_NAME</code></pre> めっちゃ簡単ですね。あとはpublishしてからcan-i-deployするまでの間に上記コマンドをcodebuild内で実行するだけです。ちなみに、上記を実行するために必要なポリシーのactionは<code>codepipeline:StartPipelineExecution</code> です。 さて、勘のいい人は気づいたと思いますが、上記はパイプラインを開始するだけなので、単純に上記をコンシューマのパイプラインに組み込むだけでは、can-i-deployは相変わらず失敗します。 ここで朗報です。can-i-deployの<code>--retry-while-unknown</code>オプションで待つことが可能みたいです。<pre><code>[--retry-while-unknown=TIMES]&nbsp;&nbsp;
# The number of times to retry while there is an unknown&nbsp;&nbsp;
verification result (ie. the provider verification is likely&nbsp;&nbsp;
still running)&nbsp;&nbsp;
# Default: 0</code></pre> 検証結果がない場合にリトライしてくれるとのことです。リトライ回数ということなのでプロバイダ側のCI/CDが正しくトリガーされなかったとか、プロバイダ側のCI/CDが異常終了して検証結果が反映されないなどの不具合の場合も無限にリトライし続けるということはないので安心です。リトライ間隔も<code>--retry-interval</code>オプションで指定できるようです。<pre><code>[--retry-interval=SECONDS]&nbsp;&nbsp;
# The time between retries in seconds. Use in conjuction with&nbsp;&nbsp;
--retry-while-unknown&nbsp;&nbsp;
# Default: 10</code></pre> うまく設計されていますね。感心しました。 それでは今回のユースケースにおいて、妥当なパラメータを検討します。今回はプロバイダは1つのみですが、依存するプロバイダが複数の場合もプロバイダのCI/CDは並列で動かすはずなので、遅くても10分には終わるという想定で設定します。また、リトライ間隔は10秒のままとします。そうすると最大リトライ回数は60回という計算になります。（60回リトライしても結果が不明な場合はcan-i-deployの結果を失敗側に倒すということ）

コンシューマのCI/CDからプロバイダのCI/CDを発火する（準備編）

では、実際にコンシューマのパイプラインに適用してみましょう。 まずはポリシーを追加します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e9428553947942c3a6e8048cea191699/Pasted%20image%2020241005152922.png" alt=""> プロバイダのパイプライン名は環境変数 PROVIDER_PIPELINES で管理します。（複数を入れる想定）<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/79a9f00a144f4878838e20b314eff770/Pasted%20image%2020241005153927.png" alt=""> buildspecを修正します。<pre><code>diff --git a/buildspec.yml b/buildspec.yml
index 71b2f6b..41e8996 100644
--- a/buildspec.yml
+++ b/buildspec.yml
@@ -10,6 +10,7 @@ phases:
&nbsp; &nbsp;commands:
&nbsp; &nbsp; - npm run test
&nbsp; &nbsp; - npm run pact:publish
+&nbsp; &nbsp;- ./trigger_pipelines.sh
&nbsp; &nbsp; - npm run pact:can-i-deploy
&nbsp; build:
&nbsp; &nbsp;on-failure: ABORT
diff --git a/package.json b/package.json
index 677ada9..4c7e9ed 100644
--- a/package.json
+++ b/package.json
@@ -9,7 +9,7 @@
&nbsp; &nbsp;"lint": "next lint",
&nbsp; &nbsp;"test": "jest",
&nbsp; &nbsp;"pact:publish": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest publish ${PWD}/pacts --consumer-app-version=$(git rev-parse HEAD) --branch=$(git branch --contains | cut -d ' ' -f 2) --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}",
-&nbsp; "pact:can-i-deploy": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}",
+&nbsp; "pact:can-i-deploy": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --retry-while-unknown 60 --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}",
&nbsp; &nbsp;"pact:record-deployment": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}"
&nbsp; },
&nbsp; "dependencies": {
diff --git a/trigger_pipelines.sh b/trigger_pipelines.sh
new file mode 100755
index 0000000..85c2d54
--- /dev/null
+++ b/trigger_pipelines.sh
@@ -0,0 +1,5 @@
+#!/bin/bash -xe
+
+for pipeline in $PROVIDER_PIPELINES; do
+ aws codepipeline start-pipeline-execution --name $pipeline
+done</code></pre> それでは、pushしてみましょう。CI/CDのログは以下のようになりました。<pre><code>&gt; auth0-next-custom@0.1.0 pact:can-i-deploy
&gt; docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --retry-while-unknown 60 --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
Computer says yes \o/&nbsp;
CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | b160b72... | google-login-back | 9a796ef... | true&nbsp; &nbsp;| 1&nbsp; &nbsp;&nbsp;
VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/cf071c371a83627a39f9642722633bb0330d74a9/metadata/Y3ZuPWIxNjBiNzJiZGVjOWI1NzhhNTFhMTNmYTVmNWVjNjI0N2UzYjRlYmQ/verification-results/330 (success)
All required verification results are published and successful</code></pre> push後のPact Matrixです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ffe84cbaf90044179770c589e5da9d0a/Pasted%20image%2020241005160309.png" alt=""> 更新後の契約に対して無事にプロバイダ側の検証も成功していることが確認できました。

コンシューマのCI/CDからプロバイダのCI/CDを発火する（実践編）

次に、コンシューマ側で互換性を保たない形での契約の更新を行ってみます。 先程は投稿一覧で各投稿にいいねの数を追加しましたが、今回は同じノリでお気に入り数を追加してみます。ですが前回とは違い、先にコンシューマ側で契約を更新し実装を修正してしまいます。 コンシューマの修正差分は以下です。<pre><code>diff --git a/app/api/microposts/service.ts b/app/api/microposts/service.ts
index a1bac9f..9db8c68 100644
--- a/app/api/microposts/service.ts
+++ b/app/api/microposts/service.ts
@@ -10,7 +10,7 @@ export default function MicropostService(baseUrl: string) {
&nbsp; &nbsp; &nbsp;return res.json();
&nbsp; &nbsp;}
&nbsp;
-&nbsp; const getAll = async (accessToken: string|undefined): Promise&lt;Array&lt;{content: string, postedAt: string, like: number}&gt;&gt; =&gt; {
+&nbsp; const getAll = async (accessToken: string|undefined): Promise&lt;Array&lt;{content: string, postedAt: string, like: number, favorite: number}&gt;&gt; =&gt; {
&nbsp; &nbsp; &nbsp;const response = await axios.get(`${baseUrl}/auth0/microposts`, {
&nbsp; &nbsp; &nbsp; &nbsp;headers: {
&nbsp; &nbsp; &nbsp; &nbsp; "Authorization": `Bearer ${accessToken}`,
diff --git a/app/microposts/page.tsx b/app/microposts/page.tsx
index f2d9a7e..b16a5b5 100644
--- a/app/microposts/page.tsx
+++ b/app/microposts/page.tsx
@@ -10,7 +10,7 @@ import { useUser } from '@auth0/nextjs-auth0/client';
&nbsp;export default withPageAuthRequired(() =&gt; {
&nbsp; const router = useRouter();
&nbsp; const { user, error, isLoading } = useUser();
- const [microposts, setMicroposts] = useState(Array&lt;{content: string, postedAt: string, like: number}&gt;);
+ const [microposts, setMicroposts] = useState(Array&lt;{content: string, postedAt: string, like: number, favorite: number}&gt;);
&nbsp; const [content, setContent] = useState("");
&nbsp;
&nbsp; useEffect(() =&gt; {
@@ -47,6 +47,7 @@ export default withPageAuthRequired(() =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;div className="flex-grow"&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;h3 className="m-0 text-lg"&gt;{micropost.content}&lt;/h3&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{micropost.like} いいね&lt;/p&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;p className="my-1 text-sm text-gray-700"&gt;{micropost.favorite} お気に入り&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{user.name}&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;p className="my-1 text-sm text-gray-700"&gt;{dayjs(micropost.postedAt).format('YYYY-MM-DD HH:mm:ss')}&lt;/p&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&lt;/div&gt;
diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
index 0c2d5b9..ea14748 100644
--- a/tests/api.pact.spec.ts
+++ b/tests/api.pact.spec.ts
@@ -50,7 +50,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;body: eachLike({
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;content: string('Hello, World.'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;postedAt: timestamp('YYYY-MM-DD HH:mm:ss', '2024-08-21 23:01:01'),
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; like: integer(123)
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; like: integer(123),
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; favorite: integer(456),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp;});
@@ -58,8 +59,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp;await provider.executeTest(async (mockserver) =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp;const service = MicropostService(mockserver.url);
&nbsp; &nbsp; &nbsp; &nbsp;const response = await service.getAll('hoge');
-&nbsp; &nbsp; &nbsp; const {content, postedAt, like} = response[0];
-&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123);
+&nbsp; &nbsp; &nbsp; const {content, postedAt, like, favorite} = response[0];
+&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123 &amp;&amp; favorite == 456);
&nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp;});</code></pre> ローカルで動作確認します。まだプロバイダ側が対応していないのでお気に入り数は表示されません。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/00d68dafe32e41b89da9c6b05cbe4f33/Pasted%20image%2020241005162202.png" alt=""> さて、pushしたのですがCI/CDで<a href="https://fu3ak1.hatenablog.com/entry/2020/11/22/122241" target="_blank" rel="noopener noreferrer">docker pullのLate Limit問題</a>で落ちまくるので急遽対応しました。（今までも実は落ちていたのですが、数回再実行すれば通っていたのでそのままにしていたのです）<code>docker login</code>するようbuildspecを更新し、<code>DOCKER_USER</code>, <code>DOCKER_TOKEN</code>環境変数を追加しました。 気を取り直して再度pushし、コンシューマ側のパイプラインが動き出しました。上で述べているように、コンシューマ側のパイプラインが動くとそれに伴ってプロバイダ側のパイプラインも動き出します。 プロバイダ側のパイプラインでエラーになりました。プロバイダ側でエラーになるとコンシューマ側も契約の検証ができないためパイプラインが失敗しデプロイは行われません。エラー内容は以下です。<pre><code>=================================== FAILURES ===================================
_ test_pacts[auth0-next-custom with request '\u30e6\u30fc\u30b6\u306e\u5168\u3066\u306e\u6295\u7a3f\u3092\u30ea\u30af\u30a8\u30b9\u30c8\u3059\u308b'1] _
Pact failure details:
Response element 'favorite' is missing at body[0]</code></pre> 各投稿にfavoriteがないので契約は満たされないという結果です。完全に予想通りです。その時のPact Matrixは以下です。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/81eb5a43eaa94235a1957473fde4d51b/Pasted%20image%2020241005170324.png" alt=""> では、今度は検証を成功させるべく、プロバイダ側を修正しましょう。差分は以下です。<pre><code>diff --git a/app.py b/app.py
index a05a689..c2987e5 100644
--- a/app.py
+++ b/app.py
@@ -178,7 +178,9 @@ def get_micropost_for_auth0():
&nbsp; &nbsp; &nbsp;return Response(body=None, status_code=401)
&nbsp;
&nbsp; &nbsp;posts = Microposts.query(payload.get("sub"))
-&nbsp; res = [{**post.to_simple_dict(), "like": random.randrange(1000)} for post in posts]
+&nbsp; res = [
+&nbsp; &nbsp; {**post.to_simple_dict(), "like": random.randrange(1000), "favorite": random.randrange(1000)} for post in posts
+&nbsp; ]
&nbsp; &nbsp;return Response(body=res, status_code=200)</code></pre> ローカルで動作確認します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/8d83101ca1ea4149a8974c2fb1d88d66/Pasted%20image%2020241005172948.png" alt=""> 問題なさそうなので、pushします。<pre><code>Computer says no ¯\_(&lt;span class='ace_cjk'&gt;ツ&lt;/span&gt;)_/¯
CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|-----------|----------|--------
auth0-next-custom | b160b72... | google-login-back | ???&nbsp; &nbsp; | ???&nbsp; &nbsp;|&nbsp; &nbsp; &nbsp;
There is no verified pact between the version of auth0-next-custom currently deployed or released to dev (b160b72bdec9b578a51a13fa5f5ec6247e3b4ebd) and version 3b301dd771efeba855e6983d8723033e9f047ef0 of google-login-back
[Container] 2024/10/05 08:31:43.951369 Command did not exit successfully docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant google-login-back --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD} exit status 1</code></pre> あれ、おかしいですね。can-i-deployで失敗しました。その時のPact Matrixです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/2465a62efe7c40d88dfdefe54d3ffcf9/Pasted%20image%2020241005173744.png" alt=""> 以下の表だとわかりやすいでしょうか。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/3ea9593a8c4040c2be69486db66df5af/image.png" alt="">新しい契約を満たすようになったプロバイダバージョンにおけるcan-i-deployでは、上記の真ん中の組み合わせの検証結果がほしいです。ポイントとしては、あくまで最新の契約ではなく、コンシューマのデプロイバージョンにおける契約に対して満たしているかを確認する必要があるということです。しかし、プロバイダのパイプラインで検証しているのは最新の契約のみなので、上記の表の通り旧契約に対しては未検証という結果になり、プロバイダのパイプラインが失敗します。 では、どうしたらいいのでしょうか？ ボツ案：コンシューマの新契約バージョン＝devデプロイバージョンになれば成功するので、コンシューマ側のパイプラインをもう一度手動で回せばいいのでは？と思いましたが、そうするとcan-i-deployでコンシューマの新契約バージョン×プロバイダのdevデプロイバージョンの組み合わせで検証結果を確認しようとしますがその組み合わせの検証結果は存在しないため成功しませんでした。コンシューマ側のパイプラインから発火するプロバイダ側のパイプラインでは、コンシューマの新契約バージョン×プロバイダの最新バージョンに対して検証が行われるため、求めている検証結果が得られません。 解決策：一旦契約をロールバックします。そうすることで今度は先にプロバイダが契約の互換性を保った状態で機能追加した状態になるので、成功するはずです。

コンシューマ側で互換性を保たない形での契約の更新

流れとしてはまず、コンシューマ側でfavoriteが追加されていない旧契約状態のものに直します。この時点でプロバイダ側はfavorite対応を行っていますが互換性があるためテストは成功します。またプロバイダ側のcan-i-deployもコンシューマ：旧契約バージョン(devデプロイバージョン)×プロバイダ：最新バージョンの検証が通っているため成功し、最新バージョンでデプロイされます。コンシューマ側のcan-i-deployも以下の理屈により成功します。コンシューマ：最新バージョン×プロバイダ：devデプロイバージョンで検証されますが、コンシューマ側のバージョンについて最新バージョン＝旧契約バージョン＝devデプロイバージョンが成り立つため、結果としてコンシューマ：devデプロイバージョン×プロバイダ：devデプロイバージョンの検証となり、これは（デプロイされている時点で当然ですが）既に検証済みです。 では、順を追って見ていきましょう。 まずはコンシューマ側の修正差分です。<pre><code>diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
index ea14748..720bb43 100644
--- a/tests/api.pact.spec.ts
+++ b/tests/api.pact.spec.ts
@@ -51,7 +51,6 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;content: string('Hello, World.'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;postedAt: timestamp('YYYY-MM-DD HH:mm:ss', '2024-08-21 23:01:01'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;like: integer(123),
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; favorite: integer(456),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp;});
@@ -59,8 +58,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp;await provider.executeTest(async (mockserver) =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp;const service = MicropostService(mockserver.url);
&nbsp; &nbsp; &nbsp; &nbsp;const response = await service.getAll('hoge');
-&nbsp; &nbsp; &nbsp; const {content, postedAt, like, favorite} = response[0];
-&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123 &amp;&amp; favorite == 456);
+&nbsp; &nbsp; &nbsp; const {content, postedAt, like} = response[0];
+&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123);
&nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp;});</code></pre> 修正できたのでpushします。コンシューマ側のパイプラインです。<pre><code>&gt; docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --retry-while-unknown 60 --pacticipant auth0-next-custom --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
Computer says yes \o/&nbsp;
CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | 5b9b833... | google-login-back | 9a796ef... | true&nbsp; &nbsp;| 1&nbsp; &nbsp;&nbsp;
VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/cf071c371a83627a39f9642722633bb0330d74a9/metadata/Y3ZuPTViOWI4MzM4N2FiODdjZjFmMzQ2MGZhNjk3ZTVhZDBlMWIwOTE4MjA/verification-results/331 (success)
All required verification results are published and successful</code></pre> 続いて、プロバイダ側のパイプラインです。<pre><code>Computer says yes \o/&nbsp;
CONSUMER&nbsp; &nbsp; &nbsp;| C.VERSION | PROVIDER&nbsp; &nbsp; &nbsp;| P.VERSION | SUCCESS? | RESULT#
------------------|------------|-------------------|------------|----------|--------
auth0-next-custom | b160b72... | google-login-back | 3b301dd... | true&nbsp; &nbsp;| 1&nbsp; &nbsp;&nbsp;
VERIFICATION RESULTS
--------------------
1. http://xxxxxxxxxxxx.ap-northeast-1.compute.amazonaws.com/pacts/provider/google-login-back/consumer/auth0-next-custom/pact-version/cf071c371a83627a39f9642722633bb0330d74a9/metadata/Y3ZuPWIxNjBiNzJiZGVjOWI1NzhhNTFhMTNmYTVmNWVjNjI0N2UzYjRlYmQ/verification-results/335 (success)
All required verification results are published and successful</code></pre> パイプライン実行後のPact Matrixです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e357f25b10dd4bbe94ef0d9ddc666139/Pasted%20image%2020241005182712.png" alt=""> どちらも無事に最新バージョンがデプロイされました。ここまでくれば、あとはロールバックしていた契約を元に戻すだけです。 コンシューマ側の修正(ロールバックコミットのrevert)：<pre><code>diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
index 720bb43..ea14748 100644
--- a/tests/api.pact.spec.ts
+++ b/tests/api.pact.spec.ts
@@ -51,6 +51,7 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;content: string('Hello, World.'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;postedAt: timestamp('YYYY-MM-DD HH:mm:ss', '2024-08-21 23:01:01'),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;like: integer(123),
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; favorite: integer(456),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp;});
@@ -58,8 +59,8 @@ describe('GET /auth0/microposts', () =&gt; {
&nbsp; &nbsp; &nbsp;await provider.executeTest(async (mockserver) =&gt; {
&nbsp; &nbsp; &nbsp; &nbsp;const service = MicropostService(mockserver.url);
&nbsp; &nbsp; &nbsp; &nbsp;const response = await service.getAll('hoge');
-&nbsp; &nbsp; &nbsp; const {content, postedAt, like} = response[0];
-&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123);
+&nbsp; &nbsp; &nbsp; const {content, postedAt, like, favorite} = response[0];
+&nbsp; &nbsp; &nbsp; expect(content == 'Hello, World.' &amp;&amp; postedAt == '2024-08-21 23:01:01' &amp;&amp; like == 123 &amp;&amp; favorite == 456);
&nbsp; &nbsp; &nbsp;})
&nbsp; &nbsp;});</code></pre> pushします。 Pact Matrix：<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/cffc7271cd2c49deab4170283b207477/Pasted%20image%2020241005184248.png" alt=""> 無事に契約バージョンが最新に更新されました。

契約をロールバックする

今回は、Pactのcan-i-deployを試してみました。契約を更新するフローとしては、<ul><li>古い契約の互換性を保ったまま先にプロバイダを更新し、後から契約を更新する</li><li>先に契約を更新し、後からプロバイダを更新する</li></ul>の2パターンを試してみました。後者の場合、今のパイプラインの実装だと、<ol><li>コンシューマ側の新契約バージョンをpush<ol><li>コンシューマ側のPactテストが成功</li><li>コンシューマ側のパイプライン上のcan-i-deployのためプロバイダ側のパイプラインが発火</li><li>プロバイダ側のPactテストが失敗（新契約に未対応のため）</li><li>コンシューマ側のパイプラインも失敗</li></ol></li><li>プロバイダ側の新契約対応バージョンをpush<ol><li>プロバイダ側のPactテスト【コンシューマ：最新バージョン（新契約バージョン）×プロバイダ：最新バージョン】が成功</li><li>プロバイダ側のパイプライン上のcan-i-deployが失敗（【コンシューマ：デプロイバージョン（旧契約バージョン）×プロバイダ：最新バージョン】の組み合わせの検証結果が存在しないため）</li><li>プロバイダ側のパイプラインが失敗</li></ol></li></ol>となり積んだ状態になってしまいます。今回は契約をロールバックする形で対応しましたが、手動で【コンシューマ：デプロイバージョン（旧契約バージョン）×プロバイダ：最新バージョン】の組み合わせの検証を行う方法もありそうです。もしくは、最初からプロバイダ側のcan-i-deployをする前に上記の検証も行うようパイプラインを組むという手もあるかもしれません。

まとめ

実用的には、「コンシューマの契約を更新する際にうっかり互換性のない修正を行ってしまった」というケースがありそうです。特に、依存するプロバイダが1個だけならまだ大丈夫かもしれませんが、数が多くなってくると段々それぞれのプロバイダの状態がどうなっているか管理するのが困難になってくると思われます。そういうときこそ、can-i-deployが威力を発揮するのではないでしょうか。そうなってくると、まとめの最後に述べた、「プロバイダ側のcan-i-deployをする前に【コンシューマ：デプロイバージョン×プロバイダ：最新バージョン】の組み合わせの検証を行うようパイプラインを組む」というのは対応したほうがいいと思います。今回はそこまでは対応しませんでしたが、それでもcan-i-deployの便利さはかなり感じました。ここまでやって初めて、Pactを導入する旨味が出てくる気がします。マイクロサービスにおいて、複数サービスを同時にデプロイしなくても、パイプラインを回すだけで検証ができ、安全でないものはデプロイされない仕組みができるというのは素晴らしいと思いました。

感想

参考までに今回の対応で修正したbuildspecの最終的なファイルの中身を添付します。 コンシューマ：<pre><code>version: 0.2

phases:
 install:
 on-failure: ABORT
 commands:
 - npm ci
 pre_build:
 on-failure: ABORT
 commands:
 - echo $DOCKER_TOKEN | docker login -u $DOCKER_USER --password-stdin
 - npm run test
 - npm run pact:publish
 - ./trigger_pipelines.sh
 - npm run pact:can-i-deploy
 build:
 on-failure: ABORT
 commands:
 - ./deploy.sh
 - npm run pact:record-deployment</code></pre> プロバイダ：<pre><code>version: 0.2

phases:
 install:
 on-failure: ABORT
 commands:
 - pip install -r requirements.txt

 pre_build:
 on-failure: ABORT
 commands:
 - TEMP_ROLE=$(aws sts assume-role --role-arn $ASSUME_ROLE_ARN --role-session-name xxxx)
 - export AWS_ACCESS_KEY_ID=$(echo "${TEMP_ROLE}" | jq -r '.Credentials.AccessKeyId')
 - export AWS_SECRET_ACCESS_KEY=$(echo "${TEMP_ROLE}" | jq -r '.Credentials.SecretAccessKey')
 - export AWS_SESSION_TOKEN=$(echo "${TEMP_ROLE}" | jq -r '.Credentials.SessionToken')
 - echo $DOCKER_TOKEN | docker login -u $DOCKER_USER --password-stdin
 - docker compose up dynamo-test -d
 - chmod 777 dynamodb-test/
 - sleep 5 # 起動待ち
 - docker compose run python ./test.sh
 - docker compose stop
 - docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker can-i-deploy --pacticipant google-login-back --version $(git rev-parse HEAD) --to-environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
 - aws s3 cp s3://xxxxx/google_login_back/dev.json .chalice/deployed/dev.json || true

 build:
 on-failure: ABORT
 commands:
 - chalice deploy
 - docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest pact-broker record-deployment --pacticipant google-login-back --version $(git rev-parse HEAD) --environment ${ENV} --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}

 post_build:
 on-failure: ABORT
 commands:
 - aws s3 cp .chalice/deployed/dev.json s3://xxxxx/google_login_back/dev.json
 - python create_table.py</code></pre>

付録：buildspecの最終形態

さいごに

コンシューマ駆動契約テストに入門してみた〜can-i-deploy編〜

まずは認可の問題です。このシステムではユーザが投稿リクエストを送る権限があるかどうかとユーザの特定をアクセストークンを使って行っています。認証・認可にはAuth0を使っており、ユーザがログインしたタイミングで取得したアクセストークンをバックエンドに送信しています。 Pactの契約を作る際、リクエスト内容と対応するレスポンスを定義しますが、リクエスト内容のAuthorizationヘッダにAuth0から取得したアクセストークンを書き込んだとしても、アクセストークンには有効期限があります。有効期限が切れた途端に失敗しかしなくなるテストコードになってしまいます。対処法として以下の2パターンを考えました。投稿APIのプロバイダ側の契約テストで必要になるアクセストークンの問題の対処法：<ol><li>リクエストヘッダをバックエンド側で上書きする<ol><li><a href="https://github.com/reecetech/pactman/tree/master?tab=readme-ov-file#verifying-pacts-using-pytest" target="_blank" rel="noopener noreferrer">pactman</a>の場合は<code>pact_verifier.verify</code>の第3引数に辞書形式で追加のリクエストヘッダを指定できるようです。</li><li>ただしこのやり方だと逆に常に認証が成功してしまい、認証失敗するケースをテストできなくなってしまいます。</li></ol></li><li>認証コンポーネントをモック化する<ol><li>モック化する場合、認証のロジックを別で担保するのかどうかを検討する必要があります。</li><li>実行中のAPIの内部状態を変更する必要があります。</li></ol></li></ol>どちらのパターンにおいてもデメリットがありました。（1のリクエストヘッダ上書きの方は、ケースごとに上書きするヘッダを指定できたらいいのにな・・・と思います） 次に対処法2のデメリットである、実行中のAPIの内部状態を変更する方法について検討しました。 django（公式ドキュメントの例）の場合<a href="https://github.com/reecetech/pactman/tree/master?tab=readme-ov-file#verifying-pacts-using-pytest" target="_blank" rel="noopener noreferrer">pactmanのドキュメント</a>では、djangoの場合の<code>live_server</code> pytest fixtureを使った例が書いてあります。自分はdjangoは全くの未経験ですが、軽く調べたところによるとlive_serverはテストとは異なるスレッドで実行されるようです。今回のように内部状態を変えたい場合はどうやって対応するんだろうと思ってもう少し調べてみたら、<code>transactional_db</code> fixtureに依存することで、DBの内容を操作できるようになっているようです。（その内部実装がどうなっているかまでは追えていません・・・） Chalice（今回のプロジェクト）の場合<a href="https://aws.github.io/chalice/topics/testing.html#rest-apis" target="_blank" rel="noopener noreferrer">テスト用のClient</a>があるようです。こちらは先程のlive_serverとは異なり、実際にサーバを起動するのではなく、あくまでクライアントのモックとしてリクエストに対するレスポンスを返してくれるみたいです。なので同じプロセスになるので、モンキーパッチなどで外部からデータを書き換えるのは簡単そうです。しかし、pactmanの公式がlive_serverを例として出していることからも想像できるように、pactmanは別プロセスとして実際に動くAPIを前提とした実装になっています。 pact_verifierの実装を少し深堀したところ、単純に<a href="https://github.com/reecetech/pactman/blob/master/pactman/verifier/verify.py#L75" target="_blank" rel="noopener noreferrer">内部でrequestsの関数を呼び出しているだけ</a>でした。したがって、もしChalice提供のテスト用Clientを使うのであれば、requestsのget関数を呼び出した際にテスト用Clientのgetが呼ばれる、みたいにうまく噛み合うようなパッチを手探りで作っていかなければなりません。 自分は少しだけ試してみましたが無理そうだったのでテスト用Clientは使わないことにしました。そうなると、テスト用Clientではなく実際に<code>chalice local</code>でサーバを起動するやり方になります。そうすると、別プロセスで動いているChaliceプログラムの内部状態を変えなければいけないという難しい問題に直面しなければならず、こちらもかなり厄介な実装になりそうだったので、アクセストークン問題の対処法2は断念し、1で対応する方針に切り替えました。 対処法1のデメリットとしては認証失敗ケースのテストができないというのがありますが、今回は別で（手動テストなどで）担保するので問題ないとしました。（というより、それしか現実的な方法がないのですが）

トークンの有効期限問題

さて、少し話が本題とそれてしまいますが、リクエストヘッダを上書きするとして、そのアクセストークンはどうやって取得すればいいでしょうか？何を言っているんだと思われるかもしれませんが、今回プロデューサ側のテストを考えています。つまり、アクセストークンは送られてくるわけではなく、プロデューサ自身の側で生成しなければいけません。今回は投稿権限を持ったテスト用のユーザをAuth0側に実際に作成し、（画面はないので）OAuth2.0のリソースオーナーパスワードフローを使って直接トークンを取得する形にしました。パスワードフローを使うにあたって色々と設定などが必要だったのですが、そのあたりの話は完全に脱線してしまうのでここでは省略します。

アクセストークンの取得方法

アクセストークンが無事に取得できたとき、また別の壁が立ちはだかりました。<code>pact_verifier.verify</code>の第3引数に設定する<code>extra_provider_headers</code>は、（なんと）<a href="https://github.com/reecetech/pactman/blob/master/pactman/verifier/verify.py#L198" target="_blank" rel="noopener noreferrer">pactに記載の内容で上書きされてしまいます</a>。つまりどういうことかというと、コンシューマ側で契約を定義しますが、その際にAuthorizationヘッダに<code>"Bearer hoge"</code>と設定していたとすると、<code>extra_provider_headers</code>を指定していたとしても<code>"Bearer hoge"</code>の方が勝ってしまうということです。更に悪いことに、<code>extra_provider_headers</code>は<code>@property</code>で「保護されている」ため、パッチするのも困難になってしまっています。自分の場合は仕方なく、契約にはAuthorizationヘッダを含めないようにしました。実際と異なる契約になってしまうため、できればやりたくなかったのですが。自分の理解が及んでいないだけかもしれませんが、契約側よりプロバイダ側の注入の方が勝つようにしてほしいです・・・pactmanの今後の改修に期待したいです。 ようやくアクセストークンを正しく設定できるようになったところで、別のエラーになりました。ユーザが自身の投稿の一覧を取得するAPIの検証結果です：<pre><code>Failed: body size 0 is smaller than minimum size 1 at body</code></pre> ただここまでくれば勝ったも同然ですね。今はユーザの投稿を1件も保存していない状態なので、想定通りのエラーです。

pactmanのextra_provider_headersが上書きされる問題

認可の問題

さてようやくDBについてどうするかを考えるタイミングが来ました。APIは別プロセスで<code>chalice local</code>で動いているので、現状DBもモックではなく本物（といってもDynamoDB localですが）に繋がっています。まずDBにモックを使わないのは妥当かどうかですが、このDBは内部システムとみなせるため、実物を使用すべしという結論になります。このあたりは<a href="https://build.yoku.co.jp/articles/rfycv5cu04_p#section_4_subsection_1" target="_blank" rel="noopener noreferrer">以前の投稿</a>をご参照ください。次に、DBのコンテナについて考えます。現状はローカル開発環境用のDBにchaliceが接続してしまっていますが、ローカル開発環境用とは切り離したいです。そこで単純にテスト用のdockerコンテナを別途作成し、chaliceのstageに紐づく環境変数を（<code>.chalice/config.json</code>で）切り分けることで、ローカル開発環境chaliceとテスト用chaliceで別々のDBコンテナを見に行くようにしました。

接続先DBの検討

上に述べたような試行錯誤の末ようやくローカルで投稿APIのプロバイダ側のテストが通るようになりました。CodeBuild環境でもテストを通したいのですが、今のままだと通りません。それは、ローカルではpythonコンテナ上でテストを実行していますが、CodeBuild環境では現状localhostで直接テストを実行しているためです。もし現状のままlocalhostで実行するのであれば、DBコンテナに接続するためにはDBコンテナをポートフォワーディングし、対象ポートに接続する必要があります。接続先は環境変数で切り替えればいいのでそこまで難易度は高くありませんが、今後も開発を進めていく中でローカル環境とCodeBuild環境の環境差異が原因でテストが通らなくなることがありそうです。手元の環境でないと中々デバッグもし辛いですし、できればこの際ローカルと同じようにCodeBuild環境でもDocker上でテストを実行するようにしたいです。

CI/CD環境をどうするか

CodeBuild環境でもDocker上でテストを実行するようにしたところ、conftest.pyのboto3をインスタンス化している箇所でNoRegionErrorが発生しました。これはCodeBuildのAWSプロファイルがコンテナに引き継がれないためです。CodeBuildの場合、認証情報が環境変数に設定されているわけでも~/.aws/配下に保存されているわけでもないようです。したがってCodeBuild環境の認証情報をDockerに引き継ぐ方法はありません。コンテナからawsコマンドを実行するには、コンテナ用のIAMロールを作る必要があります。<a href="https://repost.aws/ja/knowledge-center/codebuild-temporary-credentials-docker" target="_blank" rel="noopener noreferrer">AWS公式</a>にやり方が書いてあります。

CodeBuildでNoRegionError

curlならIP、ホスト名指定共にpythonコンテナからDBコンテナへの接続が成功するのですが、なぜかpynamodb(botocore)経由だとタイムアウトしてしまう現象に相当悩まされました。様々な試行錯誤の末、最終的に最小限の構成で新規プロジェクトをローカルに立ち上げたところ、単純に<a href="https://qiita.com/yuta-katayama-23/items/a8c497fe4a61f29deb34#%E3%81%9D%E3%81%AE2%E3%81%82%E3%82%89%E3%81%8B%E3%81%98%E3%82%81%E6%89%8B%E5%8B%95%E3%81%A7volumes%E3%81%A7%E6%8C%87%E5%AE%9A%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%83%9B%E3%82%B9%E3%83%88%E5%81%B4%E3%81%AE%E3%83%9E%E3%82%A6%E3%83%B3%E3%83%88%E5%85%88%E3%81%AB%E3%81%AA%E3%82%8B%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%82%92%E4%BD%9C%E6%88%90%E3%81%97chmod-777%E3%81%AB%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B" target="_blank" rel="noopener noreferrer">dataディレクトリのパーミッションを変更</a>していなかったことが原因と気づきました。

ローカルだと通るがcodebuildだとDynamoDB-localへの接続がタイムアウトする

投稿APIに対してリクエストを投げた際に、以下のようなエラーが発生しテストが頻繁に失敗するようになりました。<pre><code>E&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=8008): Max retries exceeded with url: /auth0/microposts (Caused by NewConnectionError('&lt;urllib3.connection.HTTPConnection object at 0x727b9434f610&gt;: Failed to establish a new connection: [Errno 111] Connection refused'))</code></pre> DB更新などを行った際にchaliceの監視対象が更新したと判定され、ホットリロードによりchaliceが再起動するようです。そして再起動している間にリクエストが来ると、応答できずにエラーになってしまうものと思われます。そのためchaliceの実行オプションに<a style="color:#ff357f;background-color:#ffffff" href="https://github.com/aws/chalice/issues/1064#issuecomment-461259975" target="_blank" rel="noopener noreferrer"><code>--no-autoreload</code></a>を追加し、リロードされないようにしたところ失敗しなくなりました。

プロバイダ側のテストが不安定に失敗することがある

DBの問題

ユーザの投稿一覧を取得するAPIの契約で、ユーザの投稿が存在する場合としない場合の両方のケースについてプロバイダ側で契約を満たしているか確認する必要があります。このように前提としているプロバイダ側の状態がある場合、どのようにコントロールしたらいいでしょうか？ Pactではもちろんこのようなケースに対応できます。pactmanの場合は<code>pact_verifier.verify</code>の第二引数に<code>provider_state</code>関数を渡してあげることで対応できます。<code>provider_state</code>関数の第一引数のnameに、契約に規定された<code>providerStates[].name</code>が渡ってくるので、そのラベルで分岐することで必要な状態を作成することが可能です。 例えば、今回の例だとユーザの投稿が存在する場合には<code>"ユーザの投稿が存在する場合"</code>という文字列が渡ってくるので、provider_state関数の中で<code>providerStates[].name</code>が<code>"ユーザの投稿が存在する場合"</code>だった場合には事前に投稿APIをPOSTすることで投稿が存在する状態を作っています。<pre><code>def provider_state(token):
 def _provider_state(name, **params):
 if name == "ユーザの投稿が存在する場合":
 requests.post(f"{CHALICE_URL}/auth0/microposts", json={"content": "hello, world"}, headers={'Authorization': f"Bearer {token}"})
 return _provider_state</code></pre> なお、今回はprovider_state関数がtokenを受け取って関数を返す関数になっていますが、これは投稿APIをPOSTする際に<code>token</code> fixtureで生成したトークンを渡す必要があるためです。

プロバイダの状態管理

プロダクションコードapp/api/microposts/service.ts<pre><code>import axios from "axios";

export default function MicropostService(baseUrl: string) {
 const ping = async (): Promise&lt;{message: string}&gt; =&gt; {
 const res = await fetch(`${baseUrl}/ping`, {
 headers: {
 "Content-Type": "application/json",
 }
 });
 return res.json();
 }

 const getAll = async (accessToken: string|undefined): Promise&lt;Array&lt;{content: string, postedAt: string}&gt;&gt; =&gt; {
 const response = await axios.get(`${baseUrl}/auth0/microposts`, {
 headers: {
 "Authorization": `Bearer ${accessToken}`,
 "Content-Type": "application/json",
 }
 });
 return response.data;
 }

 const post = async (accessToken: string|undefined, reqJson: any) =&gt; {
 await axios.post(`${baseUrl}/auth0/microposts`, reqJson, {
 headers: {
 "Authorization": `Bearer ${accessToken}`,
 "Content-Type": "application/json",
 },
 });
 }

 return {ping, getAll, post}
}</code></pre> テストコードtests/api.pact.spec.ts<pre><code>import MicropostService from "@/app/api/microposts/service";
import { MatchersV3, PactV3 } from "@pact-foundation/pact";
import path from "path";

const {eachLike, string, regex, timestamp} = MatchersV3;

const provider = new PactV3({
 dir: path.resolve(process.cwd(), 'pacts'),
 consumer: 'auth0-next-custom',
 provider: 'google-login-back'
});

describe('GET /ping', () =&gt; {
 it('200レスポンス(pong)を返すこと', async () =&gt; {
 provider.addInteraction({
 states: [{description: 'pongレスポンスに成功する場合'}],
 uponReceiving: 'pingリクエストを送信する',
 withRequest: {
 method: 'GET',
 path: '/ping',
 },
 willRespondWith: {
 status: 200,
 headers: {'Content-Type': 'application/json'},
 body: MatchersV3.equal({message: 'pong'}),
 }
 });

 await provider.executeTest(async (mockserver) =&gt; {
 const service = MicropostService(mockserver.url);
 const response = await service.ping();
 expect(response.message).toStrictEqual('pong');
 })
 })
});

describe('GET /auth0/microposts', () =&gt; {
 it('micropostsを返すこと', async () =&gt; {
 provider.addInteraction({
 states: [{description: 'ユーザの投稿が存在する場合'}],
 uponReceiving: 'ユーザの全ての投稿をリクエストする',
 withRequest: {
 method: 'GET',
 path: '/auth0/microposts',
 // 実際はAuthorizationヘッダにBearerトークンを含める必要がある
 },
 willRespondWith: {
 status: 200,
 headers: {'Content-Type': 'application/json'},
 body: eachLike({
 content: string('Hello, World.'),
 postedAt: timestamp('YYYY-MM-DD HH:mm:ss', '2024-08-21 23:01:01'),
 })
 }
 });

 await provider.executeTest(async (mockserver) =&gt; {
 const service = MicropostService(mockserver.url);
 const response = await service.getAll('hoge');
 expect(JSON.stringify(response)).toStrictEqual(
 JSON.stringify([{content: 'Hello, World.', postedAt: '2024-08-21 23:01:01'}])
 );
 })
 });

 it('空配列を返すこと', async () =&gt; {
 provider.addInteraction({
 states: [{description: 'ユーザの投稿が存在しない場合'}],
 uponReceiving: 'ユーザの全ての投稿をリクエストする',
 withRequest: {
 method: 'GET',
 path: '/auth0/microposts',
 // 実際はAuthorizationヘッダにBearerトークンを含める必要がある
 },
 willRespondWith: {
 status: 200,
 headers: {'Content-Type': 'application/json'},
 body: [],
 }
 });

 await provider.executeTest(async (mockserver) =&gt; {
 const service = MicropostService(mockserver.url);
 const response = await service.getAll('hoge');
 expect(response).toStrictEqual([]);
 })
 })
})

describe('POST /auth0/microposts', () =&gt; {
 it('正常レスポンスを返すこと', async () =&gt; {
 provider.addInteraction({
 states: [{description: 'リクエスト内容がcontentを含んでいる場合'}],
 uponReceiving: 'ユーザの投稿を投げる',
 withRequest: {
 method: 'POST',
 path: '/auth0/microposts',
 body: {
 content: string('hello'),
 }
 // 実際はAuthorizationヘッダにBearerトークンを含める必要がある
 },
 willRespondWith: {
 status: 201,
 headers: {'Content-Type': 'application/json'},
 body: null,
 }
 });

 await provider.executeTest(async (mockserver) =&gt; {
 const service = MicropostService(mockserver.url);
 await expect(service.post('hoge', {content: 'world'})).resolves.not.toThrow();
 })
 });


 it('500レスポンスを返すこと', async () =&gt; {
 provider.addInteraction({
 states: [{description: 'リクエスト内容がcontentを含んでいない場合'}],
 uponReceiving: 'ユーザの投稿を投げる',
 withRequest: {
 method: 'POST',
 path: '/auth0/microposts',
 body: {
 greeting: string('hello'),
 }
 // 実際はAuthorizationヘッダにBearerトークンを含める必要がある
 },
 willRespondWith: {
 status: 500,
 headers: {'Content-Type': 'application/json'},
 }
 });

 await provider.executeTest(async (mockserver) =&gt; {
 const service = MicropostService(mockserver.url);
 await expect(service.post('hoge', {greeting: 'world'})).rejects.toThrow('Request failed with status code 500');
 })
 })
})</code></pre>

コンシューマ側

テストコードtests/conftest.py<pre><code>import pytest
import subprocess
import time
import os
from datetime import datetime
import requests
import boto3

ssm = boto3.client("ssm")

AUTH0_CLIENT_ID = ssm.get_parameter(Name="/auth0/client_id")["Parameter"]["Value"]
AUTH0_CLIENT_SECRET = ssm.get_parameter(Name="/auth0/client_secret")["Parameter"]["Value"]
AUTH0_TEST_USER_NAME = ssm.get_parameter(Name="/auth0/test-user01/name")["Parameter"]["Value"]
AUTH0_TEST_USER_PASSWORD = ssm.get_parameter(Name="/auth0/test-user01/password")["Parameter"]["Value"]

STAGE = os.getenv('STAGE')

DB_ENDPOINT = "http://dynamo-test:8000"


@pytest.fixture()
def refresh_table():
 sub_env = os.environ.copy()
 sub_env["DB_ENDPOINT"] = DB_ENDPOINT
 subprocess.run(args=["python", "refresh_table.py"], env=sub_env)
 yield


@pytest.fixture(scope="session", autouse=True)
def start_chalice_local():
 timestamp = datetime.now().strftime("%Y%m%d%H%M%S")
 filename = f"/var/log/{timestamp}.log"

 print(f"stage: {STAGE}")

 with open(filename, "w") as f:
 process = subprocess.Popen(
 ["chalice", "local", "--host=0.0.0.0", f"--port={os.getenv('TEST_PORT')}", f"--stage={STAGE}", "--no-autoreload"],
 stdout=f,
 stderr=subprocess.STDOUT,
 text=True,
 )

 # サービスが完全に起動するまで待機
 time.sleep(5)
 yield
 process.terminate()
 process.wait()

 with open(filename, "r") as f:
 print("\nchalice output:\n", f.read())


@pytest.fixture(scope="session")
def token():
 data = {
 "client_id": AUTH0_CLIENT_ID,
 "client_secret": AUTH0_CLIENT_SECRET,
 "audience": "my-custom-api",
 "username": AUTH0_TEST_USER_NAME,
 "password": AUTH0_TEST_USER_PASSWORD,
 "grant_type": "password",
 }

 res = requests.post("https://dev-XXXXXXXXXXX.us.auth0.com/oauth/token", data)

 yield res.json()["access_token"]


@pytest.fixture(scope="session", autouse=True)
def create_table():
 sub_env = os.environ.copy()
 sub_env["DB_ENDPOINT"] = DB_ENDPOINT
 subprocess.run(args=["python", "create_table.py"], env=sub_env)
 yield</code></pre> tests/test_pacts.py<pre><code>import os
import requests


CHALICE_URL = f"http://localhost:{os.getenv('TEST_PORT')}"


def provider_state(token):
 def _provider_state(name, **params):
 if name == "ユーザの投稿が存在する場合":
 requests.post(f"{CHALICE_URL}/auth0/microposts", json={"content": "hello, world"}, headers={'Authorization': f"Bearer {token}"})
 return _provider_state


def test_pacts(pact_verifier, token, refresh_table):
 pact_verifier.verify(CHALICE_URL, provider_state(token), extra_provider_headers={'Authorization': f"Bearer {token}"})</code></pre>

プロバイダ側

今回行った修正

今回は状態の管理が必要なコンシューマ駆動契約の実装をしてみました。一見簡単そうでしたが実際にやってみるとかなりハマりポイントが存在するなと思いました。扱いづらさの一番の原因はテストとは別のプロセスでAPIサーバやDBサーバを起動する必要があったためではないかなと思います。とはいえコンシューマ・プロバイダの相互作用に関するテストなのである程度致し方ないかなと。 今回実装してみてコンシューマ駆動契約もそれなりにコストがかかることがわかったので、実際のPJで導入するかどうかはコストに見合ったメリットがあるかどうかを慎重に検討した上で判断すべきだと思いました。

コンシューマ駆動契約テストに入門してみた〜状態管理編〜

今回は<a href="https://docs.pact.io/pact_nirvana/step_5" target="_blank" rel="noopener noreferrer">こちら</a>の構成を作成することをゴールとします。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ae228997ae7a4bd4968001c45a18a40e/image.png" alt="">※厳密には上記の構成とは少し異なり、PRパイプラインには組み込みません。コンシューマ・プロバイダ共にデプロイパイプラインに組み込みます。今回実装するのは以下の流れです。 <ol><li>コンシューマ側のパイプライン<ol><li>mainブランチにコミットで発火</li><li>Pactテスト実行</li><li>テストが通ったらBrokerに契約ファイルをpublish</li><li>デプロイ</li></ol></li><li>プロバイダ側のパイプライン<ol><li>mainブランチにコミットで発火</li><li>Brokerから契約ファイルをimport</li><li>Pactテスト実行</li><li>テスト結果をBrokerにpublish</li><li>テストが通ったらデプロイ</li></ol></li></ol>

今回のゴール

前回の記事を読んでいただけたらおわかりのように、コンシューマ側でテストに成功すると契約ファイル（JSON）が作成され、それをプロバイダ側に連携する必要がありました。 そこで前回はローカルで直接ファイルをコピペして置いていましたが、CI/CDに組み込むにはリモートのサーバにファイルを置く必要があります。単にファイルを共有するだけであれば、S3で事足ります。ただ、当然のことながらS3だと本当にファイルを共有することしかできないです。 Pactではコンシューマとプロバイダの間を取り持つBrokerを提供しています。これを使うと、単にJSONを共有するだけでなく、<a href="https://docs.pact.io/pact_broker#why-do-i-need-one" target="_blank" rel="noopener noreferrer">色々便利な使い方</a>ができるようです。なのでせっかくコンシューマ駆動を導入するなら、個人的には積極的にBrokerも使っていきたいです。 Pact BrokerにはRuby製アプリ、Docker、Pact Flow（インフラ込み）の3種類があります。前の2つは自分でホスティングする必要があるので、大きく分類するなら2種類ですね。<a href="https://pactflow.io/pricing/" target="_blank" rel="noopener noreferrer">Pact Flowの料金</a>は無料プランもありますが、制約が色々あり（特に2 integrationsが気になります。2つのサービス間までしか利用できないということでしょうか？）有料プランになると万単位のお金がかかるので、実際に導入するのはなかなかハードルが高いと思います。というわけで今回は、Dockerを自分でホスティングする方向で検討しました。 次にDockerをどこに配置するかですが、個人利用でたまに動かす程度なので今回はシンプルにEC2 on Dockerの構成でグローバルIPを付与して直接外部からアクセスできるようにしました。

Broker

Brokerにpublishする方法(Pact Broker CLI)ですが、Dockerイメージ、Ruby製のスタンドアロン実行可能ファイル、NodeJS製のコマンドがあります。NodeJSであればビルド環境にそのまま組み込めるため楽かなと思ったのですが、CodeBuildで実行したところ以下のように依存関係でエラーが出て解決に時間がかかりそうだったので断念しました。<pre><code>[Container] 2024/07/22 13:29:50.176274 Running command npm run test:publish
&gt; auth0-next-custom@0.1.0 test:publish
&gt; ./node_modules/.bin/pact-broker publish ./pacts --consumer-app-version=$(git rev-parse HEAD) --auto-detect-version-properties --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}
XXXXXXXXXXXXXXXXX/auth0-next-custom/node_modules/@pact-foundation/pact-cli/standalone/linux-x64-2.4.6/pact/lib/ruby/bin.real/ruby: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
[Container] 2024/07/22 13:29:50.529456 Command did not exit successfully npm run test:publish exit status 127
[Container] 2024/07/22 13:29:50.534863 Phase complete: PRE_BUILD State: FAILED_WITH_ABORT
[Container] 2024/07/22 13:29:50.534880 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: npm run test:publish. Reason: exit status 127</code></pre> したがって環境起因の問題が起こりにくいDockerイメージを使うことにしました。 ところで、コンシューマはNextJSアプリであり、Amplifyでホスティングしています。なのでCI/CDもAmplifyで行っていました。そこで問題なのはAmplifyのCI/CDでは<a href="https://zenn.dev/ncdc/articles/f959131cf5f4b5" target="_blank" rel="noopener noreferrer">Dockerを動かすことはできない</a>ようです。調べたところ、AmplifyのCI/CDをトリガーすることは可能なので、<a href="https://qiita.com/eyuta/items/ababeedc051690b4cc15" target="_blank" rel="noopener noreferrer">こちら</a>を参考にCodeBuildから呼び出すようにしました。なお、CodeBuildからDockerを呼び出す場合、<a href="https://zenn.dev/ymiz/articles/0b81d72c66d1e7" target="_blank" rel="noopener noreferrer">特権を付与</a>する必要があるので注意が必要です。 そうすると逆にAmplifyの自動デプロイが邪魔になってくるので、設定をオフにしました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/766e266e9c85438b9e76020cba9d1f1b/Screenshot%20from%202024-07-23%2023-45-14.png" alt=""> あとは、publishする際アプリバージョンを指定する必要がありますが、Gitの<a href="https://docs.pact.io/getting_started/versioning_in_the_pact_broker" target="_blank" rel="noopener noreferrer">コミットハッシュが推奨</a>なのでその場合はCodeBuildからGitコマンドを実行する必要があります。そのためソースステージの出力アーティファクトで完全クローンを選択する必要があるのでご注意ください。また、リポジトリがGitHubを利用している場合は完全クローンするための<a href="https://docs.aws.amazon.com/codepipeline/latest/userguide/troubleshooting.html#codebuild-role-connections" target="_blank" rel="noopener noreferrer">権限</a>をCodeBuildのサービスロールに付与する必要もあります。権限を付与するために必要なConnectionArnはCodePipelineのソースステージの「詳細を表示」から確認できます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/66bcddbabb294227990ab933b6b641c7/Screenshot%20from%202024-07-24%2000-09-05.png" alt=""> コンシューマ側のCI/CDのための修正は以下のようになりました。<pre><code>diff --git a/buildspec.yml b/buildspec.yml
new file mode 100644
index 0000000..7d35759
--- /dev/null
+++ b/buildspec.yml
@@ -0,0 +1,16 @@
+version: 0.2
+
+phases:
+&nbsp; install:
+&nbsp; &nbsp; on-failure: ABORT
+&nbsp; &nbsp; commands:
+&nbsp; &nbsp; &nbsp; - npm ci
+&nbsp; pre_build:
+&nbsp; &nbsp; on-failure: ABORT
+&nbsp; &nbsp; commands:
+&nbsp; &nbsp; &nbsp; - npm run test
+&nbsp; &nbsp; &nbsp; - npm run publish
+&nbsp; build:
+&nbsp; &nbsp; on-failure: ABORT
+&nbsp; &nbsp; commands:
+&nbsp; &nbsp; &nbsp; - aws amplify start-job --app-id XXXXXXXXXX --branch-name main --job-type RELEASE
diff --git a/package.json b/package.json
index 3d79d38..22c0710 100644
--- a/package.json
+++ b/package.json
@@ -6,7 +6,9 @@
&nbsp; &nbsp; &nbsp;"dev": "next dev",
&nbsp; &nbsp; &nbsp;"build": "next build",
&nbsp; &nbsp; &nbsp;"start": "next start",
-&nbsp; &nbsp; "lint": "next lint"
+&nbsp; &nbsp; "lint": "next lint",
+&nbsp; &nbsp; "test": "jest",
+&nbsp; &nbsp; "publish": "docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest publish ${PWD}/pacts --consumer-app-version=$(git rev-parse HEAD) --branch=$(git branch --contains | cut -d ' ' -f 2) --broker-base-url=${PACT_BROKER_BASE_URL} --broker-username ${PACT_BROKER_USERNAME} --broker-password ${PACT_BROKER_PASSWORD}"
&nbsp; &nbsp;},
&nbsp; &nbsp;"dependencies": {
&nbsp; &nbsp; &nbsp;"@auth0/nextjs-auth0": "^3.5.0",</code></pre>

Consumer

Providerはpythonで実装されていてAPI Gateway+Lambda構成でCodeBuildでデプロイしていました。Consumerの方はtestとpublishを別々に実行する必要がありましたが、<a href="https://github.com/reecetech/pactman" target="_blank" rel="noopener noreferrer">pactman</a>の場合はtestの際のオプションの<code>--pact-broker-url</code>でURLを指定することでBrokerから契約ファイルをダウンロードし、<code>--pact-publish-results</code>で結果をアップロードすることが可能です。こちらもコンシューマ同様Gitのコミットハッシュでバージョンを指定する場合はそのための設定が必要になってきます。ですがDockerを使う必要がない分簡単で、CI/CDのための差分は以下のようになりました。<pre><code>diff --git a/buildspec.yml b/buildspec.yml
index 09cffeb..216944e 100644
--- a/buildspec.yml
+++ b/buildspec.yml
@@ -1,15 +1,22 @@
&nbsp;version: 0.2
&nbsp;
&nbsp;phases:
+&nbsp; install:
+&nbsp; &nbsp; on-failure: ABORT
+&nbsp; &nbsp; commands:
+&nbsp; &nbsp; &nbsp; - pip install -r requirements.txt
+
&nbsp; &nbsp;pre_build:
&nbsp; &nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp; &nbsp;commands:
&nbsp; &nbsp; &nbsp; &nbsp;- aws s3 cp s3://XXXXXXXXXXXXXXXXXXXXXXXXX/google_login_back/dev.json .chalice/deployed/dev.json || true
+&nbsp; &nbsp; &nbsp; - ./test.sh
+
&nbsp; &nbsp;build:
&nbsp; &nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp; &nbsp;commands:
-&nbsp; &nbsp; &nbsp; - pip install -r requirements.txt
&nbsp; &nbsp; &nbsp; &nbsp;- chalice deploy
+
&nbsp; &nbsp;post_build:
&nbsp; &nbsp; &nbsp;on-failure: ABORT
&nbsp; &nbsp; &nbsp;commands:
diff --git a/docker-compose.yml b/docker-compose.yml
index cca3044..815fa32 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -11,7 +11,8 @@ services:
&nbsp; &nbsp; &nbsp;environment:
&nbsp; &nbsp; &nbsp; &nbsp;DB_ENDPOINT: http://dynamo:8000
&nbsp; &nbsp; &nbsp; &nbsp;TEST_PORT: 8008
-&nbsp; &nbsp; &nbsp; PYTEST_ADDOPTS: "-v --pact-files=pacts/*.json"
+&nbsp; &nbsp; &nbsp; PACT_BROKER_BASE_URL: ${PACT_BROKER_BASE_URL}
+&nbsp; &nbsp; &nbsp; PACT_BROKER_AUTH: ${PACT_BROKER_USERNAME}:${PACT_BROKER_PASSWORD}
&nbsp; &nbsp; &nbsp;command: chalice local --host=0.0.0.0 --port=8002
&nbsp; &nbsp;dynamo:
&nbsp; &nbsp; &nbsp;image: amazon/dynamodb-local
diff --git a/test.sh b/test.sh
new file mode 100755
index 0000000..2bca591
--- /dev/null
+++ b/test.sh
@@ -0,0 +1,5 @@
+#!/bin/bash
+
+GIT_VERSION=$(git rev-parse HEAD)
+
+pytest tests/ -v --pact-broker-url=${PACT_BROKER_BASE_URL} --pact-provider-name=google-login-back --pact-publish-results --pact-provider-version=${GIT_VERSION}</code></pre> BrokerでBasic認証している場合は<code>PACT_BROKER_AUTH</code>環境変数に設定することで通すことが可能です。（もしくはURLに付与するやり方もあるようです）

Provider

対応内容

今回はPact Brokerを使って契約ファイルをコンシューマ・プロバイダ間で共有し、CI/CDにPactの検証を組み込むまでを行いました。気をつけるポイントは以下です。<ul><li>Broker<ul><li>インフラをどうするか。ユースケースにもよるが一旦動けばいいレベルならEC2 on Dockerが早い＆安い＆楽？</li></ul></li><li>Consumer<ul><li>testとは別にpublishコマンドを叩く必要がある</li><li>Pact CLIはDockerが無難。CodeBuildに組み込むなら特権が必要</li><li>Consumer=フロントエンドかつAmplifyを使っているならデプロイをトリガーするコマンドが使える</li><li>Gitコマンドを打つなら完全クローンで</li></ul></li><li>Provider<ul><li>testの中でpublishもしてくれる(pactmanの場合)</li><li>Gitコマンドを打つなら完全クローンで</li></ul></li></ul>

現状のパイプラインだと、コンシューマ側で契約を変更した際に、変更後もプロバイダが引き続きサポートしているかどうかがわからないという問題があります。もしサポートしていなかった場合、そのままデプロイされてしまい、不具合が発生する可能性があります。あるべきとしては、コンシューマ側で契約を変更したら、プロバイダが契約を満たすかどうかをチェックしに行くようにコンシューマ側のパイプラインを組む必要があります。こちらは今後の課題として、でき次第また記事にしようと思います。

課題

コンシューマ駆動契約テストに入門してみた〜CI/CD編〜

Hello Worldの本題に入る前に、まずは前提としてコンシューマ駆動契約テストとは何かについて説明させてください（自分の理解の為）。 マイクロサービスアーキテクチャを採用した場合に、特定のサービスAが、複数のサービスB,C,D...から呼ばれる、というような依存関係が生まれます。その場合に、例えばサービスBのために新しい機能をサービスAに実装したとして、サービスAをリリースする際に、サービスBが正しく動くのはもちろんですが他のサービスC,D...も正しく動くことが保証されなければなりません。そこで、サービスBだけでなくサービスC,D...についても結合テストを全て網羅しなければならない、となると非常にリリースのコストが大きくなってしまいます。これでは、マイクロサービスの本来のメリットである、サービス単位の素早いリリースが実現不可能になってしまいます。 コンシューマ駆動契約テストでは、コンシューマ（＝呼び出す側）がプロバイダ（＝呼び出される側）に対して、どんな状況でどんなリクエストを投げた場合に、どんな応答をしてほしいかという「契約」を発行します。具体的には、コンシューマ側で「コラボレーターオブジェクト（APIを呼び出し、結果をオブジェクトにエンコードする層）に対するテストコード」という形で実装します。このテストを実行し成功すると、（Pactの場合はJSON形式の）「契約」が記載されたファイルが出力されます。この契約ファイルをプロバイダに（何らかの方法で）共有し、プロバイダ側で契約が正しく守られているかを（統合テストの形で）検証する、というのが一連の流れです。 コンシューマ駆動契約テストの特徴はその名の通り、コンシューマが自身の求めるインターフェースを率先して規定することです。コンシューマB,C,Dがそれぞれ自身が必要とする最低限のインターフェースを規定し、プロバイダAはそれら全ての契約を満たすように実装できて初めて、プロバイダAの変更をリリースできます。これにより、リリースプロセスを素早く回すことが可能になります。

前提知識ーコンシューマ駆動契約テストとはなんぞや

御託はこれくらいにして、そろそろ実装してみます。前提として、今回テストするAPIの仕様は以下の通りです。<ul><li>エンドポイント: <code>/ping</code></li><li>レスポンス: <code>{"message": "pong"}</code></li></ul>これ以上ないほどシンプルですね。 以前短い文章を投稿する簡単なデモアプリを作成したので、それを流用して上記のエンドポイントを新たに生やします。デモアプリに関しては<a href="https://build.yoku.co.jp/articles/yvg_k7jpwezo" target="_blank" rel="noopener noreferrer">別のテーマで過去に記事にしている</a>ので、興味のある方はそちらをご覧くださいmm

前提

フロントエンドの実装は以下のようになりました。テストコードライブラリにはJestを使用しています。<pre><code>diff --git a/.gitignore b/.gitignore
index fd3dbb5..afa95f9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,6 +8,7 @@
&nbsp;
&nbsp;# testing
&nbsp;/coverage
+/pacts
&nbsp;
&nbsp;# next.js
&nbsp;/.next/
diff --git a/app/api/microposts/service.ts b/app/api/microposts/service.ts
new file mode 100644
index 0000000..24979c6
--- /dev/null
+++ b/app/api/microposts/service.ts
@@ -0,0 +1,11 @@
+export default function MicropostService(baseUrl: string) {
+&nbsp; &nbsp; const ping = async (): Promise&lt;{message: string}&gt; =&gt; {
+&nbsp; &nbsp; &nbsp; &nbsp; const res = await fetch(`${baseUrl}/ping`, {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; headers: {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Content-Type": "application/json",
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
+&nbsp; &nbsp; &nbsp; &nbsp; });
+&nbsp; &nbsp; &nbsp; &nbsp; return res.json();
+&nbsp; &nbsp; }
+&nbsp; &nbsp; return {ping}
+}
\ No newline at end of file
diff --git a/jest.config.js b/jest.config.js
new file mode 100644
index 0000000..7113c5a
--- /dev/null
+++ b/jest.config.js
@@ -0,0 +1,8 @@
+/** @type {import('ts-jest/dist/types').InitialOptionsTsJest} */
+module.exports = {
+&nbsp; preset: 'ts-jest',
+&nbsp; testEnvironment: 'node',
+&nbsp; moduleNameMapper: {
+&nbsp; &nbsp; '^@/app/(.*)$': '&lt;rootDir&gt;/app/$1'
+&nbsp; },
+};
\ No newline at end of file
diff --git a/tests/api.pact.spec.ts b/tests/api.pact.spec.ts
new file mode 100644
index 0000000..330712b
--- /dev/null
+++ b/tests/api.pact.spec.ts
@@ -0,0 +1,33 @@
+import MicropostService from "@/app/api/microposts/service";
+import { MatchersV3, PactV3 } from "@pact-foundation/pact";
+import path from "path";
+
+const provider = new PactV3({
+&nbsp; &nbsp; dir: path.resolve(process.cwd(), 'pacts'),
+&nbsp; &nbsp; consumer: 'auth0-next-custom',
+&nbsp; &nbsp; provider: 'google-login-back'
+});
+
+describe('GET /ping', () =&gt; {
+&nbsp; &nbsp; it('200レスポンス(pong)を返すこと', async () =&gt; {
+&nbsp; &nbsp; &nbsp; &nbsp; provider.addInteraction({
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; states: [{description: 'pongレスポンスに成功する場合'}],
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; uponReceiving: 'pingリクエストを送信する',
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; withRequest: {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; method: 'GET',
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; path: '/ping',
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; },
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; willRespondWith: {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; status: 200,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; headers: {'Content-Type': 'application/json'},
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; body: MatchersV3.equal({message: 'pong'}),
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
+&nbsp; &nbsp; &nbsp; &nbsp; });
+
+&nbsp; &nbsp; &nbsp; &nbsp; await provider.executeTest(async (mockserver) =&gt; {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const service = MicropostService(mockserver.url);
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const response = await service.ping();
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; expect(response.message).toStrictEqual('pong');
+&nbsp; &nbsp; &nbsp; &nbsp; })
+&nbsp; &nbsp; })
+});</code></pre> Pactは記載した契約の通りに動作してくれるモックサーバを提供してくれます。今回の実装ではAPIサービスの名前が<code>MicropostService</code>となっていますがこれは将来的に投稿に関するAPIをサポートしたいという意味であまり気にしないでください。テストを実行すると<code>/pacts</code>に契約ファイル(JSON)が置かれます。

フロントエンド（コンシューマ）

上記を実行したところ以下のファイルが生成されていました。 pacts/auth0-next-custom-google-login-back.json<pre><code>{
 "consumer": {
 "name": "auth0-next-custom"
 },
 "interactions": [
 {
 "description": "pingリクエストを送信する",
 "providerStates": [
 {
 "name": "pongレスポンスに成功する場合"
 }
 ],
 "request": {
 "method": "GET",
 "path": "/ping"
 },
 "response": {
 "body": {
 "message": "pong"
 },
 "headers": {
 "Content-Type": "application/json"
 },
 "matchingRules": {
 "body": {
 "$": {
 "combine": "AND",
 "matchers": [
 {
 "match": "equality"
 }
 ]
 }
 },
 "header": {},
 "status": {}
 },
 "status": 200
 }
 }
 ],
 "metadata": {
 "pact-js": {
 "version": "13.1.0"
 },
 "pactRust": {
 "ffi": "0.4.21",
 "models": "1.2.2"
 },
 "pactSpecification": {
 "version": "3.0.0"
 }
 },
 "provider": {
 "name": "google-login-back"
 }
}</code></pre>

生成された契約ファイル(JSON)

バックエンドの実装は以下のとおりです。テストコードライブラリにはpytestを使用しています。<pre><code>diff --git a/.gitignore b/.gitignore
index 25a656d..7a5766a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@
&nbsp;__pycache__/
&nbsp;.vscode/
&nbsp;dynamodb/
+pacts/
diff --git a/app.py b/app.py
index fead48f..51b7f80 100644
--- a/app.py
+++ b/app.py
@@ -179,3 +179,8 @@ def get_micropost_for_auth0():
&nbsp; &nbsp; &nbsp;posts = Microposts.query(payload.get("sub"))
&nbsp; &nbsp; &nbsp;res = [post.to_simple_dict() for post in posts]
&nbsp; &nbsp; &nbsp;return Response(body=res, status_code=200)
+
+
+@app.route("/ping", methods=["GET"])
+def ping():
+&nbsp; &nbsp; return Response(body={"message": "pong"})
diff --git a/docker-compose.yml b/docker-compose.yml
index e3d4662..cca3044 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -10,6 +10,8 @@ services:
&nbsp; &nbsp; &nbsp; &nbsp;- 8002:8002
&nbsp; &nbsp; &nbsp;environment:
&nbsp; &nbsp; &nbsp; &nbsp;DB_ENDPOINT: http://dynamo:8000
+&nbsp; &nbsp; &nbsp; TEST_PORT: 8008
+&nbsp; &nbsp; &nbsp; PYTEST_ADDOPTS: "-v --pact-files=pacts/*.json"
&nbsp; &nbsp; &nbsp;command: chalice local --host=0.0.0.0 --port=8002
&nbsp; &nbsp;dynamo:
&nbsp; &nbsp; &nbsp;image: amazon/dynamodb-local
diff --git a/tests/conftest.py b/tests/conftest.py
new file mode 100644
index 0000000..80d7fd0
--- /dev/null
+++ b/tests/conftest.py
@@ -0,0 +1,18 @@
+import pytest
+import subprocess
+import time
+import os
+
+
+@pytest.fixture(scope="session")
+def start_chalice_local():
+&nbsp; &nbsp; process = subprocess.Popen(
+&nbsp; &nbsp; &nbsp; &nbsp; ["chalice", "local", "--host=0.0.0.0", f"--port={os.getenv('TEST_PORT')}"],
+&nbsp; &nbsp; &nbsp; &nbsp; stdout=subprocess.PIPE,
+&nbsp; &nbsp; &nbsp; &nbsp; stderr=subprocess.PIPE,
+&nbsp; &nbsp; )
+&nbsp; &nbsp; # サービスが完全に起動するまで待機
+&nbsp; &nbsp; time.sleep(5)
+&nbsp; &nbsp; yield
+&nbsp; &nbsp; process.terminate()
+&nbsp; &nbsp; process.wait()
diff --git a/tests/test_pacts.py b/tests/test_pacts.py
new file mode 100644
index 0000000..e103c0c
--- /dev/null
+++ b/tests/test_pacts.py
@@ -0,0 +1,9 @@
+import os
+
+
+def provider_state(name, **params):
+&nbsp; &nbsp; pass
+
+
+def test_pacts(pact_verifier, start_chalice_local):
+&nbsp; &nbsp; pact_verifier.verify(f"http://localhost:{os.getenv('TEST_PORT')}", provider_state)</code></pre> 契約ファイルはフロント側で生成されたものをバックエンドのリポジトリ配下の<code>/pacts</code>に手動でコピーしています。実運用ならもちろん手動なんてありえないですが、今後の課題とします。 上記で、実質的なテストの中身は以下の1行だけです。<pre><code>pact_verifier.verify(f"http://localhost:{os.getenv('TEST_PORT')}", provider_state)</code></pre> 実行時に参照するpactファイルの場所を指定する必要がありますが、pytestの実行オプション(<code>--pact-files=pacts/*.json</code>)として指定します。毎回指定するのは面倒なので、<code>PYTEST_ADDOPTS</code>環境変数に指定しました。 工夫した点としてはconftest.pyでテスト実行ごとにchaliceサーバを立ち上げるようにしたことです。dockerで起動しているのでそこに直に接続でもいいのですが、テスト環境はローカル開発環境とは切り離したいです。またchaliceは基本的にはホットリロードですがグローバル変数などの変更は再起動が必要だったと思うので、そういった意味でもテストごとに起動したほうが何かと都合がいいと思います。また<code>scope="session"</code>にすることで1回のテスト実行の中ではサーバの起動は最初の1回だけでいいようにしています。

バックエンド（プロバイダ）

Hello World

今回はとりあえずPactにHello Worldしてみました。今後やってみたいことを以下にリストアップしておきます。<ul><li>CI/CDパイプラインに組み込む</li><li>契約ファイルの共有を自動化する<ul><li>ドキュメントとしても活用できたら最高</li></ul></li><li>状態を定義する<ul><li>DBの状態や認証状態など</li></ul></li><li>プロバイダ自身が外部に依存している場合</li><li>プロバイダがAPIではなくキューを使ったイベント駆動の場合</li></ul>上記でき次第また記事にしようと思います。ご覧頂きありがとうございました。

BuildersIO produced by YOKU

#マイクロサービスの記事一覧

コンシューマ駆動契約テストに入門してみた〜can-i-deploy編〜

コンシューマ駆動契約テストに入門してみた〜状態管理編〜

コンシューマ駆動契約テストに入門してみた〜CI/CD編〜

コンシューマ駆動契約テストに入門してみた〜とりあえずHello World編〜

AWS CodeCommitからSSH接続でgit cloneする

OpenAPIの運用コスト下げたい。

機密情報の漏洩を防ごう！～gitleaksの運用方法～

#マイクロサービス の記事一覧

コンシューマ駆動契約テストに入門してみた〜can-i-deploy編〜

コンシューマ駆動契約テストに入門してみた〜状態管理編〜

コンシューマ駆動契約テストに入門してみた〜CI/CD編〜

コンシューマ駆動契約テストに入門してみた〜とりあえずHello World編〜

#マイクロサービスの記事一覧