Git, CI/CD և zero-downtime deploy-եր

01Git-ի հիմունքներ՝ commit-ներ, branch-ներ, merge ընդդեմ rebase

Commit-ը ամբողջ նախագծի snapshot է՝ գումարած հաղորդագրություն և ցուցիչ դեպի իր ծնողը, ուստի պատմությունը snapshot-ների շղթա է։ Branch-ը պարզապես շարժական պիտակ է, որը ցույց է տալիս որևէ commit, և այդ պատճառով branch-ները էժան են։ Երբ աշխատանքի երկու գիծ պետք է միավորվեն, կա՛մ merge ես անում, կա՛մ rebase։ Merge-ը ստեղծում է նոր commit երկու ծնողով և պատմությունը պահում է ճիշտ այնպես, ինչպես եղել է։ Rebase-ը քո commit-ները նորից կիրառում է վերջին main-ի վրա՝ ստանալով ուղիղ գիծ, բայց այդ commit-ները վերագրում է նոր hash-երով։ Կանոնը՝ rebase արա քո սեփական լոկալ կամ feature branch-ը՝ այն կարգի բերելու համար, բայց երբեք rebase մի արա այն commit-ները, որոնք ուրիշներն արդեն pull են արել։ Լավ commit-ները փոքր են և կենտրոնացած, իսկ հաղորդագրությունը բացատրում է՝ ինչու, ոչ միայն՝ ինչ։

1git switch -c feature/order-export
2git add -p                       # stage hunks, review as you go
3git commit -m "Add CSV export for orders"
4git fetch origin
5git rebase origin/main           # update your branch, resolve conflicts
6git push --force-with-lease      # safe force-push of your own branch
7git log --oneline --graph -15

02Branching ռազմավարություններ՝ trunk-based ընդդեմ GitFlow

Trunk-based development-ը պահում է մեկ main branch, որը միշտ պատրաստ է release-ի։ Ծրագրավորողներն աշխատում են կարճատև branch-ների վրա, որոնք իդեալում merge են արվում մեկ-երկու օրում, իսկ անավարտ ֆունկցիոնալը թաքցնում են feature flag-երի հետևում։ Սա նվազագույնի է հասցնում ցավոտ merge-երը և բնականորեն համադրվում է continuous deployment-ի հետ։ GitFlow-ն օգտագործում է երկարակյաց develop և main branch-ներ՝ գումարած feature, release և hotfix branch-ներ։ Այն հարմար է տարբերակավորված, պլանավորված release-ներով արտադրանքի համար, օրինակ՝ mobile հավելվածներ, որոնք անցնում են store review, կամ on-premise ծրագրեր, որտեղ միաժամանակ մի քանի տարբերակ է սպասարկվում։ Վեբ հավելվածների մեծ մասի համար հաղթում է trunk-based-ը՝ կարճ pull request-ներով։ Ինչ էլ ընտրես, պաշտպանիր main-ը․ պահանջիր pull request-ներ, անցած ստուգումներ և առնվազն մեկ review, և արգելիր force-push-երը։

• Trunk-based՝ կարճ branch-ներ, feature flag-եր, deploy main-ից։
• GitFlow՝ develop + release branch-ներ, լավ է տարբերակավորված release-ների համար։
• Release tag-երը (v1.8.0) ճշգրիտ նշում են, թե ինչ է գնացել production։

03Pull request-ներ և code review

Pull request-ը branch-ը merge անելու առաջարկ է՝ գումարած դրա շուրջ զրույց։ Դրա խնդիրն է բռնել բագեր, կիսվել գիտելիքով և կոդի բազան միատարր պահել, ոչ թե ցույց տալ, թե ով է ավելի senior։ Pull request-ները պահիր փոքր, իդեալում մի քանի հարյուր տողից պակաս, որովհետև review-ի որակը կտրուկ ընկնում է չափի աճի հետ։ Նկարագրությունը պետք է ասի, թե ինչ է փոխվել, ինչու և ինչպես է թեստավորվել, իսկ UI աշխատանքի համար՝ screenshot-ներով։ Ոճն ու ֆորմատավորումը պետք է թողնել ավտոմատացմանը, որպեսզի մարդիկ կենտրոնանան տրամաբանության, տվյալների անվտանգության, security-ի, անվանումների և բացակայող թեստերի վրա։ Review անողները պետք է լինեն կոնկրետ և բարի, և առանձնացնեն արգելափակող խնդիրները առաջարկներից։ CODEOWNERS ֆայլերը փոփոխություններն ուղղորդում են այն մարդկանց, ովքեր գիտեն տվյալ հատվածը, իսկ պարտադիր status check-երը թույլ չեն տալիս որևէ բան merge անել, քանի դեռ CI-ը կարմիր է։

