🎪 🧑🏿‍🤝‍🧑🏼 🦒 GitLab CI: नवीनतम रिलीज़ की 6 विशेषताएं जिनका हम इंतजार कर रहे हैं 👩🏽‍🔧 ⛳️ 🍞

सर्वव्यापी CI / CD के युग में, हमें संबंधित प्रणालियों की एक विस्तृत श्रृंखला के साथ सामना करना पड़ रहा है, जिसमें CI सिस्टम शामिल है। हालाँकि, यह GitLab था जो हमारे लिए सबसे नज़दीकी बन गया, सही मायने में "देशी"। उन्होंने पूरे * के रूप में उद्योग में उल्लेखनीय लोकप्रियता हासिल की। उत्पाद के डेवलपर्स इसके उपयोग में बढ़ती रुचि से पीछे नहीं रहे, नियमित रूप से नए संस्करणों के साथ डेवलपर्स और DevOps इंजीनियरों के समुदाय को प्रसन्न करते हुए।

GitLab रिपॉजिटरी महीने और टैग एकत्रीकरण

GitLab वह मामला है जब सक्रिय विकास कई नई और दिलचस्प विशेषताएं लाता है। यदि संभावित उपयोगकर्ताओं के लिए यह उपकरण चुनने के कारकों में से एक है, तो मौजूदा लोगों के लिए, स्थिति इस प्रकार है: यदि आपने पिछले महीने में अपने गिटलैब इंस्टॉलेशन को अपडेट नहीं किया है, तो उच्च संभावना के साथ आपने कुछ दिलचस्प याद किया। जिसमें नियमित रूप से उभरते सुरक्षा अपडेट शामिल हैं।

सबसे महत्वपूर्ण के बारे में - i.e. हमारे DevOps इंजीनियरों और ग्राहकों द्वारा मांग की गई - GitLab के सामुदायिक संस्करण की नवीनतम रिलीज़ में नवाचार, और इस लेख पर चर्चा की जाएगी।

* 5 , «GitLab», : «, GitHub?». — , Google Trends 5- «gitlab» . «» , . , , «» .

№1: needs

job'.
GitLab: 12.2.
.

सोचा dependencies- यह आपको क्या चाहिए? शायद, हम केवल वही नहीं थे जिन्होंने इस निर्देश को निर्दिष्ट करने की गलती की थी ... पिछली नौकरियों को सूचीबद्ध करने की आवश्यकता है, जिनमें से कलाकृतियों की आवश्यकता होगी। यह कलाकृतियां हैं, और पिछले कार्य के प्रदर्शन पर निर्भरता नहीं है।

माना कि ऐसा हुआ कि एक चरण में ऐसी नौकरियां हैं जिनका प्रदर्शन किया जाना आवश्यक नहीं है, लेकिन किसी कारण से कोई संभावना नहीं है या बस उन्हें एक अलग चरण में ले जाने की इच्छा है (आलस्य प्रगति का इंजन है, लेकिन दूर नहीं किया जाता है)।

स्थिति:

जैसा कि आप देख सकते हैं, स्टेज डिप्लॉय में प्रोडक्शन और स्टेज, और सेलेनियम टेस्ट दोनों को रोल करने के लिए बटन हैंकिसी कारण से निष्पादित नहीं किया जाता है। यह सरल है: वह तब तक इंतजार करता है जब तक कि पिछले चरण की सभी नौकरियां सफलतापूर्वक पूरी नहीं हो जाती हैं। हालांकि, एक ही पाइपलाइन के ढांचे में, हमें परीक्षणों को चलाने के लिए अब मंच तैनात करने की आवश्यकता नहीं है (यह पहले टैग के भीतर पंप नहीं किया गया था)। क्या करें? फिर बचाव की जरूरत है !

हम अपने परीक्षण चलाने के लिए केवल आवश्यक पिछली नौकरियों की सूची देते हैं:

  needs:
    - To production (Cluster 1)
    - To production (Cluster 2)

... और हमें एक नौकरी मिलती है, जिसे केवल सूचीबद्ध नौकरियों के निष्पादित होने के बाद स्वचालित रूप से कहा जाता है:

