💦 ✌️ 🔐 कंज्यूमर ड्रिव्ड कॉन्ट्रैक्ट्स या गिटलैब सीआई-आइड क्यूए टेस्ट ऑटोमेशन ♣️ 👩🏾 👩🏾‍💻

इस प्रकाशन के उद्देश्य हैं :

उपभोक्ता प्रवृत्त संविदा (सीडीसी) का संक्षिप्त परिचय
CDI- आधारित CI पाइपलाइन कॉन्फ़िगर करें

उपभोक्ता प्रेरित अनुबंध

इस भाग में, हम सीडीसी के मुख्य बिंदुओं पर जाएंगे। अनुबंध परीक्षण के विषय पर यह लेख संपूर्ण नहीं है। एक ही Habré पर इस विषय पर पर्याप्त मात्रा में सामग्री है।

जारी रखने के लिए, हमें सीडीसी के मुख्य प्रावधानों से परिचित होना चाहिए:

संपर्क परीक्षण माइक कोहन पिरामिड के अनुसार यूनिट टेस्ट से ऊपर सेवा / एकीकरण टेस्ट स्तर पर है ।
अनुबंध परीक्षण तब लागू किया जा सकता है जब 2 (या अधिक) सेवाएं होती हैं जो एक दूसरे के साथ बातचीत करती हैं।
उपभोक्ता संचालित दृष्टिकोण का अर्थ है कि कार्यान्वयन में पहला कदम उपभोक्ता पक्ष पर एक परीक्षण लिखना है। परीक्षण का परिणाम एक जसन-स्वरूपित संधि (अनुबंध) है जो उपभोक्ता के बीच बातचीत का वर्णन करता है (जैसे वेब इंटरफ़ेस / मोबाइल इंटरफ़ेस: एक सेवा जो कुछ डेटा प्राप्त करना चाहता है) और प्रदाता (जैसे- सर्वर एपीआई: एक सेवा डेटा प्रदान करती है)
अगला कदम प्रदाता के साथ अनुबंध की जांच करना है। यह पैक्ट ढांचे द्वारा पूरी तरह से लागू किया गया है।

तो, चलो उपभोक्ता पक्ष परीक्षण के साथ शुरू करते हैं। मैंने पैक्टमैन का इस्तेमाल किया। यह परीक्षण जैसा दिखता है:

import pytest from pactman import Like from model.client import Client @pytest.fixture() def consumer(pact): return Client(pact.uri) def test_app(pact, consumer): expected = '123456789' (pact .given('provider in some state') .upon_receiving("request to get user's phone number") .with_request( method='GET', path=f'/phone/john', ) .will_respond_with(200, body=Like(expected)) .given('provider in some state') .upon_receiving("request to get non-existent user's phone number") .with_request( method='GET', path=f'/phone/micky' ) .will_respond_with(404) ) with pact: consumer.get_users_phone(user='john', host=pact.uri) consumer.get_users_phone(user='micky', host=pact.uri)

Pact DSL का उपयोग करते हुए, हम अनुरोध / प्रतिक्रिया इंटरैक्शन का वर्णन करते हैं। परीक्षण शुरू करने के बाद, हम एक नई फ़ाइल ({उपभोक्ता} - {प्रदाता} -pact.json) प्राप्त करते हैं:

 { "consumer": { "name": 'basic_client' }, "provider": { "name": 'basic_flask_app' }, "interactions": [ { "providerStates": [ { "name": "provider in some state", "params": {} } ], "description": "request to get user's phone number", "request": { "method": "GET", "path": "/phone/john" }, "response": { "status": 200, "body": "123456789", "matchingRules": { "body": { "$": { "matchers": [ { "match": "type" } ] } } } } }, { "providerStates": [ { "name": "provider in some state", "params": {} } ], "description": "request to get non-existent user's phone number", "request": { "method": "GET", "path": "/phone/micky" }, "response": { "status": 404 } } ], "metadata": { "pactSpecification": { "version": "3.0.0" } } }

अगला, हमें सत्यापन के लिए प्रदाता को संधि को पास करना होगा। यह पैक्ट ब्रोकर का उपयोग करके किया जाता है।