04Continuous integration՝ pipeline, որն աշխատում է յուրաքանչյուր փոփոխության վրա

Continuous integration-ը նշանակում է, որ յուրաքանչյուր push և pull request ավտոմատ կերպով build և թեստավորվում է մաքուր միջավայրում։ Տիպիկ pipeline-ը տեղադրում է կախվածությունները lockfile-ից, գործարկում է linter-ը և type checker-ը, unit և feature թեստերը, և կառուցում production artifact-ը։ Քայլերը դասավորիր ամենաարագից դեպի ամենադանդաղը, որպեսզի խափանումների մեծ մասը երևա մեկ-երկու րոպեում։ Քեշավորիր կախվածությունների ներբեռնումները գործարկումների միջև։ Pipeline-ը պետք է բոլորի համար նույն դարպասը լինի․ եթե այն կարմիր է, փոփոխությունը merge չի արվում։ Ստորև Node կամ Next.js նախագծի համար մինիմալ GitHub Actions workflow է․ GitLab CI-ը, Bitbucket Pipelines-ը և մյուսները օգտագործում են շատ նման գաղափարներ՝ այլ syntax-ով։ Գաղտնիքներն ապրում են CI մատակարարի secret store-ում, երբեք՝ repository-ում։

1name: ci
2on:
3  pull_request:
4  push:
5    branches: [main]
6jobs:
7  check:
8    runs-on: ubuntu-latest
9    steps:
10      - uses: actions/checkout@v5
11      - uses: actions/setup-node@v5
12        with: { node-version: 24, cache: npm }
13      - run: npm ci
14      - run: npm run lint
15      - run: npx tsc --noEmit
16      - run: npm test
17      - run: npm run build

05Deploy-ի ռազմավարություններ՝ rolling, blue-green, canary

Continuous delivery-ն նշանակում է, որ յուրաքանչյուր կանաչ build կարելի է deploy անել մեկ կտտոցով, իսկ continuous deployment-ը՝ որ այն deploy է արվում ավտոմատ։ Կարևոր է, թե ինչպես ես փոխարինում աշխատող տարբերակը։ Rolling deploy-ը load balancer-ի հետևում instance-ները փոխարինում է մեկ առ մեկ, ուստի հզորությունը մի փոքր նվազում է, բայց ծառայությունը շարունակվում է։ Blue-green-ը պահում է երկու նույնական միջավայր․ deploy ես անում պարապ մնացածի վրա (green), թեստավորում ես, ապա տրաֆիկը փոխարկում ես load balancer-ում կամ symlink-ով, և հետ փոխարկելը ակնթարթային է։ Canary-ն տրաֆիկի փոքր մասը, ասենք հինգ տոկոսը, ուղարկում է նոր տարբերակին, հետևում է սխալների մակարդակին և latency-ին, և աստիճանաբար ընդլայնում է։ Մեկ սերվերի վրա blue-green գաղափարը սովորաբար իրականացվում է release թղթապանակներով և ատոմար symlink փոխարկմամբ, կամ նոր container-ով, որը գործարկվում և health check է անցնում, նախքան proxy-ն ուղղվի դեպի այն։

• Rolling՝ էժան, աստիճանական, միաժամանակ աշխատում են երկու տարբերակ։
• Blue-green՝ ակնթարթային փոխարկում և ակնթարթային rollback, կարճ ժամանակով պետք է կրկնակի հզորություն։
• Canary՝ սահմանափակում է վնասի շառավիղը, գնահատելու համար պետք են լավ մետրիկաներ։

