10 تا از بهترین روش GitLab CI برای جلوگیری از آنتی پترن

GitLab CI یک ابزار قدرتمند است که در طول 10 سال گذشته به دلیل قابلیت های قابل توجه خود، جذابیت قابل توجهی به دست آورده است. با این حال، علیرغم جامعه رو به رشد آن و فراوانی منابع آنلاین، توسعه دهندگان اغلب خود را با همزیستی پترن ها و ضد پترن ها در GitLab CI سردرگم می کنند. این سردرگمی تلاش‌های آن‌ها برای افزایش مهارت‌های GitLab CI را مختل می‌کند. هدف این مقاله پرداختن به این موضوع با گردآوری مجموعه ای جامع از بهترین شیوه ها برای مبارزه با ضد پترن هایی است که معمولاً در پروژه های زندگی واقعی و در اینترنت یافت می شوند. با پیروی از این بهترین شیوه‌ها، توسعه‌دهندگان می‌توانند بر چالش‌های ناشی از ضد پترن غلبه کنند و مهارت GitLab CI خود را بهبود بخشند.

1. CI را با image داکر CI نسخه شده شروع کنید

اساس کار کانتینری در GitLab CI بر یک image داکر و یک کانتینر نمونه متکی است. در این کانتینر، دستوراتی را برای دستکاری پایگاه کد ارزشمند خود اجرا می کنیم.

برای ساده‌سازی گردش کار CI، بسیاری از پکیج منیجر ها و سایر ابزارهای رایج در CI از قبل image های عمومی Docker را با دقت ساخته شده‌اند. با استفاده از این image، می توانید از تنظیمات و وابستگی های از پیش پیکربندی شده آنها استفاده کنید. به روز رسانی منظم نسخه image که استفاده می کنید بسیار مهم است. از استفاده از تگ  latest خودداری کنید، زیرا می تواند منجر به تغییرات غیرمنتظره شود. در چنین مواردی، ممکن است متوجه شوید که ساعت‌ها برای عیب‌یابی کد های خود وقت می‌گذارید و از خود می‌پرسید که چرا ناگهان کار نمی‌کند.

استفاده گسترده: image داکر سفارشی از قبل

هنگامی که نمی توانید image های کاملی را پیدا کنید که تمام نیازهای شما را برآورده کند، ممکن است وسوسه ایجاد یک تصویر سفارشی ایجاد شود. به نظر می رسد به سادگی اجرای Docker build && Docker push، درست است؟ با این حال، قبل از انتشار Kraken، باید چند نکته را در نظر داشته باشید.

اول از همه، شما باید:

• یک رجیستری Docker به طور خاص برای تصاویر CI تنظیم کنید.
   
• رانرهای خود را برای احراز هویت با این رجیستری Docker پیکربندی کنید.
   
• مدیریت رجیستری برای مدیریت رشد بالقوه استفاده از دیسک. به خاطر داشته باشید که احتمالاً نسخه‌های تصویری بیشتری از آنچه در ابتدا پیش‌بینی می‌کنید وجود خواهد داشت.

این هنوز هم خوب است، به خصوص برای شرکت هایی که سیاست های امنیتی سختگیرانه دارند. یک رجیستری داکر داخلی تصاویر عمومی را منعکس می کند. اما اگر به تصاویری با محتوای سفارشی تکیه کنید، سفر به همین جا ختم نمی شود. در نهایت، شما با چرخه تعمیر و نگهداری مواجه خواهید شد که با مجموعه ای از چالش ها همراه است:

• تصویر سفارشی توسط توسعه دهندگان به عنوان یک جعبه سیاه درک می شود.
   
• کسی باید مسئولیت نگهداری آن را بپذیرد.
   
• ارتقاء ابزارها در تصویر نیاز به برنامه ریزی دقیق دارد.
   
• تغییرات مورد نیاز یک پروژه ممکن است عواقب ناخواسته ای برای جاب ها یا پروژه های دیگر داشته باشد.
   

هزینه ایجاد تغییرات زیاد است. شما باید:
Dockerfile را پیدا کنید.
تغییرات لازم را در Dockerfile انجام دهید.
تصویر اصلاح شده را به عنوان یک تگ تست  push دهید.
تصویر جدید را روی پروژه هایی که به آن وابسته هستند تست کنید.
تکرار کنید و تکرار کنید تا تصویر رضایت بخش تلقی شود.
در نهایت، تصویر را به عنوان تگ نهایی push دهید.

