Release‑prosesi — versiyalar, qeydlər, SDK/spec miqrasiyaları, feature flag‑lər, rollback

1. Niyə ChatGPT App üçün release‑prosesi adi deploy‑dan daha mürəkkəbdir

Modulun əvvəlki hissəsində App‑in keyfiyyətinə və sabitliyinə necə nəzarət etməyi (loqlar, metriklər, SLO) danışmışdıq. İndi isə özümüzün release‑prosesini elə quraq ki, bu metriklər hər deployda dağılmasın.

Adi veb‑tətbiqdə hər şey nisbətən sadədir: backend və frontend‑in yeni versiyasını deploy edirsiniz — istifadəçi səhifəni yeniləyir və yeni versiyada yaşayır. Nəsə qırılsa, çox vaxt sadəcə deployu geri qaytarmaq (rollback) olur.

ChatGPT App‑də stack daha mürəkkəbdir. Minimum dörd qatınız var və onlar fərqli “həyatlar” yaşayır:

• Manifest və alətlərin sxemi (MCP tools / OpenAPI);
• İnfrastruktur: Next.js‑tətbiq və MCP/Agents/ACP serveri;
• System‑prompt və digər promptlar;
• Verilənlər: product feed, ayarlar, konfiqlər.

Problem ondadır ki, model öz “zehni aləmində” yaşayır. Çatın konteksti saatlarla və günlərlə uzana bilər. Manifest və tools təsvirləri OpenAI tərəfindən yüklənir və keşlənir və mövcud dialoqların hamısında dərhal yenilənmir. Əgər siz alətin signaturunu dəyişsəniz (məsələn, input‑sxemdən sahə silsəniz), köhnə dialoqlarda model köhnə payload göndərməyə davam edəcək, amma sizin yeni backend onu rədd edəcək. Nəticədə — 400 xətaları, söhbətdə qəribə cavablar və çox məyus istifadəçilər.

Ona görə də ChatGPT App dünyasında “release” — sadəcə “yeni Docker‑i deploy etmək” deyil. Bu, bir neçə qatın koordinasiyalı dəyişməsidir — versiyaların səliqəli idarəsi, feature flag‑lər və geri qayıtma (rollback) imkanı ilə.

2. Versiya matrisi: ümumiyyətlə nəyi versiyalaşdırmaq lazımdır

Yalnız “App 1.3” versiyasına yox, dərhal qatlar üzrə versiya matrisinə baxmaq faydalıdır. GiftGenius üçün bu təxmini belədir.

giftgenius-app 1.4.2

tools-schema v1.7

prompt v3.1

feed v2, acp v1.3

Qeyd edin ki, bunlar fərqli oxlardır. Siz tətbiqin 1.4.2 versiyasını buraxa bilərsiniz, burada tools sxemi v1.7 kimi qalır, amma prompt v3.2‑yə keçir. Bu, loqlarda görünməlidir; sonra “niyə prompt v3.2‑dən sonra checkout konversiyası düşdü?” sualını daha asan araşdıracaqsınız.

Kod üçün semantik versiyalaşdırmadan (SemVer) istifadə etmək rahatdır: MAJOR.MINOR.PATCH. MAJOR — pozucu dəyişiklik, MINOR — pozmadan yeni funksiyalar, PATCH — bugfixlər. İnterfeys versiyaları (schema, prompts) üçün məntiq oxşardır: MAJOR breaking‑change siqnalıdır.

Alətlərin interfeys versiyasını ayrıca vurğulamağa dəyər. LLM üçün bu kritikdir: əgər siz alətin kontraktını dəyişirsinizsə, amma model “düşünür” ki, kontrakt köhnədir, problemi başlayır. Odur ki, siyasət adətən belədir: MINOR‑release‑lərdə yalnız yeni opsional sahələr əlavə edirik və köhnələri nə adını dəyişirik, nə də silirik; pozucu dəyişikliklər — yalnız yeni alət vasitəsilə, məsələn suggest_gifts_v2.

Artıq qatları versiyalar üzrə ayırdığımıza görə, gəlin bu versiyalar dev‑dən prod‑a qədər release siklində necə “yaşayır” baxaq.

3. GiftGenius üçün əsas release‑flow

Əvvəlcə mərhələlər barədə razılaşaq. Yəqin ki, sizdə artıq mühitlər var (deploy haqqında moduldan), amma indi onlara release prizmasından baxaq.

Adətən aşağıdakıları ayırırlar:

• dev — lokal inkişaf, ChatGPT‑də Dev Mode, tunellər;
• staging — proda maksimum oxşar: eyni DB tipi, eyni MCP/ACP tipi, amma test verilənləri və ödənişlər sandbox‑da;
• prod — döyüş (production) mühiti; Store listinginə qoşulan prod ChatGPT App.

Proses belə görünə bilər:

flowchart TD
  A[Dev: feature/* branşı] --> B[PR → main]
  B --> C[CI: unit + contract + lint]
  C --> D[Deploy to Staging]
  D --> E[Smoke/E2E + əl ilə yoxlama]
  E --> F[Deploy to Prod]
  F --> G[Metrix və loqlara görə müşahidə]

Hər addımda “sığortalayıcılar” əlavə edirik. Dev‑mühitdə developer istədiyini edə bilər, amma hər bir main ilə birləşmə CI‑ı işə salır, o da unit/contract testləri qaçırır. Hər şey qaydasındadırsa — avtomatik olaraq staging‑ə çıxarırıq. Staging‑də qısa E2E/smoke ssenarilərini işə salırıq: məsələn, hədiyyə seçiminin tam bir axını və test ödəniş sistemində “saxta” checkout.

Və yalnız bundan sonra prod‑a deploy düyməsini basırıq. Arzuolunandır — versiya qeydilə və CHANGELOG linki ilə. Artıq prod‑da p95, error‑rate və biznes metriklərinə (tövsiyədən checkout‑a konversiya) baxmağa davam edirik. Release‑dən sonra nəsə düşürsə — aşağıda danışacağımız aydın rollback planımız olmalıdır.

4. Release notes və changelog: nəyi necə yazmalı

Əgər release qeydləriniz yoxdursa, bir ay sonra qrafikə baxıb “3 həftə əvvəl niyə bizdə checkout‑un p95‑i 2 dəfə artdı?” deyəcək və özünüzə “bilmirəm, amma böyük release olmuşdu” cavabını verəcəksiniz. O qədər də yaxşı strategiya deyil.

Adətən ən azı iki tip qeyd olur.

Daxili changelog — texniki. O, developerlərə, SRE və koda baxan hər kəsə lazımdır. Orada hansı funksiyalar əlavə olunub, hansı buglar düzəldilib, breaking changes olubmu yazılır. Formatı Keep a Changelog kanonundan götürmək olar: Added, Changed, Fixed, Removed bölmələri.

Xarici release notes — istifadəçilər və Store üçün oxunaqlı qeydlər. Burada “MCP SDK‑nı 0.4 → 0.5 miqrasiya etdik” yazmaq lazım deyil; daha yaxşıdır “Thanksgiving bayramı üçün tövsiyələr əlavə etdik”, “Bəzi hədiyyələrin səbətə əlavə olunmamasına səbəb olan nadir bug düzəldildi” yazmaq.

GiftGenius üçün CHANGELOG.md parçası nümunəsi:

## [1.4.0] - 2025-11-20
### Added
- Yeni tool `suggest_gifts_v2` maraq təqlərinin dəstəyi ilə.
- Yeni system-prompt üçün A/B testi (flag: GG_PROMPT_V3).

### Changed
- ACP checkout səhvlərinin emalı yaxşılaşdırıldı (daha dost mesajlar).

### Fixed
- Şəkilsiz məhsulların tövsiyələrdən yox olmasına səbəb olan bug düzəldildi.

Promptun versiyasını da haradasa yaxınlıqda saxlamaq faydalıdır: hətta system‑prompt faylının sadə commit hash‑i belə sonradan xatırlamağa kömək edir: “aha, b3f9c2d promptundan sonra istifadəçilər “Almaq” düyməsinə daha az basmağa başlayıblar”.

5. SDK və spesifikasiyaların miqrasiyası: sürətlə dəyişən ekosistemdə necə yaşamalı

Apps SDK, MCP və Agents ətrafındakı ekosistem sürətlə inkişaf edir: yeni SDK versiyaları, MCP protokolunda dəyişikliklər, ACP yeniləmələri və s. Bu, yaxşıdır (imkanlar yaranır), amma ağrılı da ola bilər: nəsə də tez qırıla bilər.

Versiyaları pin etmək və “release günündə yenilənmirik”

İlk sadə tövsiyə: asılılıqların versiyalarını sabitləyin. ^0.4.0 yox, 0.4.0. API‑ni tez‑tez sındıran SDK‑lar (MCP/Agents/Apps SDK) üçün bu xüsusilə kritikdir. Bu mövzu üzrə araşdırmalarda ayrıca “SDK fatigue” — daimi uyğunsuz yeniləmələrdən yorulma fenomeni qeyd olunur; xüsusən də versiyaları üzən qoyanlar (məsələn, ^0.4.0) bir gün npm installdan sonra qəfil bir yığın səhv tutur.

Kiçik nümunə:

// package.json (fraqment)
{
  "dependencies": {
    "@modelcontextprotocol/sdk": "0.4.2",
    "@openai/applications-sdk": "0.3.1"
  }
}

İkinci tövsiyə: eyni release‑də həm biznes funksiyalarını, həm də böyük SDK miqrasiyalarını toplamayın. Əgər MCP SDK‑nı 0.3.x‑dən 0.4.x‑ə yeniləmək lazımdırsa, daha yaxşısı ayrıca texniki release etməkdir: əvvəlcə SDK yenilənir, testlər və stabilizasiya edilir, sonra — yeni checkout flow.

SDK miqrasiyası strategiyası

Adətən məntiqli plan belə görünür:

Dev‑mühitdə ayrıca upgrade/mcp-sdk-0.4 branşı yaradırsınız. Asılılığı yeniləyirsiniz, kodu düzəldirsiniz, bütün unit/contract testləri işə salırsınız, GiftGenius‑un əsas axınını lokal olaraq Dev Mode vasitəsilə yoxlayırsınız.

Sonra bu branşı ayrıca staging URL‑ə deploy edirsiniz və onun üzərində E2E/smoke testləri qaçırırsınız. Hətta kiçik bir yükləmə testi də etmək olar: ardıcıl 50–100 dəfə suggest_gifts çağırışı.

Hər şey qaydasındadırsa — main‑ə merge edirsiniz, əsas staging‑ə deploy edirsiniz, bir daha smoke qaçırsınız və yalnız sonra — prod‑a çıxırsınız.

Yoxdursa — aydın rollback‑iniz var: sadəcə bu branşı merge etmirsiniz və ya onu geri alırsınız. SDK miqrasiyalarını məhsul release‑lərindən ayırmağın məğzi də budur.

Tools və API sxemlərinin miqrasiyaları

Ən xoşagəlməz hissə — interfeys dəyişiklikləridir: model onlar barədə dərhal xəbər tutmur. Bu mövzuda araşdırmalar xüsusilə mühüm qaydanı vurğulayır: “Genişlət, amma sındırma” (additive‑only). Əgər suggest_gifts‑ə yeni interests: string[] arqumentini əlavə etmək lazımdırsa, onu məcburi yox, opsional edin; köhnə ssenarilər işləməyə davam edəcək.

Zod sxeminin giriş məlumatları üçün təkamül nümunəsi:

// v1
const suggestGiftsInputV1 = z.object({
  recipientName: z.string(),
  budget: z.number()
});

// v1.1 (opsional sahələr əlavə olundu)
const suggestGiftsInputV1_1 = suggestGiftsInputV1.extend({
  interests: z.array(z.string()).optional(),
  occasion: z.string().optional()
});

Diqqət edin: mövcud sahələrə toxunmuruq, yalnız genişləndiririk.

Əgər həqiqətən kontraktı sındırmaq lazımdırsa (məsələn, budget‑i minBudget + maxBudget ilə əvəz etmək), daha yaxşısı yeni suggest_gifts_v2 aləti etmək və təsvirində bunun təkmilləşdirilmiş versiya olduğunu göstərməkdir. Köhnə API‑ni “deprecated” kimi saxlayıb tədricən söndürmək olar — modelin və istifadəçilərin keçdiyinə əmin olduqdan sonra.

Verilənlərin miqrasiyası: product feed və ACP

Artıq SDK və tools sxemlərinin miqrasiyalarını danışdıq. Product feed də kontraktdır. SKU, valyutalar, lokallaşdırmalar formatını dəyişsəniz, bunu koordinasiyalı etmək lazımdır: həm feed sxemini, həm MCP/ACP‑də emalı, həm də istənilən ön emalçıları yeniləmək. ChatGPT App üçün commerce sənədlərində qeyd olunur ki, feed‑dəki səhvlər (qırıq sahələr, dublikatlar, qəribə qiymətlər) kod ideal olsa belə tövsiyələrin keyfiyyətini məhv edə bilər.

Tipik yanaşma:

1. Əvvəlcə yeni sahələri feed sxeminə opsional kimi əlavə edin və GiftGenius‑u onlar varsa istifadə etməyə öyrədin.
2. Sonra feed quran pipeline‑ı yeniləyin ki, bu sahələri doldurmağa başlasın.
3. Feed validatorunu (verilənlər üçün contract testləri) işə salın və yalnız bundan sonra bu sahələrdən məntiqdə asılı olmağa başlayın.

6. Feature flag‑lər: deploy‑u release‑dən ayırırıq

Feature flag‑lər — ChatGPT App dünyasında sağ qalmağın əsas alətlərindən biridir. Əsas fikir sadədir: kodu deploy edirsiniz, amma yeni funksionallığı dərhal açmaq məcburi deyil. Əvvəlcə o “flag altında” yaşayır — yalnız developerlər üçün aktivdir, ya da istifadəçilərin 1 %‑i üçün, ya da ümumiyyətlə söndürülübdür.

Bu xüsusilə vacibdir, nə vaxt ki:

• yeni tövsiyə alqoritmini çıxarırsınız;
• system‑promptu dəyişirsiniz (bu, modelin davranışını radikal dəyişə bilər);
• bahalı və ya yavaş aləti qoşursunuz;
• yeni checkout flow ilə eksperiment aparırsınız.

Env dəyişənləri ilə sadə flag

Minimumda feature flag‑i mühit dəyişəni ilə etmək olar:

// lib/features.ts
export const isNewRecoEnabled =
  process.env.NEXT_PUBLIC_GG_NEW_RECO === "1";

Sonra MCP alətinin kodunda bunu belə istifadə edə bilərsiniz:

if (isNewRecoEnabled) {
  return runNewRecoAlgorithm(input);
}
return runOldRecoAlgorithm(input);

Bu yanaşmanın üstünlüyü — sadəlikdir. Mənfi cəhəti — flagləri runtime‑da çevirmək çətindir: yeni mühiti deploy etmək və ya heç olmasa yenidən init etmək gərəkir.

Kontekstlə mərkəzləşdirilmiş helper

Bir az daha yetkin yanaşma — yalnız qlobal flaqları yox, həm də istifadəçi kontekstini (tenant, seqment, A/B qrup) nəzərə alan mərkəzləşdirilmiş helperə sahib olmaqdır.

// lib/featureFlags.ts
type Feature = "new-reco" | "checkout-v2";

type Context = { userId: string; tenantId?: string };

export function isFeatureEnabled(
  feature: Feature,
  ctx: Context
): boolean {
  // burada məntiq ola bilər: env, DB, xarici flag xidməti
  if (feature === "new-reco") {
    return process.env.GG_NEW_RECO === "1";
  }
  return false;
}

MCP handler‑də:

const enabled = isFeatureEnabled("new-reco", { userId });
const result = enabled
  ? await runNewReco(input)
  : await runOldReco(input);

Gələcəkdə hər hansı xarici flag xidmətini (LaunchDarkly, Statsig və s.) qoşsanız, yalnız isFeatureEnabled reallaşdırmasını dəyişmək kifayətdir, bütün kodu yox.

GiftGenius üçün ssenari nümunələri

System‑prompt üçün A/B testi. Siz PROMPT_V2 yaradırsınız və onu yalnız müəyyən siyahıdakı tenantId‑yə sahib istifadəçilərin 10 %‑i üçün aktiv edirsiniz. Bu zaman MCP alətləri və vidcet dəyişmir, siz isə konversiyanı müqayisə edirsiniz.

Bahalı alət üçün kill‑switch. Tutaq ki, siz çətin xarici sorğu edən bir alət hazırlamısınız (məsələn, baha başa gələn hər hansı tövsiyə ML modeli). Əgər həmin xarici xidmət çökməyə başlasa və ya qəfil bahalaşsa, GiftGenius‑u tam dayandırmadan onu bir saniyədə söndürmək istəyəcəksiniz. Feature flag — ən sadə yoldur.

Yeni checkout flow‑unun tədricən rollout‑u. Checkout v2‑ni əvvəlcə yalnız şirkət əməkdaşları və bir neçə etibarlı müştəri üçün aktiv edirsiniz. Metriklər qaydasındadırsa — auditoriyanı genişləndirirsiniz, hər kəs üçün açanadək.

7. Rollback: hər şey “yananda” necə tez geri qayıtmalı

Hətta ideal testlər və flaglərlə də nəsə qırılar. Vacib olan odur ki, aydın strategiyanız olsun: xətaların sıçrayışını və ya metriklərin düşməsini gördükdən sonra ilk 5–15 dəqiqədə nə edirsiniz.

Koda sürətli rollback

Problem sırf texniki bir bagdırsa (NPE, səhv dəyişən, xarici xidmətin yanlış URL‑i), adətən deployu əvvəlki versiyaya qaytarmaq kifayətdir. Məsələn, Vercel‑də əvvəlki deployment‑ə anlıq rollback var.

Sizin vəzifəniz — hansı deploymentin hansı versiyaya uyğun gəldiyini və onu necə geri qaytarmağı həmişə bilməkdir. İdeal halda bu, on‑call üçün README‑də təsvir olunub: “əgər 1.4.0 release‑indən sonra hər şey yanırsa, X deploymentinə geri qayıdın”.

İkinci sürətli qolu — feature flag‑lərdir. Yalnız yeni funksiya (checkout-v2) çökübsə, bütün release‑i dərhal geri qaytarmaqdansa, onu flaglə söndürmək daha asandır.

Riskli dəyişikliklər: manifestlər və sxemlər

Manifestlər və sxemlərlə iş çətindir. Əgər siz Store‑a alətlərin səhv sxemi ilə yeni manifest yükləmisinizsə və onu OpenAI artıq təsdiqləyibsə, rollback günlər çəkə bilər. Səbəb sadədir: hər bir manifest dəyişiyi də OpenAI review‑undan keçir. Müxtəlif Store analizlərində manifest və sxem dəyişiklikləri “riskli” release‑lər kimi qeyd olunur — onları xüsusilə diqqətlə hazırlamaq və test etmək lazımdır.

Ona görə daha yaxşıdır ayırmaq:

• təhlükəsiz release‑lər: MCP/Next.js kod dəyişiklikləri, prompt düzəlişləri, flag arxasında gizlənmiş yeni funksiyalar;
• riskli release‑lər: tools siyahısında, input/output sxemlərində, ACP kontraktlarında dəyişikliklər.

“Riskli” release‑ləri ayrıca, əlavə yoxlamalarla və bəlkə də əvvəlcə yalnız Dev Mode və staging App vasitəsilə (Store‑da dərc etmədən) yaymaq lazımdır.

Verilənlər və feed üçün rollback

Verilənlərlə vəziyyət daha da çətindir (və daha ağrılıdır). Əgər product feed‑i yeni sxemə miqrasiya etdiniz və bu zaman köhnə sahələri sildinizsə, hər şeyi geri qaytarmaq həmişə asan deyil. Buna görə verilənlər miqrasiyaları idempotent və geri dönən olmalıdır: ya köhnə nüsxəni saxlayırsınız, ya da miqrasiyanı iki addımda edirsiniz (əvvəlcə verilənləri dublikatlayırsınız, sonra oxunuşu çevirirsiniz).

Sadə yanaşma — köhnə və yeni sahələri müəyyən müddət paralel saxlamaq və onlar arasında feature flag vasitəsilə keçid imkanı verməkdir. Nəsə çökürsə — sadəcə köhnə oxunuşa qayıdırsınız.

8. GiftGenius üçün release‑prosesinin mini‑dizaynı

Gəlin yuxarıda danışdığımız (versiyalar, SDK miqrasiyaları, feature flag‑lər, rollback) hər şeyi bir praktik ssenaridə toplayaq.

Tutaq ki, siz 1.4.0 release‑ini hazırlayırsınız, burada:

• genişləndirilmiş input ilə yeni suggest_gifts_v2 alətini əlavə edirsiniz;
• yeni system‑promptu istifadəçilərin bir hissəsi üçün aktiv edirsiniz;
• MCP SDK‑nı 0.3 → 0.4 yeniləyirsiniz;
• product feed formatını dəyişirsiniz (tags sahəsini əlavə edirsiniz).

Məntiqli plan belə görünərdi.

Əvvəlcə ayrıca texniki release 1.3.1: MCP SDK yenilənməsi + minimal kod düzəlişləri, sxemlər və funksiyalar dəyişmədən. CI, staging, smoke testləri qaçırırsınız. Hər şey stabil olsa — bununla bir neçə gün yaşayırsınız.

Sonra feature/reco-v2 branşı. Burada suggest_gifts_v2‑ni yeni alət kimi əlavə edirsiniz (köhnə suggest_gifts qalır). Onun input sxemi yalnız yeni opsional sahələrin əlavə olunması istiqamətində genişlənir. Yeni system‑promptu hazırlayırsınız, amma onu GG_PROMPT_V3 flagi ilə örtürsünüz. ACP/feed‑də tags adlı yeni sahə əlavə edirsiniz, amma opsional; oxunuşu elə edirsiniz ki, bu sahə olmadıqda da hər şey işləməyə davam etsin.

CI‑a bir neçə yeni contract testi əlavə edirsiniz: suggest_gifts_v2‑nin köhnə və yeni payload qəbul etməsi, tags olan feed‑in valid olması, amma tags olmadan köhnə qeydlərin də serveri sındırmaması.

main‑ə merge‑dən sonra:

• CI unit/contract testləri qaçırır;
• staging‑də yeni alət üzərindən 1–2 E2E ssenari işə salınır;
• feature flag vasitəsilə yeni prompt və aləti yalnız test tenant üçün aktiv edirsiniz.

Metriklərə baxırsınız: alətin p95‑i, error‑rate, checkout‑a konversiya. Hər şey qaydasındadırsa — flagi daha çox istifadəçiyə genişləndirirsiniz. Və yalnız bundan sonra, sabitliyə əmin olandan sonra (lazımdırsa) Store üçün manifesti və tətbiqin promo təsvirini yeniləyirsiniz.

Yolda haradasa nəsə qırılarsa — necə rollback edəcəyinizi bilirsiniz: ya flagi söndürürsünüz, ya deploymenti geri qaytarırsınız, ya da ən ekstremal halda manifest versiyasını geri çevirirsiniz (amma bu, ümumiyyətlə yol verməməyə çalışdığımız haldır).

9. ChatGPT App release‑prosesində tipik səhvlər

Səhv №1: vahid “App versiyası” əvəzinə versiya matrisi yoxdur.
Yalnız “GiftGenius v1.4” olduqda, amma tools sxemi, promptlar və product feed versiyaları heç yerdə qeyd olunmadıqda, sonra “checkout hansı dəyişikliyimizdən sonra düşdü?” sualına cavab verə bilməyəcəksiniz. Versiyaları qatlar üzrə ayırın və onları strukturlaşdırılmış loqlarda qeyd edin.

Səhv №2: tools‑da pozucu (breaking) dəyişikliklər yeni ad/versiya olmadan.
Ən ağrılı şey: input sxemində sahənin adını dəyişdiniz və ya sildiniz, alətin adını dəyişmədən. Köhnə çatlarda model köhnə payload göndərir, backend 400 qaytarır, GPT cavabda “halyusinasiya” etməyə başlayır, istifadəçilər heç nə başa düşmür. Hər hansı pozucu dəyişikliyi yeni alət (foo_v2) və ya yeni API versiyası ilə edin, köhnə interfeysi isə keçid dövründə saxlayın.

Səhv №3: SDK‑nı “yolda” funksiyaya doğru yeniləmək.
Klassika: siz yeni biznes funksiyası əlavə edirsiniz və yolüstü @modelcontextprotocol/sdk‑ni 0.3‑dən 0.5‑ə “əl dəydi təzələnsin” deyə yeniləyirsiniz. Nəticədə nəsə qırıldıqda, günahın yeni kodda, yeni sxemdə, yoxsa yeni SDK‑da olduğu başa düşülmür. SDK miqrasiyalarını ayrıca texniki release‑lərlə edin — aydın test planı və rollback imkanı ilə.

Səhv №4: feature flag‑lərin və instant kill‑switchlərin olmaması.
Yeni tövsiyə alqoritmini dərhal 100 % istifadəçiyə çıxarmaq — hər şey yaxşı gedənə qədər “əyləncəlidir”; sonra qəribə nəticələr verməyə və ya xarici xidməti yıxmağa başlaya bilər. Feature flag olmadan yeganə alətiniz — tam release rollbackidir, bu isə yalnız yeni funksiyanı deyil, onlarla günahı olmayan yaxşılaşdırmanı da geri ala bilər. Heç olmasa env və ya kiçik konfiq vasitəsilə sadə flaglər edin.

Səhv №5: manifestin “ani” yenilənməsinə ümid.
Geniş yayılmış yanlış təsəvvür — tools və ya openapi.yaml dəyişən kimi modelin dərhal yeni sxemdən xəbər tutacağını düşünməkdir. Praktikada manifest və tools təsvirləri keşlənir və artıq açıq çatlardakı həyatları uzun ola bilər. Bunu görməzdən gəlmək qeyri‑aşkar baglara gətirir: yeni çatlardakı hər şey işləyir, köhnələrdə — çökür. Sxem dəyişikliklərini bu davranışı nəzərə alaraq planlayın və Store‑da dərcdən əvvəl Dev Mode və staging vasitəsilə test edin.

Səhv №6: aydın rollback planının və release sənədləşməsinin olmaması.
Komandanızda “releası 5 dəqiqəyə necə geri qaytarırıq?”, “hansı versiyaya qayıdacağıq?”, “köhnə feed sxeminə necə dönəcəyik?” suallarına cavab verən yoxdursa — deməli rollback sizdə yoxdur. On‑call üçün qısa, amma konkret ssenari olmalıdır: hansı düymələri basmaq, hansı dəyişənləri dəyişmək və rollbackin işə düşdüyünü haradan görmək.

Səhv №7: release notes olmadan “lal” release‑lər və metriklərlə bağın olmaması.
Heç bir changelog olmadan release çıxarmaq — bir neçə aydan sonra falçılıq rejimində yaşamaq deməkdir. P95 qəfil artanda, konversiya düşəndə, “o zaman nə dəyişmişdi?” deyə təxmin edəcəksiniz. Heç olmasa minimal release qeydləri yazmaq və onları deploy tarixləri və versiyalarla bağlamaq yalnız keyfiyyət auditini yox, bütün komandanın həyatını da asanlaşdırır.