आसानी से, सही? लेकिन एक बार मुझे उम्मीद थी कि निर्देश कुछ इस तरह से काम करेगा dependencies...

नंबर 2: फैली हुई है

बढ़ाया YAML एंकर और उपनाम।
GitLab 11.3 के बाद से पेश किया गया।
docs.gitlab.com/ce/ci/yaml/#extends

पढ़ने के रोल से थक गए .gitlab-ci.yaml? कोड का पुन: उपयोग सिद्धांत गुम है? तब आप पहले ही प्रयास कर चुके हैं और संभवत: सफलतापूर्वक आपको .gitlab-ci.yamlइस तरह से एक राज्य में ले आए :

.base_deploy: &base_deploy
  stage: deploy
  script:
    - my_deploy_command.sh
  variables:
    CLUSTER: "default-cluster"
    MY_VAR: "10"

Deploy Test:
  <<: *base_deploy
  environment:
    url: test.example.com
    name: test

Deploy Production:
  <<: *base_deploy
  environment:
    url: production.example.com
    name: production
  variables:
    CLUSTER: "prod-cluster"
    MY_VAR: "10"

बहुत अच्छा लगता है? हालांकि, अगर आप बारीकी से देखते हैं, तो कुछ आपकी नज़र को पकड़ता है ... हमने न केवल उत्पादन में बदलाव किया variables.CLUSTER, बल्कि दूसरी बार भी निर्धारित किया variables.MY_VAR=10? क्या इस चर से लिया जाना चाहिए base_deploy? यह पता चलता है कि यह नहीं होना चाहिए: YAML इसलिए काम करता है कि, एंकर से इसे प्राप्त करने को पुनर्परिभाषित करते हुए, यह मिलान वाले क्षेत्रों की सामग्री का विस्तार नहीं करता है , लेकिन इसे बदल देता है । इसलिए, हमें उन वेरिएबल्स को सूचीबद्ध करने के लिए मजबूर किया जाता है जो पहले से ही हमें ज्ञात पैराग्राफ में मिलते हैं।

हां, "विस्तार" सही शब्द है: यह वही है जिसे प्रश्न में विशेषता कहा जाता है। Extendsवे हमें न केवल क्षेत्र को फिर से लिखने की अनुमति देते हैं, जैसा कि एंकर के साथ होता है, लेकिन इसके लिए एक स्मार्ट मर्ज का संचालन करने के लिए:

.base_deploy: 
  stage: deploy
  script:
    - my_deploy_command.sh
  variables:
    CLUSTER: "default-cluster"
    MY_VAR: "10"

Deploy Production:
  extends: .base_deploy
  environment:
    url: production.example.com
    name: production
  variables:
    CLUSTER: "prod-cluster"

यहाँ पर अंतिम जॉब डिप्लॉय प्रोडक्शनMY_VAR में डिफॉल्ट वैल्यू वाला एक वैरिएबल और ओवरराइड दोनों होंगे CLUSTER।

ऐसा लगता है कि यह ऐसी एक तिपहिया है, लेकिन कल्पना करें: आपके पास एक base_deployऔर 20 सर्किट समान रूप से तैनात हैं। चर या अन्य मिलान क्षेत्रों के एक निश्चित सेट को संरक्षित करते हुए cluster, उन्हें दूसरों पर पारित करने की आवश्यकता होती है environment.name... इस छोटी सी खुशी ने हमें कई देव-सर्किटों की तैनाती के विवरण को 2-3 गुना कम करने की अनुमति दी।

नंबर 3: शामिल हैं

हम विशाल YAML को कई में विभाजित करते हैं और अन्य परियोजनाओं में पुन: उपयोग करते हैं।
11.4 संस्करण के बाद से कोर में पेश किया गया।
docs.gitlab.com/ce/ci/yaml/#include

.gitlab-ci.yamlयह अभी भी ~~20 भाषाओं में वैक्यूम क्लीनर के लिए एक तह निर्देश की तरह~~ दिखता है ~~(जिसमें से आप केवल अपने मूल एक को समझते हैं) क्या~~ यह मुश्किल है जब आपको रास्ते में सामना किए गए अज्ञात नौकरियों के चेहरे को बदलने के बिना इसके एक अनुभाग से निपटने की आवश्यकता है?

