GH GambleHub

خطوط لوله CI/CD: اقدامات GitHub، GitLab CI

خطوط لوله CI/CD: اقدامات GitHub، GitLab CI

1) وظیفه CI/CD و فضای پلت فرم

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

اصول کلیدی: «خط لوله به عنوان کد»، مصنوعات غیر قابل تغییر، «ساخت یک بار - اجرا بسیاری از»، «امنیت تغییر چپ»، «امتیاز چپ»، مجامع قطعی.

2) الگوهای معماری نوار نقاله

Stage-gate: build → test → security → package → چک های پس از استقرار

Fan-out/Fan-in: مجموعه های ماتریس موازی (زبان/سیستم عامل) با ترکیب نتایج.
ارتقاء: همان محصول از طریق محیط (dev → stage → prod) ترویج می شود و دوباره جمع نمی شود.

مبتنی بر تنه + شاخه های کوتاه: به حداقل رساندن رانش، چک خودکار در PR/MR

قابل استفاده مجدد: گردش کارهای قابل استفاده مجدد GitLab: شامل/child-pipelines).
GitOps (اختیاری): جداسازی «مونتاژ» و «تحویل» (محیط های بازپرداخت اعلانی مانیتور Argo CD/Flux).

3) امنیت زنجیره تامین

شناسایی: فدراسیون OIDC از دونده به ابر (بدون کلید های طولانی مدت).
اسرار: ذخیره سازی متمرکز، محدودیت زمینه، ممنوعیت ورود به سیستم.
امضای مصنوعات/ظروف (cosign/Sigstore)، تأیید امضا در کنترل پذیرش.
SBOM (CycloneDX/SPDX) و SCA، SAST/DAST/کانتینر اسکن - «دروازه اجباری».
سیاستمداران: OPA/Conftest برای IaC/manifestos، «نه آخرین»، ممنوعیت ظروف مجاز.
جداسازی دونده ها: انگیزه دونده ها در یک شبکه خصوصی، دسترسی خروجی جداگانه از اینترنت عمومی.

4) اقدامات GitHub - ساختار و شیوه ها

4. 1 ساختار گردش کار

'.github/workflows/.yml' - триггеры ('در: فشار، pull_request، برنامه، workflow_call').
گردش کار قابل استفاده مجدد برای استاندارد سازی (لاینتر، SCA، مونتاژ ظرف، استقرار).

4. 2 مثال: خط لوله چند مرحله ای با OIDC و امضای تصویر

yaml name: ci-cd

on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]

permissions:
id-token: write  # для OIDC contents: read packages: write

jobs:
build_test_matrix:
runs-on: ubuntu-latest strategy:
matrix:
node: [18, 20]
os: [ubuntu-latest]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4 with: { node-version: ${{ matrix. node }} }
- name: Cache npm uses: actions/cache@v4 with:
path: ~/.npm key: npm-${{ runner. os }}-${{ matrix. node }}-${{ hashFiles('/package-lock. json') }}
- run: npm ci
- run: npm run lint && npm test -- --ci

docker_build_sign:
runs-on: ubuntu-latest needs: build_test_matrix steps:
- uses: actions/checkout@v4
- name: Login to GHCR uses: docker/login-action@v3 with:
registry: ghcr. io username: ${{ github. actor }}
password: ${{ secrets. GITHUB_TOKEN }}
- name: Build image run:
docker build --pull --no-cache -t ghcr. io/org/app:${{ github. sha }}.
docker push ghcr. io/org/app:${{ github. sha }}
- name: Generate SBOM uses: anchore/syft-action@v0 with:
image: ghcr. io/org/app:${{ github. sha }}
format: cyclonedx-json output-file: sbom. json
- name: Cosign sign (OIDC)
uses: sigstore/cosign-installer@v3
- name: Sign image run:
cosign sign ghcr. io/org/app:${{ github. sha }} \
--yes \
--identity-token $ACTIONS_ID_TOKEN_REQUEST_TOKEN \
--rekor-url https://rekor. sigstore. dev

deploy_stage:
runs-on: ubuntu-latest needs: docker_build_sign environment:
name: stage url: https://stage. example. com steps:
- uses: actions/checkout@v4
- name: Assume cloud role via OIDC uses: aws-actions/configure-aws-credentials@v4 with:
role-to-assume: arn:aws:iam::123456789012:role/github-deployer aws-region: eu-central-1
- name: Helm deploy (canary 10%)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=true --set canary. traffic=10
- name: Smoke checks run:./scripts/smoke. sh

