GitHub Actions билан CI/CD: автоматик тест ва серверга деплой

Замонавий дастурлаш дунёсида кодни ёзиш жараённинг фақат ярмидир. Ёзилган кодни текшириш, тестдан ўтказиш ва серверга жойлаштириш ҳам худди шунчалик муҳим, аммо буларнинг барчасини қўлда бажариш вақт талаб қилади ва хатоларга мойил. Айнан шу муаммони ҳал қилиш учун CI/CD методологияси пайдо бўлди. Ушбу мақолада биз CI/CD нима эканлигини, нега у замонавий жамоалар учун зарурий бўлиб қолганини ва GitHub Actions ёрдамида уни қандай амалда жорий қилишни батафсил кўриб чиқамиз.

CI/CD нима ва нега керак?

CI/CD иккита тушунчанинг қисқартмасидир: Continuous Integration (узлуксиз интеграция) ва Continuous Delivery ёки Deployment (узлуксиз етказиб бериш ёки жойлаштириш). Узлуксиз интеграция дегани ҳар бир дастурчи ўз ўзгартиришларини умумий код омборига мунтазам равишда, кўпинча кунига бир неча марта қўшади ва ҳар бир қўшилиш автоматик равишда тест ва build жараёнидан ўтказилади. Бу ёндашув коднинг турли қисмлари бир-бирига мос келмаслиги натижасида юзага келадиган конфликтларни эрта аниқлашга ёрдам беради.

Узлуксиз етказиб бериш эса тестдан муваффақиятли ўтган кодни автоматик тарзда ишлаб чиқариш муҳитига ёки серверга жойлаштириш жараёнидир. Бу жараённинг энг катта фойдаси шундаки, хатолар фойдаланувчига етиб бормасидан анча олдин, ишлаб чиқиш босқичида аниқланади. Агар сиз кичик бир ўзгартириш киритсангиз ва у бирор функцияни бузса, автоматик тестлар буни дарҳол кўрсатади ва сиз муаммони соатлар ёки кунлар эмас, балки дақиқалар ичида ҳал қиласиз. Натижада жамоа тезроқ ишлайди, код сифати ошади ва ишлаб чиқишдан фойдаланувчигача бўлган йўл қисқаради.

GitHub Actions нима?

GitHub Actions бу GitHub платформасига тўғридан-тўғри интеграция қилинган автоматлаштириш воситасидир. У сизнинг репозиторийингиздаги муайян ҳодисаларга, масалан кодни push қилиш, pull request очиш ёки белгиланган вақт жадвалига жавобан автоматик вазифаларни ишга тушириш имконини беради. GitHub Actionsнинг энг катта афзаллиги шундаки, у сизнинг кодингиз аллақачон сақланаётган жойда жойлашган, шунинг учун алоҳида хизматларни созлаш ёки интеграция қилиш билан овора бўлишингиз шарт эмас.

Ҳар бир автоматлаштириш сценарийси workflow деб аталади ва у репозиторийнинг .github/workflows папкасидаги YAML форматидаги файл орқали таърифланади. GitHub бу файлларни автоматик ўқийди ва белгиланган шартлар бажарилганда уларни ишга туширади. Бунда кодни ишга тушириш учун GitHub ўзининг булутдаги серверларини, яъни runner деб аталадиган виртуал машиналарни тақдим этади, шунинг учун сиз ўз инфратузилмангиз ҳақида қайғуришингиз шарт эмас.

Workflow тузилмаси: триггер, job ва step

Workflow файлининг тузилмасини тушуниш CI/CDни ўрганишнинг калитидир. Ҳар бир workflow учта асосий қатламдан иборат: триггерлар workflow қачон ишга тушишини белгилайди, joblar бир-биридан мустақил равишда параллел ёки кетма-кет бажариладиган вазифалар гуруҳини ифодалайди, steplar эса ҳар бир job ичида кетма-кет бажариладиган аниқ буйруқлардир. Қуйидаги мисолда энг оддий workflow тузилмаси келтирилган:

name: CI

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

Ушбу мисолда on бўлими триггерларни белгилайди, яъни workflow main тармоғига push қилинганда ёки pull request очилганда ишга тушади. jobs остидаги build эса Ubuntu серверида ишлайди ва тўртта қадамдан иборат: аввал код юклаб олинади, кейин Node.js муҳити тайёрланади, сўнгра пакетлар ўрнатилади ва ниҳоят тестлар ишга туширилади.