06Zero-downtime deploy-եր Laravel-ի և Next.js-ի համար

VPS-ի վրա Laravel-ի համար ապացուցված մոտեցումը ատոմար release-ներն են․ յուրաքանչյուր deploy գնում է նոր, timestamp-ով թղթապանակ, symlink-ներով կիսում է .env-ը և storage թղթապանակը, այնտեղ տեղադրում է կախվածությունները և կառուցում քեշերը, և միայն դրանից հետո մեկ ատոմար քայլով փոխում է current symlink-ը։ PHP-FPM-ի reload-ը մաքրում է OPcache-ը, իսկ queue:restart-ը worker-ներին ասում է ավարտել ընթացիկ job-ը և սկսել նոր կոդով։ Next.js-ի համար նույնպես build արա նոր release թղթապանակում, ապա graceful կերպով reload արա Node պրոցեսը (pm2 reload-ը cluster ռեժիմում նոր worker-ներ է գործարկում՝ նախքան հները կանգնեցնելը), կամ գործարկիր նոր container և փոխարկիր proxy-ն, երբ դրա health check-ն անցնի։ Զգույշ եղիր version skew-ից․ հին էջը բաց պահած բրաուզերները կարող են հին JavaScript chunk-եր պահանջել, ուստի նախորդ ստատիկ asset-ները որոշ ժամանակ հասանելի պահիր։

1#!/usr/bin/env bash
2set -euo pipefail
3APP=/var/www/app
4RELEASE=$APP/releases/$(date +%Y%m%d%H%M%S)
5git clone --depth 1 --branch main [email protected]:your_user/app.git "$RELEASE"
6cd "$RELEASE"
7rm -rf storage && ln -s $APP/shared/storage storage
8ln -s $APP/shared/.env .env
9composer install --no-dev --optimize-autoloader --no-interaction
10npm ci && npm run build
11php artisan migrate --force
12php artisan optimize
13ln -sfn "$RELEASE" $APP/current          # atomic switch
14sudo systemctl reload php8.3-fpm         # match your PHP version
15php artisan queue:restart

07Բազայի migration-ներ և rollback-ներ

Կոդը կարելի է հետ գլորել վայրկյանների ընթացքում, տվյալները՝ ոչ։ Ցանկացած deploy-ի ժամանակ հին և նոր կոդը մի պահ աշխատում են միաժամանակ, ուստի յուրաքանչյուր migration պետք է աշխատի երկու տարբերակների հետ էլ։ Expand and contract մոտեցումն սա դարձնում է անվտանգ։ Սյունակը վերանվանելու համար՝ նախ ավելացրու նոր սյունակը և գրիր երկուսի մեջ էլ (expand), deploy արա, հին տողերը լրացրու batch-երով, ընթերցումները փոխարկիր նոր սյունակին, և միայն հաջորդ release-ում ջնջիր հինը (contract)։ Խուսափիր մեծ աղյուսակների վրա երկար lock-երից․ index-ները ավելացրու concurrently, որտեղ բազան դա աջակցում է։ Rollback արա՝ նորից deploy անելով նախորդ release թղթապանակը կամ image tag-ը, և այդ պատճառով պահում ես վերջին մի քանիսը։ Բազայի համար նախընտրիր առաջ շարժվել ուղղող migration-ով, քան production-ում down migration-ներ գործարկել, և ռիսկային փոփոխություններից առաջ միշտ ունեցիր թարմ backup։

• Սկզբում՝ միայն ավելացնող փոփոխություններ․ նոր սյունակները nullable կամ default արժեքներով։
• Քանդող փոփոխությունները (drop, rename) միայն այն բանից հետո, երբ ոչ մի կոդ չի օգտագործում հին կառուցվածքը։
• Դիսկի վրա պահիր մի քանի նախորդ release՝ ակնթարթային rollback-ի համար։

08Ինչպես է Git-ը պահում քո աշխատանքը, և ինչու գրեթե ոչինչ չի կորչում