توصیه: نصب های جزئی در زمان اجرا

یک رویکرد کارآمدتر این است که job ها را بر اساس اهداف اصلی آنها تقسیم کنید، تصاویری را انتخاب کنید که با اکوسیستم اصلی هماهنگ باشند و ابزارهای گمشده را در زمان اجرا نصب کنید. در اینجا چند نمونه هستند:

node-and-git:
  image: node:18.10-alpine
  before_script:
    - apk --no-cache add git

kubectl-and-stern:
  image: alpine/k8s:1.22.13
  before_script:
    # install stern
    - curl --show-error --silent --location https://github.com/stern/stern/releases/download/v1.22.0/stern_1.22.0_linux_amd64.tar.gz | tar zx --directory /usr/bin/ stern && chmod 755 /usr/bin/stern

playwright-and-kubectl:
  image: mcr.microsoft.com/playwright:v1.35.1-focal
  before_script:
    # install kubectl
    - curl --show-error --silent --location --remote-name https://storage.googleapis.com/kubernetes-release/release/v1.25.3/bin/linux/amd64/kubectl && chmod +x ./kubectl && mv ./kubectl /usr/local/bin/

اما ممکن است تعجب کنید که آیا این رویکرد زمان اجرا را کاهش می دهد؟ پاسخ اکثراً منفی است، حداقل نه به طور قابل توجهی، به خصوص اگر شما runner قابل اعتمادی داشته باشید.

با این حال، به دلیل محدودیت‌های نرخ Docker Hub، یک مشکل بالقوه با این پترن وجود دارد. برای کاهش این مشکل، runner خود را پیکربندی کنید تا در صورت امکان با ایجاد یا پیکربندی آن با "docker-pull-policy "if-not-present-- از تصاویر محلی استفاده کند.

اگر از runner های مقیاس خودکار استفاده می کنید، ممکن است همچنان با مشکلات محدودیت نرخ مواجه شوید. در چنین مواردی می توانید از پروکسی رجیستری Docker استفاده کنید. GitLab می تواند به عنوان یک سرویس کششی عمل کند و تاخیر شبکه را هنگام تعامل با Docker Hub کاهش دهد.

برای فعال کردن این ویژگی:

عملکرد را در سطح گروه فعال کنید (Settings > Packages & Registries > Dependency Proxy > Enable Proxy).
پیشوند {CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}$ را به نام تصویر در فایل YAML خود اضافه کنید: تصویر:latest/alpine

 : ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}  .
 

در برخی موارد استفاده پیشرفته، که توسط محدودیت های شرکت هدایت می شود، ممکن است هنوز یک تصویر سفارشی لازم باشد. با این حال، مهم است که به این مسیر عاقلانه نزدیک شوید. قبل از رفتن به سراغ یک تصویر سفارشی، با رویکرد نصب ابزارهای گمشده در زمان اجرا شروع کنید.

2. یک product جدید را در یک mono-repo راه اندازی کنید

هنگام شروع یک محصول جدید، با یک تصمیم مهم روبرو می شوید:

گزینه 1: Multi-Repos - برای هر ماژول یک مخزن جداگانه ایجاد کنید.
گزینه 2: Mono-Repo - همه ماژول ها را در یک مخزن نگه دارید.
بحث در مورد این موضوع می تواند به اندازه بحث بین مونولیت ها و میکروسرویس ها پرشور باشد. در این مقاله فقط سطح را خراش می دهیم. در اینجا خلاصه ای از دو گزینه آورده شده است:

محصول Multi-Repos در GitLab:

✅ به دانش اولیه راه اندازی pipeline و مدیریت بسته نیاز دارد.
❌ درخواست ادغام چندگانه برای یک عملکرد واحد.
❌ به یک استراتژی نسخه سازی پیشرفته نیاز دارد.
❌ آزمایش یکپارچه سازی مستمر واقعی محدود یا بدون ابزار پیشرفته یا پرهزینه.
❌ تحویل مداوم یا محدود بدون ابزار پیشرفته یا پرهزینه.
❌ بدون اشتراک کش بین ماژول ها.