पैक्ट ब्रोकर कुछ अतिरिक्त विशेषताओं के साथ एक अनुबंध भंडार है जो हमें सेवा संस्करणों की संगतता को ट्रैक करने की अनुमति देता है, साथ ही साथ नेटवर्क आरेख (सेवा इंटरैक्शन) भी उत्पन्न करता है।

संधि दलाल

संधि

संस्करण मैट्रिक्स

प्रदाता सत्यापन

परीक्षण का यह हिस्सा पूरी तरह से रूपरेखा द्वारा किया जाता है। सत्यापन के बाद, परिणाम पैक्ट ब्रोकर को वापस भेज दिए जाते हैं।

 provider-verifier_1 | Verifying a pact between basic_client and basic_flask_app provider-verifier_1 | Given provider in some state provider-verifier_1 | request to get user's phone number provider-verifier_1 | with GET /phone/john provider-verifier_1 | returns a response which provider-verifier_1 | WARN: Skipping set up for provider state 'provider in some state' for consumer 'basic_client' as there is no --provider-states-setup-url specified. provider-verifier_1 | has status code 200 provider-verifier_1 | has a matching body provider-verifier_1 | Given provider in some state provider-verifier_1 | request to get non-existent user's phone number provider-verifier_1 | with GET /phone/micky provider-verifier_1 | returns a response which provider-verifier_1 | WARN: Skipping set up for provider state 'provider in some state' for consumer 'basic_client' as there is no --provider-states-setup-url specified. provider-verifier_1 | has status code 404 provider-verifier_1 | provider-verifier_1 | 2 interactions, 0 failures

पाइपलाइन में परीक्षण के दोनों हिस्सों को चलाना

अब जब कॉन्ट्रैक्ट टेस्टिंग के दोनों हिस्से डिसाइड हो गए हैं, तो उन्हें हर कमिटमेंट में चलाना अच्छा रहेगा। यह वह जगह है जहाँ गिटलब सीआई बचाव के लिए आता है। पाइपलाइन नौकरियों में .gitlab-ci.yml वर्णन किया गया है। इससे पहले कि हम पाइपलाइन पर आगे बढ़ें, हमें गिटलैब रनर के बारे में कुछ शब्द कहने की ज़रूरत है, जो एक ओपन-सोर्स प्रोजेक्ट है, और इसका उपयोग जॉब चलाने और रिजल्ट्स को वापस गीतालाब में भेजने के लिए किया जाता है। नौकरियों को स्थानीय रूप से या डॉकटर कंटेनरों का उपयोग करके चलाया जा सकता है। हमारे प्रोजेक्ट में हम डॉकर का उपयोग करते हैं। परीक्षण बुनियादी ढांचे को कंटेनरों में लागू किया जाता है और परियोजना के मूल में स्थित docker-compose.yml में वर्णित किया जाता है।

 version: '2' services: basic-flask-app: image: registry.gitlab.com/tknino69/basic_flask_app:latest ports: - 5005:5005 postgres: image: postgres ports: - 5432:5432 env_file: - test-setup.env volumes: - db-data:/var/lib/postgresql/data/pgdata pactbroker: image: dius/pact-broker links: - postgres ports: - 80:80 env_file: - test-setup.env provider-states: image: registry.gitlab.com/tknino69/cdc/provider-states:latest build: provider-states ports: - 5000:5000 consumer-test: image: registry.gitlab.com/tknino69/cdc/consumer-test:latest command: ["sh", "-c", "find -name '*.pyc' -delete && pytest $${TEST}"] links: - pactbroker environment: - CONSUMER_VERSION=$CI_COMMIT_SHA provider-verifier: image: registry.gitlab.com/tknino69/cdc/provider-verifier:latest build: provider-verifier ports: - 5001:5000 links: - pactbroker depends_on: - consumer-test - provider-states command: ['sh', '-c', 'find -name "*.pyc" -delete && CONSUMER_VERSION=`curl --header "PRIVATE-TOKEN:$${API_TOKEN}" https://gitlab.com/api/v4/projects/$${BASIC_CLIENT}/repository/commits | jq ".[0] .id" | sed -e "s/\x22//g"` && echo $${CONSUMER_VERSION} && pact-provider-verifier $${PACT_BROKER}/pacts/provider/$${PROVIDER}/consumer/$${CONSUMER}/version/$${CONSUMER_VERSION} --provider-base-url=$${BASE_URL} --pact-broker-base-url=$${PACT_BROKER} --provider=$${PROVIDER} --consumer-version-tag=$${CONSUMER_VERSION} --provider-app-version=$${PROVIDER_VERSION} -v --publish-verification-results=PUBLISH_VERIFICATION_RESULTS'] environment: - PROVIDER_VERSION=$CI_COMMIT_SHA - API_TOKEN=$API_TOKEN env_file: - test-setup.env volumes: db-data:

इसलिए, हमारे पास ऐसी सेवाएँ हैं जो आवश्यकतानुसार कंटेनर में चलती हैं।

सेवा प्रदाता:

 basic-flask-app: image: registry.gitlab.com/tknino69/basic_flask_app:latest ports: - 5005:5005

पैक्ट ब्रोकर और उसके डेटाबेस। वॉल्यूम हमें पैक्ट्स और प्रदाता सत्यापन के परिणामों के लिए एक स्थायी भंडार रखने की अनुमति देते हैं:

 postgres: image: postgres ports: - 5432:5432 env_file: - test-setup.env volumes: - db-data:/var/lib/postgresql/data/pgdata pactbroker: image: dius/pact-broker links: - postgres ports: - 80:80 env_file: - test-setup.env

सेवा प्रदाता राज्य। व्यवहार में, इसे प्रदाता को एक निश्चित स्थिति में लाना चाहिए (उदाहरण के लिए, डेटाबेस में उपयोगकर्ता प्राप्त करें)। हालांकि, हमारे उदाहरण में, यह केवल एक डमी फ़ंक्शन करता है।

 provider-states: image: registry.gitlab.com/tknino69/cdc/provider-states:latest build: provider-states ports: - 5000:5000

एक सेवा जो उपभोक्ता परीक्षण चलाता है। कंटेनर find -name '* .pyc' -delete && pytest $$ {TEST} वाले कमांड में ध्यान दें find -name '* .pyc' -delete && pytest $$ {TEST}

 consumer-test: image: registry.gitlab.com/tknino69/cdc/consumer-test:latest command: ["sh", "-c", "find -name '*.pyc' -delete && pytest $${TEST}"] links: - pactbroker environment: - CONSUMER_VERSION=$CI_COMMIT_SHA

सेवा प्रदाता सत्यापनकर्ता:

 provider-verifier: image: registry.gitlab.com/tknino69/cdc/provider-verifier:latest build: provider-verifier ports: - 5001:5000 links: - pactbroker depends_on: - consumer-test - provider-states command: ['sh', '-c', 'find -name "*.pyc" -delete && CONSUMER_VERSION=`curl --header "PRIVATE-TOKEN:$${API_TOKEN}" https://gitlab.com/api/v4/projects/$${BASIC_CLIENT}/repository/commits | jq ".[0] .id" | sed -e "s/\x22//g"` && echo $${CONSUMER_VERSION} && pact-provider-verifier $${PACT_BROKER}/pacts/provider/$${PROVIDER}/consumer/$${CONSUMER}/version/$${CONSUMER_VERSION} --provider-base-url=$${BASE_URL} --pact-broker-base-url=$${PACT_BROKER} --provider=$${PROVIDER} --consumer-version-tag=$${CONSUMER_VERSION} --provider-app-version=$${PROVIDER_VERSION} -v --publish-verification-results=PUBLISH_VERIFICATION_RESULTS'] environment: - PROVIDER_VERSION=$CI_COMMIT_SHA - API_TOKEN=$API_TOKEN env_file: - test-setup.env