एक लंबे समय तक प्रोग्रामिंग मित्र मदद करेगा include:

stages:
  - test
  - build
  - deploy

variables:
  VAR_FOR_ALL: 42

include:
  - local: .gitlab/ci/test.yml
  - local: .gitlab/ci/build.yml
  - local: .gitlab/ci/deploy-base.yml
  - local: .gitlab/ci/deploy-production.yml

उन। अब हम साहसपूर्वक उत्पादन में तैनाती का संपादन कर रहे हैं, जबकि परीक्षक अपनी फाइल को संशोधित करने में व्यस्त हैं, जिसे हम देख भी नहीं सकते हैं। इसके अलावा, यह मर्ज संघर्ष से बचने में मदद करता है: किसी और के कोड को समझने में हमेशा मजा नहीं आता है।

लेकिन क्या होगा अगर हम अपनी 20 परियोजनाओं की पाइपलाइन को साथ-साथ जानते हैं, तो क्या हम इसमें से प्रत्येक काम का तर्क समझा सकते हैं? इससे हमें कैसे मदद मिलेगी? उन लोगों के लिए जिन्होंने कोड पुन: उपयोग में ज्ञान प्राप्त किया है और सभी के लिए जिनके पास कई समान परियोजनाएं हैं, आप कर सकते हैं:

का उपयोग कर शामिल हैं: फ़ाइल - GitLab CI फ़ाइलों को उसी GitLab उदाहरण के अन्य भंडार से शामिल करें,
के साथ शामिल हैं: टेम्पलेट - तैयार GitLab टेम्पलेट्स का संग्रह ,
के साथ शामिल हैं: रिमोट - एक बाहरी फ़ाइल (HTTPS के माध्यम से सुलभ)।

विभिन्न कोड वाली एक ही प्रकार की दर्जनों परियोजनाएँ, लेकिन सभी रिपॉजिटरी में सीआई को अप-टू-डेट सीआई बनाए रखने के बिना - उसी तरह से तैनात - आसानी से और बिना! इस लेख में

व्यावहारिक उपयोग includeका एक उदाहरण भी दिया गया था ।

नंबर 4: केवल / रेफरी को छोड़कर

परिवर्तनशील और फ़ाइल परिवर्तन सहित व्यापक स्थितियाँ।
चूंकि यह फ़ंक्शन का एक पूरा परिवार है, इसलिए कुछ हिस्से गिटलैब 10.0 में दिखाई देने लगे, जबकि अन्य (उदाहरण के लिए changes) 11.4 में दिखाई देने लगे ।
docs.gitlab.com/ce/ci/yaml/#onlyexcept-advanced

कभी-कभी ऐसा लगता है कि यह हमारी बात सुनने वाली पाइपलाइन नहीं है, बल्कि हम हैं। एक उत्कृष्ट प्रबंधन उपकरण कर रहे हैं only/ except- अब एकीकृत। इसका क्या मतलब है?

सबसे सरल (और शायद सबसे सुखद) मामले में, लंघन चरणों:

Tests:
  only:
    - master
  except:
    refs:
    - schedules
    - triggers
    variables:
    - $CI_COMMIT_MESSAGE =~ /skip tests/

उदाहरण की नौकरी में, यह केवल मास्टर शाखा पर चलता है, लेकिन एक शेड्यूल या ट्रिगर द्वारा ट्रिगर नहीं किया जा सकता है (GitLab एपीआई कॉल और ट्रिगर साझा करता है, हालांकि यह अनिवार्य रूप से एक ही एपीआई है)। यदि प्रतिबद्ध संदेश में स्किप परीक्षण पासफ़्रेज़ है तो नौकरी निष्पादित नहीं की जाएगी । उदाहरण के लिए, README.mdपरियोजना या प्रलेखन में एक टाइपो तय किया गया है - परीक्षण के परिणाम की प्रतीक्षा क्यों करें?