محصول Mono-Repos در GitLab:

❌ به دانش پیشرفته راه اندازی pipeline و مدیریت بسته نیاز دارد.
✅ یک درخواست ادغام برای هر عملکرد.
✅ بدون نیاز به استراتژی نسخه سازی.
✅ تست یکپارچه سازی مداوم واقعی را بدون ابزار پیشرفته امکان پذیر می کند.
✅ امکان تحویل مداوم بدون ابزار پیشرفته را فراهم می کند.
✅ امکان اشتراک کش بین ماژول ها را فراهم می کند.

هنگام شروع یک پروژه، به‌ویژه مونولیت‌های توزیع‌شده، بسیاری دشواری مدیریت کدهای رایج (کتابخانه‌ها) را در یک راه‌اندازی چند مخزن دست‌کم می‌گیرند. آزمایش تغییرات و رسیدگی به اعداد نسخه می تواند به سرعت طاقت فرسا شود، در حالی که این وظایف در یک مخزن تک بسیار ساده تر هستند.

انتخاب یک مخزن تک محصولی همچنین می‌تواند به جلوگیری از سایر ضد پترن های ساختاری، مانند الگوی 3 و الگوی 11 (خطوط راه‌اندازی) کمک کند.

3. CI را با فایل های محلی GitLab CI YAML شروع کنید

در بسیاری از شرکت ها، فرآیند تحویل نرم افزار اغلب شامل قالب های متمرکز GitLab است. این به ویژه در مواردی که ضد پترن DevOps Team Silo وجود دارد، صادق است.

به جای افزودن و غنی سازی دائمی قالب ها در یک مکان متمرکز برای هر نیاز جدید، توصیه می شود با ساختن CI YAML خود به صورت محلی شروع کنید. حتی می توانید زمانی که با یک مورد استفاده مشابه دوم مواجه می شوید، آن را کپی کنید. فقط پس از استفاده سوم باید YAML را متمرکز کنید.

درک این نکته مهم است که متمرکز شدن با مبادلات مختلفی از نظر کارایی همراه است. قبل از انتخاب تمرکز، مشکلاتی را که در توسعه خطوط لوله CI/CD با آن مواجه هستید، مانند حلقه بازخورد کند، در نظر بگیرید. افزودن تمرکز، چالش‌های دیگری را ایجاد می‌کند، از جمله:

انجام و فشار دادن تغییرات به مخزن دیگری در حین آزمایش در مخزن فعلی.
مدیریت عوارض جانبی بالقوه در پروژه های دیگری که از فایل های YAML یکسان استفاده می کنند.
مدیریت نسخه های قالب

با کار اولیه با فایل های YAML محلی، می توانید فرآیند توسعه را ساده کنید و درک بهتری از الزامات خاص خطوط لوله CI/CD خود به دست آورید. هنگامی که درک روشنی از این الزامات دارید، می توانید تصمیمی آگاهانه در مورد اینکه آیا تمرکز رویکرد درست است یا خیر، بگیرید.

4. اسکریپت نویسی را با دستورات خام شروع کنید

بسیاری از توسعه دهندگان وسوسه می شوند تا دستورات خام را با یک اسکریپت در خطوط لوله CI/CD خود جایگزین کنند. به عنوان مثال جایگزین کردن این:

script:
  - kustomize build devops/k8s/$MODULE/overlays/$OVERLAY | DOLLAR='$' envsubst | kubectl -n $NAMESPACE apply -f -
  - echo -e "\e[93;1mWaiting for the new app version to be fully operational...\e[0m"
  # waiting for successful deployment
  - kubectl -n $NAMESPACE rollout status deploy/$MODULE

با یک اسکریپت:

script:
  - make deploy

دلیل اصلی این تغییر، داشتن اسکریپت های ثابت برای تست های محلی و runner های راه دور در طول تست و اشکال زدایی است. با این حال، در حال حاضر ابزارهایی مانند gitlab-ci-local وجود دارد که به شما امکان می‌دهد تا کارهای محلی را اجرا کنید و تا حدی این استدلال را باطل می‌کند. علاوه بر این، کار محلی ممکن است دسترسی به همه متغیرهای ضروری را فراهم نکند.

