GitLab CI bilan solishtirish

GitHub Actions - yagona vosita emas. Tushunchalarni bir marta o'rgansangiz, boshqasiga o'tish bir necha soatlik ish bo'ladi. Buni ko'rsatish uchun bir xil quvurni ikki vositada yozamiz.

Atamalar jadvali #

Bir xil quvur - ikki fayl #

GitHub Actions:

name: Quvur

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

  qurish:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: sayt
          path: dist/

GitLab CI da xuddi shu narsa:

stages:
  - test
  - qurish

default:
  image: node:22-alpine
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/

test:
  stage: test
  script:
    - npm ci --cache .npm --prefer-offline
    - npm test
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

qurish:
  stage: qurish
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

Tuzilma bir xil, farqlar tafsilotda.

Asosiy farqlar #

Jenkins - eski avlod, hali ham tirik #

Jenkins CI ning klassikasi va hali ham ko'p korxonada ishlaydi. Uning mantiqi boshqacha: quvur Jenkinsfile da, Groovy tilida yoziladi.

pipeline {
    agent { docker { image 'node:22-alpine' } }
    stages {
        stage('Test') {
            steps {
                sh 'npm ci'
                sh 'npm test'
            }
        }
        stage('Qurish') {
            steps {
                sh 'npm run build'
                archiveArtifacts artifacts: 'dist/**'
            }
        }
    }
}

Yangi loyihada Jenkins ni tanlash uchun aniq sabab bo'lishi kerak - masalan, internetdan ajratilgan muhit yoki mavjud katta infratuzilma.

Vosita tanlash #

Kod qayerda saqlanadi?
├── GitHub   -> GitHub Actions (integratsiya tayyor)
├── GitLab   -> GitLab CI (integratsiya tayyor)
└── O'z serveringizda
    ├── Sodda ehtiyoj -> Gitea Actions yoki Woodpecker
    └── Murakkab ehtiyoj -> Jenkins yoki GitLab (o'zida)

Asosiy qoida: kod qayerda bo'lsa, quvur ham o'sha yerda bo'lgani qulay. Alohida CI serverini faqat aniq sabab bo'lganda qo'shing.

Ko'chib o'tish #

Quvurni bir vositadan boshqasiga ko'chirishda tartib shunday bo'ladi:

Uchinchi qadam ko'pincha e'tibordan chetda qoladi: ko'chirish paytida sirlar ikki joyda qoladi va eskisi unutiladi.

Xulosa #

• Tushunchalar hamma vositada bir xil: hodisa, job, qadam, artefakt, sir.
• GitHub Actions'da har quvur alohida fayl, GitLab'da odatda bitta .gitlab-ci.yml.
• GitHub'da runs-on mashina tanlaydi, GitLab'da image: konteyner tanlaydi.
• Shuning uchun GitLab quvurlarida setup-node kabi qadamlar uchramaydi.
• GitLab'da artefakt va kesh tilning o'zida, GitHub'da esa alohida amallar bilan.
• Jenkins eski avlod: kuchli va mustaqil, lekin serverni o'zingiz boqasiz.
• Yangi loyihada Jenkins tanlash uchun aniq sabab kerak.
• Asosiy qoida: kod qayerda bo'lsa, quvur ham o'sha yerda bo'lsin.
• Ko'chib o'tishda sirlarni faqat ko'chirish emas, almashtirish kerak.
• uses: ga kamroq bog'lansangiz, quvuringiz ko'chma bo'ladi.

Keyingi bo'limda quvurning o'zini himoyalashni - ta'minot zanjiri xavfsizligini ko'ramiz.