Sürüm Süreci

Sürüm Süreci

Denomas, dual-track deployment stratejisi uygular. Bu strateji, SaaS ve self-managed ürün hatlarının farklı sürüm döngülerini yönetir. Dağıtım süreci code.denomas.com ve code.ilimteknoloji.com GitLab altyapıları üzerinde çalışır. Otomatik Kalite Kapısı tüm süreci otomatize eder ve güvence altına alır.

Git Akışı

Standart ve kanıtlanmış branch stratejisi:

feature-branch → develop → staging → main

Dual-Track Deployment

Track 1: Sürekli Deployment (SaaS)

• Hedef: denomas.com, sibersigorta.com, cybercasko.com üzerinden sunulan SaaS hizmetler
• Sıklık: Günlük (her başarılı main merge sonrası)
• GitLab CI Aşamaları: lint → test → build → scan → deploy-staging → deploy-prod
• Süreç:
  1. MR onaylandı ve staging dalına merge edildi
  2. GitLab Runner deploy-staging aşamasını tetikler → Staging ortamına otomatik deploy
  3. Otomatik smoke testleri çalıştırılır
  4. Geliştirici main dalına merge eder (Manuel onay ile)
  5. Canary ortamına otomatik deploy → %5 trafik yönlendirilir
  6. Canary metrikler 30 dakika izlenir
  7. Başarılı → Production'a kademeli rollout (%5 → %25 → %50 → %100)
  8. Başarısız → Otomatik rollback

Track 2: Aylık Release (Self-Managed)

• Hedef: Müşteri kendi altyapısında çalıştıran kurumsal müşteriler (on-premise Denomas Denetim Otomasyon, GPMS vb.)
• Sıklık: Aylık (her ayın ilk Perşembesi)
• Süreç:
  1. Release branch oluşturulur (release/vX.Y.Z)
  2. Release candidate tag'lenir (vX.Y.Z-rc.1)
  3. QA ekibi kapsamlı test yapar (1 hafta)
  4. Release notes ve upgrade kılavuzu hazırlanır
  5. Final release tag'lenir (vX.Y.Z) ve paketlenir (Docker image + Ansible playbook)
  6. 08-HANDBOOKS/ altında release dokümantasyonu güncellenir
  7. Müşterilere bildirim gönderilir + upgrade Ansible playbook'u paylaşılır

GitLab CI Pipeline Aşamaları (Detay)

# .gitlab-ci.yml — Track 1 pipeline özeti
stages:
  - lint        # Pre-commit, ruff, mypy, eslint, yamllint
  - test        # pytest (--cov-fail-under=80), entegrasyon testleri
  - build       # Docker image oluşturma, semantic versiyon etiketi
  - scan        # Bandit, Semgrep, Trivy, GitLab SAST, lisans kontrolü
  - deploy-staging   # Ansible ile staging ortamına deploy + smoke test
  - deploy-prod      # Manuel onay (when: manual) + canary + kademeli rollout

Her aşama başarısız olursa pipeline durur ve MR merge edilemez. Detaylı .gitlab-ci.yml yapısı için CI/CD Pipeline sayfasına bakınız.

Canary Deployment

Canary, production deploy öncesi küçük bir trafik yüzdesini yeni versiyona yönlendirerek risk azaltır.

                    ┌─────────────┐
                    │  Canary     │ ← %5 trafik (ilk 15 dk)
                    │  (v2.1.1)   │    %25 trafik (15-30 dk)
┌──────────┐       ├─────────────┤
│  Caddy   │ ──→   │  Production │ ← Kalan trafik
│  LB      │       │  (v2.1.0)   │
└──────────┘       └─────────────┘

Kademeli Rollout Adımları

Canary Metrikleri

Canary metrikleri Prometheus tarafından toplanır ve Grafana panolarında gerçek zamanlı izlenir.

Rollback Prosedürü

Otomatik Rollback (Canary Aşaması)

Canary aşamasında eşik değerler aşıldığında otomatik rollback tetiklenir:

1. Caddy upstream'de canary pod'ları trafik dışına alınır (0 saniye)
2. Canary pod'ları durdurulur
3. Önceki stabil versiyon tüm trafiği almaya devam eder
4. PagerDuty üzerinden on-call mühendise bildirim gönderilir
5. GitLab'da otomatik issue oluşturulur (severity::1 etiketi ile)
6. Post-mortem süreci başlatılır (48 saat içinde tamamlanır)

Manuel Rollback (Production Aşaması)

Production'da sorun tespit edildiğinde:

# 1. Önceki stabil versiyona geri dön
ansible-playbook rollback-production.yml -e "target_version=v2.1.0"

# 2. Veritabanı migration rollback (gerekli ise)
python manage.py migrate <app_name> <previous_migration>

# 3. Doğrulama
ansible-playbook smoke-test.yml -e "environment=production"

Versiyon Politikası

• Destek: Son 2 major versiyon desteklenir
• EOL (End of Life): Major versiyon çıkarıldığından 12 ay sonra N-2 versiyonu destek dışı kalır

Release Kontrol Listesi

## Track 1 (SaaS) Release
- [ ] Tüm kalite kapıları geçildi (lint, test, sast, scan)
- [ ] Staging ortamında smoke testler başarılı
- [ ] Canary metrikleri 30 dakika boyunca stabil
- [ ] Kademeli rollout tamamlandı (%5 → %100)
- [ ] Grafana panolarında anomali yok

## Track 2 (Self-Managed) Release
- [ ] Tüm kalite kapıları geçildi
- [ ] RC tag'lendi ve QA testi tamamlandı (1 hafta)
- [ ] Release notes yazıldı (Conventional Commits'ten otomatik üretildi)
- [ ] Upgrade kılavuzu güncellendi (Ansible playbook dahil)
- [ ] Docker image'lar registry'ye push edildi
- [ ] Handbook sayfaları güncellendi
- [ ] Destek ekibi bilgilendirildi ve runbook güncellendi
- [ ] Müşteri bildirimi gönderildi (email + partner portal)
- [ ] Partner kit güncellendi (release notes + battle card)

Hotfix Süreci

Kritik güvenlik veya iş kesintisi durumları için:

1. main dalından hotfix/vX.Y.Z+1 branch'i oluşturulur
2. Fix uygulanır, tüm kalite kapıları geçilir
3. Doğrudan main ve develop dallarına merge edilir
4. Acil canary + production deploy (kademeli rollout süresi 15 dakikaya kısaltılır)
5. Track 2 müşterilerine patch release olarak sunulur

İlgili Sayfalar

• Mühendislik Genel Bakış
• CI/CD Pipeline
• İzleme ve Gözlemlenebilirlik
• Kalite Mühendisliği
• Kod Kalitesi
• Mimari Prensipler
• Mühendislik

Sayfa kaynağını görüntüle - Bu sayfayı düzenle - please contribute.