"अरे, 2020 बाहर है!" मुझे हर बार लोहे के बक्से की व्याख्या क्यों करनी चाहिए कि दस्तावेज़ बदलते समय परीक्षण चलाना आवश्यक नहीं है? " और वास्तव में: only:changesयह आपको कुछ निर्देशिकाओं में केवल फाइलें बदलते समय परीक्षण चलाने की अनुमति देता है। उदाहरण के लिए:

  only:
    refs:
      - master
      - merge_requests
    changes:
      - "front/**/*"
      - "jest.config.js"
      - "package.json"

और रिवर्स एक्शन के लिए - i.e. भागो मत - हाँ except:changes।

नंबर 5: नियम

व्यक्तिगत नौकरी के नियम।
GitLab 12.3 में प्रस्तुत किया गया।
docs.gitlab.com/ce/ci/yaml/#rules

यह निर्देश पिछले वाले के समान है only:*, लेकिन एक महत्वपूर्ण अंतर के साथ: यह आपको पैरामीटर को नियंत्रित करने की अनुमति देता है when। उदाहरण के लिए, यदि आप नौकरी शुरू करने की संभावना को पूरी तरह से दूर नहीं करना चाहते हैं। आप बस बटन छोड़ सकते हैं, जो, यदि वांछित है, तो स्वतंत्र रूप से बुलाया जाएगा, बिना एक नई पाइपलाइन लॉन्च किए या बिना प्रतिबद्ध किए।

# 6: पर्यावरण: auto_stop_in

गतिविधि के अभाव में वातावरण को रोकें।
GitLab 12.8 में पेश किया गया।
docs.gitlab.com/ce/ci/yaml/#environmentauto_stop_in

हमने लेख के प्रकाशन से ठीक पहले इस अवसर के बारे में सीखा और अभी तक इसे अभ्यास में आज़माने के लिए पर्याप्त समय नहीं है, लेकिन यह निश्चित रूप से "एक ही बात" है जो कई परियोजनाओं में अपेक्षित थी।

आप GitLab वातावरण में एक पैरामीटर निर्दिष्ट कर सकते हैं on_stop- यह तब बहुत उपयोगी होता है जब आप गतिशील रूप से वातावरण बनाना और हटाना चाहते हैं, उदाहरण के लिए, प्रत्येक शाखा के लिए। K के साथ चिह्नित कार्य on_stopनिष्पादित किया जाता है, उदाहरण के लिए, जब एमआर का विलय मास्टर शाखा में होता है या जब एमआर बंद होता है (या यहां तक कि सिर्फ बटन पर क्लिक करके), जिसके कारण अनावश्यक वातावरण स्वचालित रूप से हटा दिया जाता है।

सब कुछ सुविधाजनक, तार्किक, काम करता है ... यदि मानव कारक के लिए नहीं। कई डेवलपर्स GitLab में एक बटन क्लिक करके नहीं, बल्कि स्थानीय स्तर पर MR का विलय करते हैं git merge। आप उन्हें समझ सकते हैं: यह सुविधाजनक है! लेकिन इस मामले में, तर्कon_stopयह काम नहीं करता है, हम भूल गए परिवेश को संचित करते हैं ... यह वह जगह है जहां लंबे समय से प्रतीक्षित काम आता है auto_stop_in।

बोनस: अस्थायी झोपड़ियों जब पर्याप्त अवसर नहीं हैं

इन सभी (और कई अन्य) के बावजूद, गिटलैब के नए मांगे गए कार्यों, दुर्भाग्य से, कभी-कभी नौकरी पूरी करने की शर्तों को वर्तमान में उपलब्ध क्षमताओं के संदर्भ में वर्णन करना असंभव है।

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

समाधान संख्या 1: एक बटन के साथ दो कार्य लॉन्च करें

script:
  - > 
    export CI_PROD_CL1_JOB_ID=`curl -s -H "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \ 
      "https://gitlab.domain/api/v4/projects/${CI_PROJECT_ID}/pipelines/${CI_PIPELINE_ID}/jobs" | \
      jq '[.[] | select(.name == "Deploy (Cluster 1)")][0] | .id'`
  - > 
    export CI_PROD_CL2_JOB_ID=`curl -s -H "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \ 
      "https://gitlab.domain/api/v4/projects/${CI_PROJECT_ID}/pipelines/${CI_PIPELINE_ID}/jobs" | \
      jq '[.[] | select(.name == "Deploy (Cluster 2)")][0] | .id'`
  - > 
    curl -s --request POST -H "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \ 
      "https://gitlab.domain/api/v4/projects/${CI_PROJECT_ID}/jobs/$CI_PROD_CL1_JOB_ID/play"
  - > 
    curl -s --request POST -H "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \ 
      "https://gitlab.domain/api/v4/projects/${CI_PROJECT_ID}/jobs/$CI_PROD_CL2_JOB_ID/play"