با این حال، با کپسوله کردن دستورات در اسکریپت ها، چیزی مهمتر از آزمایش محلی از بین می رود: درک فرآیند اجرا و شناسایی دقیق مرحله ای که در آن یک خطا رخ داده است. هنگام استفاده از یک اسکریپت، خط لوله CI/CD، که در حال حاضر برای اکثر توسعه دهندگان رمزآلود است، تبدیل به یک جعبه سیاه می شود، مگر اینکه اسکریپت به دقت ساخته شده باشد تا اطلاعات دقیقی ارائه دهد. در نتیجه، هرگونه مشکل CI به نگهدارنده(های) CI منتقل می شود، حتی اگر علت اصلی در تغییرات کد باشد.

به طور کلی توصیه می شود که حداقل تعداد دستورات را در هر کار نگه دارید، که از کپسوله کردن اسکریپت ها حمایت می کند. با این حال، با استفاده از تصویر Docker مناسب، ابزارهای بسته بندی برای زبان های برنامه نویسی خود (مانند Maven، Npm، و غیره)، و منطق job های اضافی در GitLab CI (مانند متغیرها، dotenv، قوانین، قالب های جابی و غیره)، می توانید از اسکریپت های کاری طولانی اجتناب کنید. در بیشتر موارد، اگر یک اسکریپت job از چند خط بیشتر شود، شانس خوبی وجود دارد که یک ابزار خط فرمان مناسب (و رایگان) وجود داشته باشد، که باید از آن استفاده کنید.

مثل همیشه، این یک نقطه شروع توصیه شده به جای یک قانون سخت است. اگر مواردی وجود دارد که یک اسکریپت مناسب‌تر است، در صورت نیاز آن را ایجاد و استفاده کنید.

5. از گردش کار: rules استفاده کنید

به طور پیش‌فرض، هر کار روی هر رویداد Git اجرا می‌شود، مانند یک commit فشرده، یک شاخه جدید یا یک تگ جدید. در حالی که این ممکن است برای موارد استفاده ساده مناسب باشد، زمانی فرا می رسد که می خواهید از اجرای کارهای غیر ضروری در pipeline خاص اجتناب کنید. برای رفع این مشکل، می‌توانید از کلمه کلیدی workflow: rule برای تعیین زمان راه‌اندازی pipeline استفاده کنید. برای کنترل دقیق بر راه اندازی job های فردی، می توانید از کلمه کلیدی قوانین استفاده کنید.

هنوز ممکن است با کلمات کلیدی منسوخ شده در pipeline مواجه شوید. با این حال، استفاده از آنها توصیه نمی شود زیرا آنها دیگر نگهداری نمی شوند. کلمه کلیدی rule تمام ویژگی هایی را که قبلاً توسط only/ except شده بود پوشش می دهد، بنابراین توصیه می شود به سینتکس جدید مهاجرت کنید.

یکی از جنبه‌هایی که only/ except در دسترس بود و در rule وجود ندارد، توانایی نوشتن کارها یا قالب‌ها از طریق وراثت است. در حالی که rule تا حدی از طریق reference! از این امر پشتیبانی می کنند، اما آنقدر جامع نیست. در ابتدا، این جنبه مهاجرت ما به قوانین را به تاخیر انداخت. با این حال، به زودی متوجه شدیم که rule عملکرد برتری را ارائه می دهند و بار شناختی را برای خوانندگان کاهش می دهند.

به طور کلی، استفاده از workflow:rules ، رویکردی قوی‌تر و انعطاف‌پذیرتر برای کنترل اجرای کار در خطوط لوله GitLab CI/CD ارائه می‌کند.

6. کد تکراری Abstract (بدون آنچر های YAML)
Abstract یک مفهوم اساسی در هر زبان برنامه نویسی است که به ما امکان می دهد از تکرار کد جلوگیری کنیم. GitLab CI شکلی از Abstract را از طریق job templates ارائه می‌کند که در مستندات GitLab به عنوان «hidden jobs» نیز شناخته می‌شود. با استفاده از کلمه کلیدی extends و گاهی اوقات از کلمه کلیدی reference! برای ترکیب بندی، می توانیم به انعطاف لازم دست پیدا کنیم. پترن های job لزوماً نباید job های معتبر باشند، که تطبیق پذیری آنها را بیشتر می کند.

حتی وبلاگ رسمی GitLab همیشه عاری از پترن های ضد پترن نیست و به ما فرصتی می دهد تا کد تکراری زیر را از مقاله "مدیریت چندین محیط با Terraform و GitLab CI" به عنوان مثال Abstract کنیم:

fmt-dev:
  extends: .fmt
  rules:
    - changes:
        - dev/**/*

validate-dev:
  extends: .validate
  rules:
    - changes:
        - dev/**/*

build-dev:
  extends: .build
  rules:
    - changes:
        - dev/**/*

deploy-dev:
  extends: .deploy
  rules:
    - changes:
        - dev/**/*

متأسفانه، آنچه که برنامه نویس ها را در زبان های توسعه سنتی وحشت می کند، اغلب در کد CI/CD تحمل می شود. با این حال، در اینجا یک نسخه بازسازی شده است که قابل خواندن تر است:

.dev:
  rules:
    - changes:
        - dev/**/*

fmt-dev:
  extends:
    - .fmt
    - .dev

validate-dev:
  extends:
    - .validate
    - .dev

build-dev:
  extends:
    - .build
    - .dev

deploy-dev:
  extends:
    - .deploy
    - .dev

در حالی که GitLab از آنچرهای YAML به عنوان راهی برای به اشتراک گذاری بلوک ها پشتیبانی می کند، این یک رویکرد فنی و سخت به دنبال آن است که محدود به فایل YAML فعلی است. به طور کلی توصیه می شود از آنچر های YAML استفاده نکنید، زیرا تقریبا همیشه جایگزین بهتری وجود دارد.

در اینجا یک نمونه استفاده کمتر از بهینه از خود اسناد رسمی آمده است:

.default_scripts: &default_scripts
  - ./default-script1.sh
  - ./default-script2.sh

.job_template:
  &job_configuration # Hidden yaml configuration that defines an anchor named 'job_configuration'
  image: ruby:2.6
  services:
    - postgres
    - redis

job1:
  <<: *job_configuration # Add the contents of the 'job_configuration' alias
  script:
    - *default_scripts
    - ./job-script.sh

که به راحتی می توانید آن را جایگزین کنید:

.default_scripts:
  script:
    - ./default-script1.sh
    - ./default-script2.sh

.job_template:
  image: ruby:2.6
  services:
    - postgres
    - redis

job1:
  extends: .job_template
  script:
    - !reference [.default_scripts, script]
    - ./job-script.sh

به طور خلاصه، همیشه می توانید از تکرار کد در GitLab CI جلوگیری کنید. با این حال، در برخی موارد، کمی تکرار بهتر از Abstract بیش از حد مهندسی شده است. به یاد داشته باشید، توسعه دهندگان بیشتر وقت خود را صرف خواندن کد می کنند و درک GitLab CI YAML می تواند چالش برانگیز باشد.

7. از artifacts و cache استفاده کنید

ویژگی‌های artifacts و cache در GitLab CI اغلب مورد سوء استفاده قرار می‌گیرند، زیرا هیچ چیزی مانع از استفاده شما از یکی برای هدف دیگری نمی‌شود.

artifacts فایل های کوچکی هستند که تضمین می شود به کارهای بعدی در همان pipeline منتقل شوند. از سوی دیگر، cache تضمینی نیست و برای مدیریت هزاران فایل دانلود شده از اینترنت بهینه شده است. در دنیای Maven،نیز jars به عنوان artifacts در نظر گرفته می‌شوند، در حالی که مخزن محلی Maven (m2/repository) به عنوان cache عمل می‌کند. به طور مشابه، در دنیای NPM،نیز dist برای artifacts استفاده می شود و node_modules به عنوان cache در نظر گرفته می شود.

ما به شما توصیه می کنیم از artifacts و cache همانطور که در نظر گرفته شده است استفاده کنید تا از کارهای تکراری و دانلودهای غیر ضروری در جاب های خود جلوگیری کنید. با استفاده صحیح از آنها در حوزه های مورد استفاده خود، می توانید خط لوله خود را بهینه کنید و کارایی کلی را بهبود بخشید.

8. جاب ها را عاقلانه تقسیم کنید

هنگام طراحی خط لوله خود، این انتخاب را دارید که همه وظایف را در یک جاب واحد بگنجانید یا آنها را بر اساس نیازهای خود به چندین جاب تقسیم کنید.