उपभोक्ता पाइपलाइन
उपभोक्ता परियोजना के मूल में .gitlab-ci.yml उपभोक्ता पक्ष पर चलने वाली प्रक्रियाओं का वर्णन करता है:

 image: gitlab/dind:latest variables: TEST: 'tests/docker-compose.app.yml' CONSUMER_VERSION: $CI_COMMIT_SHA BASIC_APP: '11993024' services: - gitlab/gitlab-runner:latest before_script: - docker login -u $GIT_USER -p $GIT_PASS registry.gitlab.com stages: - clone_test - get_broker_up - test - verify_provider - clean_up clone test: tags: - cdc stage: clone_test script: - git clone https://$GIT_USER:$GIT_PASS@gitlab.com/tknino69/cdc.git && ls -ali artifacts: paths: - cdc/ broker: tags: - cdc stage: get_broker_up script: - cd cdc && docker-compose -f docker-compose.yml up -d pactbroker dependencies: - clone test test: tags: - cdc stage: test script: - cd cdc && CONSUMER_VERSION=$CONSUMER_VERSION docker-compose -f docker-compose.yml -f $TEST up consumer-test dependencies: - clone test provider verification: tags: - cdc stage: verify_provider script: - curl -X POST -F token=$CI_JOB_TOKEN -F ref=master https://gitlab.com/api/v4/projects/$BASIC_APP/trigger/pipeline when: on_success clean up: tags: - cdc stage: clean_up script: - cd cdc && docker-compose stop consumer-test dependencies: - clone test

यहाँ निम्न होता है:

before_script हम $ GIT_USER और $ GIT_PASS चर का उपयोग करके अपनी gitlab रजिस्ट्री में लॉग इन करते हैं जो हमने सेटिंग्स> CI / CD में सेट किया है

अगला, हम एक परीक्षण परियोजना का क्लोन बनाते हैं
अगले चरण में, हम पैक्ट ब्रोकर बढ़ाते हैं
फिर कंज्यूमर टेस्ट शुरू होता है।
उसके बाद, प्रदाता सत्यापन शुरू करने के लिए Gitlab API का उपयोग करें।
और अंत में, हम खुद को साफ करते हैं

प्रदाता पाइपलाइन
प्रदाता पाइपलाइन विन्यास को प्रदाता परियोजना की जड़ में .gitlab-ci.yml में संग्रहीत किया जाता है।

 image: gitlab/dind:latest variables: TEST: 'tests/docker-compose.app.yml' PROVIDER_VERSION: $CI_COMMIT_SHA services: - gitlab/gitlab-runner:latest stages: - clone_test - provider_verification - clean_up clone test: tags: - cdc stage: clone_test script: - git clone https://$GIT_USER:$GIT_PASS@gitlab.com/tknino69/cdc.git artifacts: paths: - cdc/ verify provider: tags: - cdc stage: provider_verification before_script: - cd cdc - docker login -u $GIT_USER -p $GIT_PASS registry.gitlab.com && docker-compose -f docker-compose.yml up -d basic-flask-app script: - PROVIDER_VERSION=$PROVIDER_VERSION docker-compose -f docker-compose.yml -f $TEST up provider-verifier dependencies: - clone test .clean up: tags: - cdc stage: clean_up script: - cd cdc && docker-compose down --rmi local

उपभोक्ता पाइपलाइन में, हमारे पास कई काम हैं:

क्लोन एक परीक्षण परियोजना
प्रदाता सत्यापित करें
हम खुद को साफ करते हैं

संक्षेप :

पाइथन में एक अनुबंध परीक्षण लिखा
डॉकटर कंटेनरों में एक परीक्षण वातावरण सेट करें
अनुबंध परीक्षणों के आधार पर कॉन्फ़िगर किया गया CI, अर्थात उपभोक्ता परियोजना के लिए CI पाइपलाइन लॉन्च करेगा ( उपभोक्ता पक्ष पर : परीक्षण वातावरण का क्लोनिंग -> पैक्ट ब्रोकर शुरू करना -> उपभोक्ता का परीक्षण करना - प्रदाता प्रदाता सत्यापन शुरू करना -> प्रदाता पक्ष पर : परीक्षण वातावरण का क्लोन करना -> प्रदाता सत्यापन)> साफ करना; )।
प्रदाता परियोजना के लिए प्रदाता सत्यापन सुनिश्चित करता है कि प्रदाता समझौते का अनुपालन करता है

आपका ध्यान के लिए धन्यवाद।

कंज्यूमर ड्रिव्ड कॉन्ट्रैक्ट्स या गिटलैब सीआई-आइड क्यूए टेस्ट ऑटोमेशन

More articles: