Etibarlı CI/CD pipeline-in məqsədi sadəcə hər commit-dən sonra production-a deploy etmək deyil. Məqsəd odur ki, komanda hansı dəyişikliklərin harada işlədiyini, hansı build-in yayımlandığını, kim tərəfindən təsdiqləndiyini və problem yaranarsa təhlükəsiz şəkildə necə geri qayıdacağını dəqiq bilsin. CI/CD pipeline implementation services buna görə build skriptindən daha geniş işdir: kod keyfiyyəti, infrastruktur, təhlükəsizlik, database dəyişiklikləri, release prosesləri və müşahidəetmə bir delivery sistemi kimi qurulur.

Bu xüsusilə manual deploy edən, eyni məhsula bir neçə developer-in dəyişiklik göndərdiyi, staging mühitinin production-dan fərqli davrandığı və ya mobil tətbiq yeniləmələrini nəzarətsiz yayımlayan komandalar üçün vacibdir. POLADO-nun texniki dəstək və konsaltinq xidməti mövcud prosesi audit edib, məhsulun risk səviyyəsinə uyğun release engineering modelini qurmağa kömək edir.

Production-ready pipeline hansı nəticəni verməlidir?

Sağlam pipeline hər release üçün beş suala cavab verməlidir: hansı commit yayımlandı, hansı yoxlamalardan keçdi, hansı artifact deploy edildi, hansı mühitə və nə vaxt çıxarıldı, risk yarananda hansı rollback əməliyyatı icra olunacaq? Bu suallara Slack mesajları, fərdi laptop-lar və ya yaddaş deyil, avtomatlaşdırılmış deployment qeydləri cavab verməlidir.

  • Təkrarlana bilən build: eyni commit eyni dependency lock faylları və build parametrləri ilə yaradılır.
  • Dəyişməz artifact: production-da yenidən build etmək əvəzinə testdən keçmiş eyni container image, paket və ya mobil binary promotion edilir.
  • Mühit ayrılığı: development, test, staging və production üçün ayrıca konfiqurasiya, giriş hüquqları və secret-lər olur.
  • Qapılar və audit izi: kritik mərhələlər test, review və lazımi hallarda müstəqil approval olmadan keçilmir.
  • Ölçülə bilən rollback: “nəsə pis görünür” deyil, konkret error rate, checkout uğuru, gecikmə, crash və biznes metrikləri qərarı tetiklədir.

Pipeline arxitekturası: commit-dən release-ə qədər

1. Pull request yoxlamaları merge-dən əvvəl başlayır

CI merge-dən sonra yox, pull request açılan anda başlamalıdır. Minimum yoxlamalara formatlama, lint, type check, unit test, dependency və secret yoxlaması, build-in alınması daxildir. Backend və web tətbiqlərində API contract testləri; mobil tətbiqlərdə isə ən azı build, static analysis və kritik user flow testləri əlavə edilməlidir.

Yoxlamaların hamısını eyni “yaşıl” status altında gizlətməyin. Məsələn, test keçib, amma database migration yoxlaması uğursuzdursa, release riski ayrıca görünməlidir. Dependency dəyişikliklərini ayrıca yoxlamaq yeni zəif dependency-lərin merge edilməzdən əvvəl aşkar olunmasına kömək edir. GitHub-un dependency review mexanizmi pull request-də əlavə olunan və ya yenilənən dependency-lər üzrə məlum zəiflik məlumatını göstərə bilir. ([docs.github.com](https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-review?utm_source=openai))

2. Artifact bir dəfə yaradılmalı, sonra promotion edilməlidir

“Staging-də işlədi” ifadəsi yalnız production-a gedən artifact staging-də test olunubsa dəyərlidir. Pipeline container image üçün immutable digest, web build üçün versiyalı paket, Android üçün imzalanmış AAB/APK, iOS üçün versiyalanmış archive yaratmalıdır. Artifact-a commit SHA, build nömrəsi, dependency lock faylının izi və build vaxtı bağlanmalıdır.

Bu yanaşma release zamanı fərqi azaldır: production üçün ayrıca build almaq dependency registry, build agent və ya environment fərqlərinə görə gözlənilməz davranış yarada bilər. Eyni artifact-ı mühitlər arasında promotion etmək isə araşdırmanı və rollback-i sadələşdirir.

3. Mühitləri məqsədinə görə ayırın

Development sürətli inteqrasiya üçündür; ephemeral preview mühiti hər pull request üçün faydalı ola bilər; staging isə production-a mümkün qədər bənzər konfiqurasiya və inteqrasiya sınağı üçündür. Production isə yalnız qorunan branch/tag, təsdiqlənmiş artifact və məhdud girişlə dəyişdirilməlidir.

Staging-in production datasının tam kopiyası olması məcburi deyil və şəxsi məlumat riski yarada bilər. Ancaq auth provider, queue, object storage, cache, migration yolu, feature flag konfiqurasiyası və üçüncü tərəf inteqrasiyalarının davranışı real riskləri təmsil etməlidir. Yeni veb platforma və ya mobil tətbiq hazırlanarkən bu ayrılıq sonradan əlavə edilən opsiya deyil, arxitekturanın bir hissəsi kimi planlanmalıdır.

Secret-lər, girişlər və approval gate-lər

Production credential-ları repository fayllarında, mobil tətbiqin daxilində və ya shared chat mesajlarında saxlanmamalıdır. Secret-ləri environment səviyyəsində ayırın, ən az imtiyaz prinsipi ilə verin və deploy job-u approval-dan keçməyənədək production secret-lərinə giriş verməyin. GitHub Actions environment-ləri branch məhdudiyyətləri, reviewer approval-ları və environment secret-lərinin məhdudlaşdırılması üçün istifadə oluna bilər; təsdiq tələb olunan job secret-lərə yalnız approval-dan sonra çıxış əldə edir. ([docs.github.com](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments?utm_source=openai))

Approval hər deploy üçün insanın düyməyə basması demək deyil. Aşağı riskli, kiçik və yaxşı test olunmuş dəyişikliklər avtomatik staging deploy və ya hətta məhdud production rollout ala bilər. Approval gate isə aşağıdakı hallarda məntiqlidir:

  • database schema və ya data migration dəyişiklikləri;
  • ödəniş, autentifikasiya, icazə və ya maliyyə məntiqi;
  • mobil store submission və ya publik versiya dəyişikliyi;
  • infrastruktur, firewall, DNS və ya background worker dəyişiklikləri;
  • qeyri-adi error, performans və ya təhlükəsizlik riski olan release.

Approval verən şəxs release qeydlərini, test nəticəsini, migration planını, müşahidəetmə panelini və geri dönüş yolunu görməlidir. Mümkünsə, deploy-u başladan şəxs production approval-ını təkbaşına verməməlidir.

Database migration pipeline-dən kənarda qalmamalıdır

Bir çox release problemi tətbiq kodundan yox, schema uyğunsuzluğundan yaranır. Pipeline migration-ları ayrıca risk kateqoriyası kimi tanımalıdır. Praktik qayda: əvvəl genişləndirin, sonra uyğunluğu qoruyaraq kodu yayımlayın, data backfill prosesini izləyin və köhnə sahəni yalnız bütün consumer-lər keçdikdən sonra silin.

Deploy job-u migration fayllarının mövcudluğunu, onların düzgün ardıcıllığını və staging-də tətbiq olunduğunu yoxlaya bilər. Lakin destructive migration, uzun lock yaradan indeks əməliyyatı və böyük backfill üçün avtomatik “apply” təhlükəsiz default deyil. Belə dəyişikliklər üçün plan, vaxt pəncərəsi, backup/restore yoxlaması və ayrıca stop criteria olmalıdır. Bu mövzu üzrə daha dərin yanaşma üçün zero-downtime migration məzmunu ilə pipeline qaydalarını uyğunlaşdırmaq faydalıdır.

Staged rollout və rollback: sürət yox, nəzarət

Web və backend məhsullarında canary, region üzrə rollout və ya feature flag ilə aktivləşdirmə riski məhdud auditoriyada yoxlamağa imkan verir. Mobil tətbiqlərdə isə server deploy-u kimi ani rollback həmişə mümkün deyil: istifadəçinin cihazında olan binary qalır. Buna görə mobile app CI/CD setup backend compatibility, remote config, kill switch, minimum supported API contract və mağaza rollout prosesini birlikdə idarə etməlidir.

App Store Connect yeniləmələri mərhələli yayımlamağa imkan verir; Apple-ın standart phased release modeli avtomatik yeniləməsi açıq olan uyğun istifadəçilərə yeniləməni yeddi gün ərzində artıran faizlərlə çatdırır və release dayandırıla bilər. İstifadəçilərin tətbiqi manual yükləyə bilməsi səbəbilə bu, tam izolasiya vasitəsi deyil. ([developer.apple.com](https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases?utm_source=openai)) Buna görə mobil rollback planı “store-dan əvvəlki binary-ni dərhal qaytarmaq” kimi yazılmamalıdır. Plan server tərəfdə feature flag söndürməyi, problemli API davranışını geriyə uyğun saxlamağı, rollout-u dayandırmağı və zərurət olduqda düzəliş versiyasını hazırlamağı əhatə etməlidir.

Rollback qərarı üçün əvvəlcədən meyar yazın

  • 5xx error rate və ya API timeout normal səviyyədən müəyyən həddi keçir;
  • checkout, login, qeydiyyat və ya əsas əməliyyatın uğur faizi azalır;
  • yeni mobil versiyada crash-free sessions göstəricisi qəbul olunan səviyyədən aşağı düşür;
  • queue gecikməsi, database connection limiti və ya CPU/memory saturation davamlı artır;
  • maliyyə, icazə və ya məlumat bütövlüyü riski müşahidə olunur.

Rollback tək əmrlə bitmir. Komanda deploy-u dayandırmalı, traffic/flag vəziyyətini qoruyub saxlamalı, hansı artifact-ın geri qaytarıldığını qeyd etməli, migration compatibility-ni yoxlamalı və düzəlişdən sonra eyni incident-in təkrarlanmaması üçün pipeline qaydasını yeniləməlidir.

Hansı komanda hansı pipeline modelindən başlamalıdır?

Manual deploy edən kiçik komanda: əvvəlcə protected main branch, pull request check-ləri, versiyalı artifact, staging deploy və production deploy checklist qurmalıdır. Tam canary sistemi ilk addım deyil.

Bir neçə developer eyni məhsula release edirsə: artifact promotion, environment protection, release notes və deployment history prioritetdir. Kiminsə laptop-undan “tez düzəliş” production prosesini əvəz etməməlidir.

Ödəniş, şəxsi məlumat və ya kritik əməliyyatları olan məhsul: əlavə olaraq təhlükəsizlik scan-ları, audit log, separation of duties, migration approval və biznes metrikləri ilə release monitorinqi tələb olunur.

Web və mobil məhsulu birlikdə olan komanda: backend contract versiyalaşdırması, remote config, store metadata, signing credential-ları, beta distribution və public rollout qərarları vahid release planında olmalıdır.

POLADO ilə CI/CD implementation necə aparılır?

POLADO əvvəlcə mövcud kod repository-lərini, hosting/iac yanaşmasını, build müddətlərini, test coverage boşluqlarını, secret-ləri, database dəyişiklik prosesini və son incident-ləri qiymətləndirir. Sonra məhsula uyğun target delivery model hazırlanır: branch və versioning qaydaları, pipeline mərhələləri, environment siyasəti, artifact registry, approval matrisi, observability panelləri və rollback runbook-ları.

Nəticə yalnız YAML workflow deyil. Məqsəd web və mobile komandalarının yeni funksiyanı daha proqnozlaşdırılan formada buraxdığı, release statusunun izlənə bildiyi və production riski yarananda operativ qərar verdiyi işlək əməliyyat sistemidir. Manual release-lər, qeyri-sabit deploy-lar və ya aydın rollback planı olmayan məhsulunuz varsa, POLADO texniki dəstək və konsaltinq xidməti çərçivəsində CI/CD pipeline audit və implementation müzakirəsi üçün müraciət edin.