همانطور که در این مقاله نشان داده شده است، داشتن همه وظایف در یک جاب به طور بالقوه می تواند خط لوله شما را سریعتر کند. از سوی دیگر، تقسیم وظایف به جاب ها جداگانه می‌تواند درک جریان را آسان‌تر کند.

قبل از گروه بندی وظایف در یک جاب واحد، موارد زیر را در نظر بگیرید:

ردیابی پیشرفت چالش برانگیزتر می شود.
ممکن است به یک تصویر Docker سفارشی نیاز داشته باشید که شامل همه چیز باشد، که می تواند دست و پا گیر باشد.
خطر رسیدن به حد مجاز ثبت نام runner وجود دارد.

GitLab به طور پیش فرض وظایف را موازی نمی کند، بنابراین باید به ابزارهای خارجی برای موازی سازی (مخصوصاً برای آزمایش و استقرار) تکیه کنید، در غیر این صورت، ممکن است خطوط لوله خود را کاهش دهید.
توسعه دهندگان به احتمال کمتر علت شکست در یک کار بزرگ را درک می کنند، که منجر به درخواست های بیشتر برای کمک از طرف تعمیرکاران می شود.
در صورت شکست در یک کار پوسته پوسته، کل کار باید دوباره راه اندازی شود، که در کارهای بزرگتر بیشتر اتفاق می افتد.
کارهای حجیم می توانند مانع بهینه سازی منابع runner شوند و در مجموع خطوط لوله را کندتر کنند.
 

به طور مشابه، هنگام بررسی بیش از حد جاب ها، موارد زیر را در نظر داشته باشید:

شما باید artifacts و cache خود را به دقت مدیریت کنید.
خود ذخیره سازی زمان می برد.
اجتناب از تکرار مراحل می تواند چالش برانگیز باشد، به خصوص با مدیران بسته مانند Maven که تمایل به تکرار مراحل قبلی دارند.
هرچه مراحل بیشتری داشته باشید، احتمال کندتر شدن خطوط لوله بیشتر است.

یک ضدالگوی قابل ذکر، ساخت چند مرحله ای Docker است. در حالی که ممکن است وسوسه انگیز به نظر برسد برای ایجاد artifacts جدا شده برای بازتولید کامل، این نگرانی در مورد عدم تکرارپذیری در حال حاضر هنگام استفاده از runner های Docker برطرف شده است. شما می توانید با بسته بندی و آزمایش در یک کار سنتی و سپس ارسال artifacts به ساخت تصویر به نتایج مشابهی دست پیدا کنید. این رویکرد در مقایسه با تکرار مراحل بسته بندی در کارهای جداگانه، اطلاعات و سرعت اجرایی ارزشمندی را ارائه می دهد.

هنگام تصمیم گیری در مورد نحوه تقسیم جاب ها خود به منظور بهینه سازی خط لوله خود برای کارایی و نگهداری، این عوامل را در نظر بگیرید.

9. از کلمه کلیدی needs هوشمندانه استفاده کنید

از زنجیر needs استفاده کنید اما در صورت لزوم آن را متوقف کنید
به‌طور پیش‌فرض، یک مرحله در GitLab CI تا زمانی که مرحله قبلی با موفقیت به پایان نرسد، شروع نمی‌شود. با این حال، کلمه کلیدی "needs" به شما اجازه می دهد تا از این محدودیت برای جاب ها خاص عبور کنید. این جاب ها به محض تکمیل موفقیت آمیز جاب ها "needs" آغاز خواهند شد.

این ویژگی به ویژه زمانی مفید است که چندین زنجیره از کارها می توانند به صورت موازی بدون تعامل زیاد اجرا شوند، که به طور طبیعی در mono-repos رخ می دهد. با این حال، توجه به این نکته مهم است که جاب ها در زنجیره "needs" مستقل می شوند. در صورت شکست سایر جاب ها دیگر متوقف نمی شوند. برای جلوگیری از بی ثباتی در برنامه خود، بسیار مهم است که زنجیره های needs را قبل از کارهای مصرف کننده منابع (مانند container image build/push) و/یا مراحل حیاتی (مانند استقرار) متوقف کنید. در غیر این صورت، داشتن زنجیره کامل "needs" تا زمان استقرار می تواند منجر به یک برنامه ناپایدار شود، به طوری که برخی از ماژول ها در نسخه جدید هستند در حالی که برخی دیگر هنوز مستقر نشده اند.