Git-ը բովանդակությամբ հասցեավորվող տվյալների բազա է։ Ֆայլի յուրաքանչյուր տարբերակ պահվում է որպես blob, յուրաքանչյուր թղթապանակ՝ որպես tree, որը թվարկում է blob-ներն ու այլ tree-ներ, իսկ յուրաքանչյուր commit՝ որպես օբյեկտ, որը ցույց է տալիս մեկ արմատային tree, ծնող commit-ները, հեղինակին և հաղորդագրությունը։ Յուրաքանչյուր օբյեկտի անունը նրա բովանդակության hash-ն է, ուստի նույնական ֆայլերը պահվում են մեկ անգամ, իսկ ցանկացած կեղծում փոխում է hash-ը։ Branch-ներն ու tag-երը ref-եր են՝ փոքր ֆայլեր, որոնք պարունակում են մեկ commit-ի hash։ HEAD-ը ցույց է տալիս այն ref-ը, որի վրա դու գտնվում ես։ Քանի որ commit-ները երբեք չեն խմբագրվում, այլ միայն նորերն են ստեղծվում, rebase-ը կամ reset-ը չեն ոչնչացնում հին commit-ները․ դրանք պարզապես կորցնում են իրենց պիտակը։ Reflog-ը գրանցում է HEAD-ի և յուրաքանչյուր branch-ի բոլոր դիրքերը, սովորաբար մոտ 90 օրվա համար, ուստի վատ rebase-ից կամ reset-ից հետո կարող ես գտնել հին hash-ը և branch-ը նորից ուղղել դրա վրա։ Garbage collection-ը անհասանելի օբյեկտները ջնջում է միայն այդ ժամկետից հետո։

1git reflog -15                      # where HEAD has been
2git branch rescue HEAD@{3}          # recover the state from 3 moves ago
3git reset --hard ORIG_HEAD          # undo the last rebase or merge
4git fsck --lost-found               # find dangling commits and blobs
5git cat-file -p HEAD                # see a commit object: tree, parent, author

09Հենց pipeline-ի պաշտպանությունը

CI համակարգը պահում է production-ի բանալիները, ուստի հարձակվողները թիրախավորում են հենց այն։ Ամենակարևորը չորս միջոց է։ Առաջին՝ նվազագույն իրավունքներ job-ի token-ի համար․ յուրաքանչյուր workflow-ի սկզբում բացահայտ հայտարարիր permissions-ը, լռելյայն՝ միայն կարդալու։ Երկրորդ՝ ամբողջությամբ հրաժարվիր երկարակյաց cloud բանալիներից․ GitHub Actions-ը, GitLab-ը և այլք կարող են տալ կարճաժամկետ OIDC token, որը AWS-ը, Google Cloud-ը կամ Azure-ը փոխանակում են ժամանակավոր credential-ների հետ՝ սահմանափակված մեկ repository-ով և branch-ով։ Երրորդ՝ երրորդ կողմի action-ները ամրացրու commit-ի ամբողջական SHA-ին, ոչ թե tag-ին, որովհետև tag-ը կարող է տեղափոխել ցանկացած մեկը, ով վերահսկում է այդ repository-ն։ Չորրորդ՝ զգույշ եղիր fork-երից եկող pull request-ներով գործարկվող workflow-ների հետ․ pull_request_target-ն աշխատում է հիմնական repository-ի secret-ներով, ուստի այն երբեք չպետք է checkout անի և գործարկի անվստահելի կոդ։ Production deploy-երը պետք է անցնեն պաշտպանված environment-ով՝ պարտադիր reviewer-ներով, որպեսզի կոտրված branch-ը ինքնուրույն deploy անել չկարողանա։

1permissions:
2  contents: read
3  id-token: write          # allow OIDC token for cloud login
4jobs:
5  deploy:
6    environment: production  # required reviewers + env-scoped secrets
7    runs-on: ubuntu-latest
8    steps:
9      - uses: actions/checkout@v5
10      - uses: aws-actions/configure-aws-credentials@v6
11        with:
12          role-to-assume: arn:aws:iam::111122223333:role/deploy-web
13          aws-region: eu-central-1