और क्यों नहीं, यदि आप वास्तव में चाहते हैं?

वर्कअराउंड नंबर 2: छवि के अंदर रूबोकॉप के लिए एमआर आरबी-फाइलों में स्थानांतरण बदल गया

Rubocop:
  stage: test
  allow_failure: false
  script:
    ...
    - export VARFILE=$(mktemp)
    - export MASTERCOMMIT=$(git merge-base origin/master HEAD)
    - echo -ne 'CHANGED_FILES=' > ${VARFILE}
    - if [ $(git --no-pager diff --name-only ${MASTERCOMMIT} | grep '.rb$' | wc -w |awk '{print $1}') -gt 0 ]; then
        git --no-pager diff --name-only ${MASTERCOMMIT} | grep '.rb$' |tr '\n' ' ' >> ${VARFILE} ;
      fi
    - if [ $(wc -w ${VARFILE} | awk '{print $1}') -gt 1 ]; then
        werf --stages-storage :local run rails-dev --docker-options="--rm --user app --env-file=${VARFILE}" -- bash -c /scripts/rubocop.sh ;
      fi
    - rm ${VARFILE}

अंदर कोई छवि नहीं है .git, इसलिए मुझे केवल परिवर्तित फ़ाइलों की जांच करने के लिए बाहर निकलना पड़ा।

नोट: यह एक बहुत ही मानक स्थिति नहीं है और समस्या की कई स्थितियों का पालन करने के लिए एक हताश प्रयास है, जिसका वर्णन इस लेख के दायरे में शामिल नहीं है।

वर्कअराउंड # 3: ट्रिगर करते समय अन्य रिपॉजिटरी से नौकरी शुरू करने के लिए ट्रिगर करें

  before_script:
    - |
      echo '### Trigger review: infra'
      curl -s -X POST \
        -F "token=$REVIEW_TOKEN_INFRA" \
        -F "ref=master" \
        -F "variables[REVIEW_NS]=$CI_ENVIRONMENT_SLUG" \
        -F "variables[ACTION]=auto_review_start" \
        https://gitlab.example.com/api/v4/projects/${INFRA_PROJECT_ID}/trigger/pipeline

ऐसा लगता है कि इस तरह के एक सरल और आवश्यक (माइक्रोसिस्टर्स की दुनिया में) बात एक और माइक्रोसेवर को एक निर्भरता के रूप में एक नए सिरे से बनाए गए सर्किट में रोल कर रही है। लेकिन यह नहीं है, इसलिए, एक एपीआई कॉल और पहले से परिचित (ऊपर वर्णित) सुविधा की आवश्यकता है:

  only:
    refs:
    - triggers
    variables:
    - $ACTION == "auto_review_start"

टिप्पणियाँ:

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

निष्कर्ष

GitLab ट्रेंड्स के साथ रहने की कोशिश करता है, धीरे-धीरे उन विशेषताओं को लागू करता है जो सुखद हैं और देवओप्स समुदाय द्वारा मांग में हैं। वे उपयोग करने में काफी आसान हैं, और जब बुनियादी क्षमताएं पर्याप्त नहीं हैं, तो उन्हें हमेशा स्क्रिप्ट के साथ विस्तारित किया जा सकता है। और अगर हम देखते हैं कि यह समर्थन में इतनी भव्यता और सुविधाजनक रूप से नहीं निकला है ... तो यह गीतालाब की नई रिलीज के लिए इंतजार करने के लिए - या हमारे योगदान के साथ परियोजना में मदद करने के लिए बनी हुई है ।

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

GitLab CI: नवीनतम रिलीज़ की 6 विशेषताएं जिनका हम इंतजार कर रहे हैं