راه‌حل دیگر برای این مشکل، اضافه کردن جاب های همگام‌سازی است که منتظر می‌مانند تا چندین زنجیره «needs» قبل از ادامه تکمیل شوند.

از pipeline بدون مرحله اجتناب کنید

کلمه کلیدی "needs" همچنین می تواند برای جاب ها در همان مرحله اعمال شود و به شما امکان می دهد خطوط لوله بدون مرحله مشابه آنچه در Jenkins وجود دارد ایجاد کنید. با این حال، توجه به این نکته مهم است که در واقعیت، جاب ها در مرحله پیش فرض قرار می گیرند که تست است. همانطور که در این شماره ذکر شد، در حال حاضر در GitLab به این محدودیت پرداخته شده است.

با توجه به این محدودیت و عدم وجود مزیت نسبت به استفاده جزئی از «needs»، استفاده از خطوط لوله بدون مرحله را توصیه نمی کنیم. اگر هنوز دلیل موجهی برای استفاده از خطوط لوله بدون مرحله دارید، لطفاً بینش خود را در نظرات به اشتراک بگذارید!

10. از pipeline های پایین دست خودداری کنید

A. از خطوط لوله child خودداری کنید
GitLab مفهوم خطوط لوله فرزند را ارائه می دهد که به شما امکان می دهد خطوط لوله پایین دست را در همان پروژه راه اندازی کنید. خطوط لوله فرزند از نظر بافت و مراحل متغیر جدا از خط لوله اصلی اجرا می شود. حتی می‌توانید خط لوله‌های فرزند پویا ایجاد کنید، خط لوله را در یک جاب والدین اولیه ایجاد کنید و آن را در جاب بعدی فعال کنید.

در حالی که خطوط لوله فرزند امیدوار کننده است، چندین جنبه وجود دارد که آنها را به یک راه حل کمتر از ایده آل در حال حاضر تبدیل می کند:

رابط کاربری برای خطوط لوله فرزند ناهموار است. خطوط لوله فرزند به طور کامل در لیست خطوط لوله قابل مشاهده نیستند و برای دسترسی به جزئیات سمت راست خط لوله اصلی نیاز به پیمایش ناخوشایند دارند.
همانطور که در این شماره ذکر شد، خط لوله مادر نمی تواند از گزارش های خطوط لوله فرزند استفاده کند.
اگر خط لوله اصلی شکست خورده باشد، خط لوله مادر نمی تواند خط لوله فرزند را متوقف کند.
ایجاد خط لوله های فرزند پویا از نظر فنی پیچیده است، زیرا GitLab قالب داخلی ارائه نمی دهد. برای دستیابی به این قابلیت به ابزارهای شخص ثالث نیاز است.
همگام سازی مصنوعات والدین/فرزند بی جهت پیچیده است.

ب از خطوط لوله multi-project اجتناب کنید
 

GitLab قابلیت راه اندازی خطوط لوله در پروژه های دیگر را با استفاده از خطوط لوله multi-project فراهم می کند. با این حال، در نظر گرفتن محدودیت های مرتبط با این ویژگی مهم است. خط لوله اصلی کنترل محدودی بر خطوط لوله فعال دارد، از جمله عدم امکان دسترسی به artifacts . این به طور قابل توجهی امکانات را هنگام استفاده از خطوط لوله multi-project محدود می کند.

به طور کلی، نیاز به این نوع خط لوله یا از مسائل مربوط به معماری مخزن، گردش کار git یا هر دو ناشی می شود. همانطور که قبلاً توصیه شد، هنگام کار با یک محصول mono-repo، می توانید به راحتی از استفاده از خطوط لوله پایین دستی به طور کلی اجتناب کنید.

نتیجه

با پیروی از این بهترین شیوه ها، می توانید از رایج ترین ضد الگوهای GitLab CI اجتناب کنید. اگر بهترین روش دیگری دارید که فکر می کنید باید به این لیست اضافه شود، یا اگر هر یک از این انتخاب ها را به دلایل معتبر بحث برانگیز می دانید، لطفاً نظرات خود را در نظرات زیر به اشتراک بگذارید.