10Build մեկ անգամ, առաջխաղացում digest-ով և deploy-երը հերթով

Հասուն pipeline-ը artifact-ը build է անում ճիշտ մեկ անգամ՝ main-ի մեջ merge-ի պահին, պիտակում է այն commit-ի SHA-ով և push անում registry։ Այնուհետև staging-ը և production-ը deploy են անում նույն artifact-ը՝ նույնականացված իր անփոփոխ digest-ով, այնպես որ այն, ինչ թեստավորել ես, բայթ առ բայթ նույնն է, ինչ առաքում ես։ Production-ի համար նորից build անելը վերադարձնում է ռիսկը․ այդ ընթացքում կարող էին փոխվել կախվածությունը կամ բազային image-ը։ Միաժամանակ աշխատող երկու deploy կարող են սերվերը թողնել կիսով չափ մեկ, կիսով չափ մյուս տարբերակի վրա, ուստի դրանք հերթագրիր concurrency group-ով և մի չեղարկիր արդեն ընթացող deploy-ը, որովհետև կեսից կանգնեցնելն ավելի վատ է, քան ավարտին հասցնելը։ Գրանցիր յուրաքանչյուր deploy՝ commit-ով, ժամանակով և հեղինակով, որպեսզի «ի՞նչ է հիմա աշխատում production-ում» հարցն ունենա մեկ տողանոց պատասխան։ Rollback-ն այդ դեպքում պարզապես նախորդ digest-ի կրկնակի deploy-ն է։

1concurrency:
2  group: deploy-production
3  cancel-in-progress: false     # queue, never kill a running deploy
4 
5# build stage (once):
6#   docker build -t registry.example.com/web:$GITHUB_SHA .
7#   docker push registry.example.com/web:$GITHUB_SHA
8# deploy stages reuse the same tag/digest, no rebuild

11Սխեմայի փոփոխություններ մեծ աղյուսակներում՝ առանց կայքը կողպելու

Expand and contract-ը կոդը և սխեման համատեղելի է պահում, բայց յուրաքանչյուր քայլ դեռ կարող է կողպել աղյուսակը։ PostgreSQL-ում ALTER TABLE-ի ձևերի մեծ մասը վերցնում է ACCESS EXCLUSIVE lock։ Նույնիսկ արագ փոփոխությունը պետք է սպասի ցանկացած երկար transaction-ի ավարտին, իսկ քանի դեռ սպասում է, այդ աղյուսակի բոլոր նոր query-ները հերթ են կանգնում նրա հետևում, ուստի երկու միլիվայրկյանանոց migration-ը կարող է րոպեներով սառեցնել կայքը։ Պաշտպանվիր կարճ lock_timeout-ով և կրկնակի փորձերով։ Index-ները ստեղծիր CREATE INDEX CONCURRENTLY-ով, որը չի արգելափակում գրառումները, բայց չի կարող աշխատել transaction-ի ներսում, ուստի այն framework-ներում, որոնք migration-ները փաթաթում են transaction-ի մեջ, դա պետք է անջատել տվյալ migration-ի համար (Laravel-ում migration-ի withinTransaction հատկությունը դիր false)։ Հսկայական աղյուսակի վրա NOT NULL ավելացնելն ավելի անվտանգ է որպես CHECK constraint՝ ավելացված NOT VALID-ով և ավելի ուշ վավերացված։ MySQL-ում նախընտրիր ALGORITHM=INSTANT, որտեղ այն աջակցվում է, կամ gh-ost-ի նման գործիքներ մեծ վերակառուցումների համար։

1SET lock_timeout = '3s';
2ALTER TABLE orders ADD COLUMN export_status text;   -- metadata-only, fast
3 
4CREATE INDEX CONCURRENTLY idx_orders_export_status
5  ON orders (export_status);
6 
7ALTER TABLE orders ADD CONSTRAINT orders_export_status_nn
8  CHECK (export_status IS NOT NULL) NOT VALID;
9ALTER TABLE orders VALIDATE CONSTRAINT orders_export_status_nn;