Серверга автоматик деплой қилиш

Тестлар муваффақиятли ўтгандан кейин кейинги мантиқий қадам кодни серверга жойлаштиришдир. Кўпинча бу SSH орқали серверга уланиб, янги кодни юклаб олиш ва хизматни қайта ишга тушириш орқали амалга оширилади. Қуйидаги мисолда тестлар ўтгандан сўнг sayt.uzдаги хостинг серверига автоматик деплой қилиш workflowи келтирилган:

name: Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to server
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /var/www/myproject
            git pull origin main
            npm install --production
            pm2 restart app

Бу ерда workflow main тармоғига ҳар сафар код push қилинганда ишга тушади ва SSH орқали серверга уланиб, энг сўнгги кодни тортиб олади, керакли пакетларни ўрнатади ҳамда иловани қайта ишга туширади. Шу тарзда сиз код ёзишдан ташқари ҳеч қандай қўлда ҳаракат қилмасдан, ўзгартиришларингиз автоматик равишда жонли серверга етиб боради.

Сирлар (secrets) билан ишлаш

Юқоридаги мисолда сиз ${{ secrets.SSH_KEY }} каби ёзувларни пайқагандирсиз. Булар GitHubнинг сирлар тизими орқали сақланадиган махфий маълумотлардир. Сервер пароли, SSH калити, API токенлари ёки маълумотлар базаси уланиш сатрлари каби махфий маълумотларни ҳеч қачон тўғридан-тўғри код ичига ёзмаслик керак, чунки бу хавфсизлик нуқтаи назаридан жуда хавфли. Бунинг ўрнига уларни репозиторий созламаларида Settings бўлимидаги Secrets and variables қисмига сақлайсиз.

Бундай сирлар шифрланган ҳолда сақланади ва фақат workflow ишга тушганда уларга мурожаат қилиш мумкин, ҳатто логларда ҳам улар автоматик равишда яширилади. Бу ёндашув сизнинг махфий маълумотларингиз код омборида очиқ ҳолда турмаслигини ва бошқа одамлар уларни кўра олмаслигини таъминлайди. Шунинг учун ҳар қандай парол ёки калитни доимо secrets орқали бошқариш энг яхши амалиёт ҳисобланади.

Матрица орқали бир нечта муҳитда тест қилиш

Кўпинча кодингиз турли версияларда ёки турли операцион тизимларда тўғри ишлашига ишонч ҳосил қилишингиз керак. Бунинг учун ҳар бир версия учун алоҳида job ёзиш ўрнига матрица стратегиясидан фойдаланиш мумкин. Матрица бир jobни бир нечта параметрлар билан автоматик равишда кўпайтиради, масалан Node.jsнинг бир неча версиясида бир вақтнинг ўзида тест ўтказиш имконини беради:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm install
      - run: npm test

Ушбу конфигурация билан GitHub Actions автоматик равишда учта алоҳида job яратади, уларнинг ҳар бири Node.jsнинг турли версиясида ишлайди. Бу сизга кодингиз кенг аудитория фойдаланадиган барча муҳитларда барқарор ишлашига кафолат беради ва версиялар ўртасидаги мослиқсизликларни эрта аниқлашга ёрдам беради.

Реал фойда ва хулоса

CI/CDни жорий қилишнинг амалий фойдаси беҳолдир. Автоматлаштириш туфайли жамоа қўлда тест ва деплой қилишга сарфланадиган соатларни тежайди, инсон хатоси эҳтимоли кескин камаяди ва код сифати барқарор юқори даражада сақланади. Энг муҳими, дастурчилар деплой жараёнидан қўрқмасдан тез-тез ва ишончли тарзда янгиланишлар чиқара оладилар, бу эса маҳсулотнинг ривожланиш суръатини сезиларли даражада оширади.

GitHub Actions бу жараённи бошлаш учун энг қулай воситалардан биридир, чунки у кодингиз билан бир жойда жойлашган ва созлаш учун мураккаб инфратузилма талаб қилмайди. Агар сиз ўз лойиҳангизни sayt.uz хостингига ёки серверга жойлаштираётган бўлсангиз, юқоридаги деплой workflowини ўзингизнинг эҳтиёжларингизга мослаб, бутун етказиб бериш жараёнини тўлиқ автоматлаштиришингиз мумкин. Бир марта созланган CI/CD қувури йиллар давомида сизга хизмат қилади ва жамоангизнинг энг қимматли ресурсини, яъни вақтни тежайди.