promote_prod:
runs-on: ubuntu-latest needs: deploy_stage environment:
name: production url: https://app. example. com concurrency: prod-release steps:
- name: Manual approval gate run: echo "Requires environment approvers in repo settings"
- name: Promote canary → 100% (blue-green)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=false
- name: Post-deploy checks & rollback on SLO breach run:./scripts/verify_or_rollback. sh
کلید های:
  • «permissions» به حداقل می رسد، «id-token: write» برای OIDC فعال است.
  • محیط هایی با تأیید و URL، «همزمانی» در برابر مسابقه محافظت می کند.
  • ورود قناری از ترافیک و بازگشت خودکار بر روی SLO.

4. 3 گردش کار قابل استفاده مجدد (به عنوان مثال تماس)

yaml jobs:
security_suite:
uses: org/.github/.github/workflows/security. yml@v1 with:
severity_threshold: high

5) GitLab CI - ساختار و شیوه ها

5. 1 ساختار اساسی

'.gitlab-ci. yml 'در ریشه ؛ نهادهای کلیدی: «مراحل»، «شغل»، «قوانین»، «نیازها»، «مصنوعات»، «محیط»، «کتابچه راهنمای کاربر».
استفاده مجدد: «شامل:» (الگوهای محلی/از راه دور)، خطوط لوله کودک/والدین برای مونورپوس های پیچیده.

5. 2 مثال: ماتریس، حافظه پنهان، امضا، محیط و مصوبات

yaml stages: [lint, test, build, security, deploy]

variables:
DOCKER_TLS_CERTDIR: "" # docker: dind acceleration
IMAGE_TAG: $CI_COMMIT_SHA

lint:
stage: lint image: node:20 script:
- npm ci
- npm run lint cache:
key: "npm-${CI_COMMIT_REF_SLUG}"
paths: [node_modules/]
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"

test:
stage: test image: node:20 parallel:
matrix:
- NODE_VERSION: ["18", "20"]
script:
- nvm install $NODE_VERSION          true
- npm ci
- npm test -- --ci artifacts:
when: always reports:
junit: report. xml

build_image:
stage: build image: docker:26. 1 services: [ "docker:26. 1-dind" ]
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG.
- docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG artifacts:
expire_in: 1 week paths: [ "sbom. json" ]
after_script:
- syft $CI_REGISTRY_IMAGE:$IMAGE_TAG -o cyclonedx-json > sbom. json

security_scans:
stage: security image: alpine:3. 20 script:
- trivy image --exit-code 0 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

deploy_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage url: https://stage. example. com on_stop: stop_stage script:
- kubectl set image deploy/app app=$CI_REGISTRY_IMAGE:$IMAGE_TAG -n stage
-./scripts/smoke. sh needs: [build_image, security_scans]
when: manual allow_failure: false

stop_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage action: stop script:
- kubectl rollout undo deploy/app -n stage

deploy_prod:
stage: deploy image: alpine/k8s:1. 30. 2 environment:
name: production url: https://app. example. com rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual allow_failure: false script:
-./scripts/canary_traffic. sh 10
-./scripts/verify_or_rollback. sh
کلید های:
  • تمام و کمال. ماتریس 'شبیه سازی مجامع ماتریس.
  • «artifacts» + گزارش های آزمون.
  • محیط هایی با «on _ stop»، کتابچه راهنمای «when: manual» برای مصوبات.
  • DIND برای ساخت یک تصویر (بهتر است - Kaniko/BuildKit در دونده k8s).

5. 3 خطوط لوله کودک و شامل مونورپو است

yaml include:
- local:.gitlab/ci/includes/security. yml
- project: org/platform/pipelines file: /k8s/deploy. yml ref: v1

stages: [prepare, component_a, component_b, deploy]

component_a:
stage: component_a trigger:
include:.gitlab/ci/component_a. yml strategy: depend

component_b:
stage: component_b trigger:
include:.gitlab/ci/component_b. yml strategy: depend

6) Monorepository و خدمات چندگانه

مالکیت مبتنی بر دایرکتوری: CODEOLDERS و تست های محدوده توسط مسیر.
ساخت افزایشی: شناسایی بسته های آسیب دیده/نمودار ؛ کش توسط کلید های مسیر و فایل های قفل.
خطوط لوله پویا: child-pipelines/« workflow _ call »فقط برای اجزای تغییر یافته اجرا می شود.
نسخه: semver برای هر ماژول، changelog در مرحله انتشار.

7) ذخیره سازی و شتاب

کش های آدرس محتوا (hashFiles/lockfile).
کش جداگانه برای وابستگی ها و مصنوعات.
تصاویر دونده پیش گرم (زنجیره ابزار، SDK).
آینه های بسته محلی (npm/pip/maven) و رجیستری کانتینر.

8) استراتژی های انتشار و بازگشت

قناری: به تدریج درصد ترافیک را افزایش می دهد ؛ توقف خودکار در طول تخریب SLO.
آبی سبز: پشته موازی، تعویض فوری.
Shadow: درخواست های تکراری بدون تاثیر بر مشتری.
ویژگی های پرچم: گسترش در سطح پرچم، سطح انتشار نیست.
Rollback: پاک کردن اسکریپت های یک دکمه، نسخه مصنوعی در ابرداده انتشار ذخیره می شود.

9) زیرساخت و GitOps

IaC: Terraform/Ansible/Helm در مخازن جداگانه مدیریت می شوند. سیاست به عنوان کد به عنوان یک دروازه.
GitOps-contour: Argo CD/Flux مشاهده repo با مانیفست محیط ؛ خط لوله فقط یک نسخه مصنوعی و به روز رسانی در Git ایجاد می کند.
مزایا: تاریخ روشن تغییرات محیطی، idempotency، رول های استاندارد از طریق Git.

10) قابل مشاهده بودن CI/CD

معیارهای DORA: نرخ تخلیه، زمان از تعهد به تولید، نرخ شکست، MTTR.
تله متری: زمان صف های شغلی، مدت زمان مراحل، نرخ ضربه کش، فرکانس تست های پوسته پوسته.
سیاهههای مربوط به امنیت: چه کسی انتشار را آغاز کرد، کدام دروازه ها تصویب شد، کدام استثنائات صادر شد.

11) کنترل دسترسی و مصوبات

حفاظت از شعبه و چک های اجباری

محیط زیست-مصوبات: جداگانه تصویب لیست در مرحله/انگیختن.
دسترسی JIT برای مراحل دستی، ورود به جلسه.
تفکیک وظایف: نقش های مختلف برای «نوشتن کد»، «تصویب»، «انتشار».

12) خطاهای مکرر (ضد الگوهای)

کلید های ابر طولانی مدت در اسرار repo به جای نقش های OIDC.
مونتاژ مصنوعات مختلف برای مرحله و تحریک (نقض «ساخت یک بار»).
آخرین عکس ها و تصاویر قابل تغییر.
انتشار اسرار در سیاهههای مربوط به مرحله (ماسک غیر فعال).
یک دونده عمومی مشترک برای استقرار تولید.
عدم وجود گیت های امنیتی (SAST/SCA/Policy) و چک های پس از استقرار.

13) چک لیست پیاده سازی (0-60 روز)

0-15 روز

پیکربندی قوانین مبتنی بر تنه، PR/MR، چک های استاتیک اجباری.

فعال کردن فدراسیون OIDC به ابر ؛ حداقل «عدم موفقیت»

ارسال دونده: عمومی - برای CI، خصوصی - برای CD.

16-30 روز

اضافه کردن SBOM، امضای تصویر ؛ خوشه - تأیید امضا.

قناری را وارد کنید/آبی سبز ؛ بازگشت خودکار توسط SLO

کش وابستگی ها و مصنوعات، تصاویر پیش گرم.

31-60 روز

مونتاژ و تحویل جداگانه (GitOps)، دروازه سیاست به عنوان کد.
معیارها و هشدارهای DORA را برای تخریب خطوط لوله ایجاد کنید.
خطوط لوله قالب (قابل استفاده مجدد/کودک) برای همه خدمات.

14) نکات قابلیت اطمینان عملی

پشتیبانی از خطوط لوله کوچک و سریع (10-12 دقیقه قبل از سیگنال PR).
کشتن آزمون پوسته پوسته شدن: برچسب های قرنطینه + رفع موازی.
مصنوعات CI را مخلوط نکنید و مصنوعات را آزاد کنید. ذخیره ابرداده (تعهد، زمان، SBOM، امضا).
اسکریپت های محلی را با مراحل خط لوله یکسان کنید (برابری dev-prod).

15) قالب برای استفاده مجدد

15. 1 اقدامات GitHub - گردش کار قابل استفاده مجدد (ساده شده)

yaml name: security-suite on:
workflow_call:
inputs:
severity_threshold:
type: string required: false default: high jobs:
sast_sca:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run:./sec/sast. sh --threshold ${{ inputs. severity_threshold }}
- run:./sec/sca. sh --format cyclonedx-json --out sbom. json artifacts: # if using actions/upload-artifact
- sbom. json

15. 2 GitLab - شامل استقرار الگو (ساده شده)

yaml
.deployment_template:
image: alpine/k8s:1. 30 script:
- helm upgrade --install $APP charts/$APP --set image. tag=$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

16) نتیجه گیری

GitHub Actions و GitLab CI مکانیسم های بالغ را برای یک کد سریع و ایمن → حلقه prod ارائه می دهند. کلید موفقیت استاندارد سازی و امنیت است: OIDC به جای کلید، امضا و SBOM، دروازه های کیفیت، یک محصول با ارتقاء، تحویل GitOps و مشاهده از طریق DORA. ساخت خطوط لوله به عنوان یک محصول: اندازه گیری، ساده سازی، سرعت بخشیدن - و انتشار آن به یک کار سخت تبدیل خواهد شد، نه یک رویداد.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

Telegram
@Gamble_GC
شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.