Teknik teslim: repo, ortam değişkenleri, CI ve yedek doğrulama

Teslim paketinin kapsamı: kod, yapılandırma ve sırlar

Teknik teslim, “ZIP gönderildi” cümlesiyle bitmez; alıcının üretimde ayakta kalması için gereken her parçanın izlenebilir bir envanterle taşınması gerekir. Kaynak kod deposu (repo) tek başına yeterli değildir; sürüm etiketleri, dallanma politikası, derleme komutları ve testlerin nasıl çalıştığı açıklanmadan devralınan proje ilk sprintte çökme riski taşır. Ortam değişkenleri ve API anahtarları ayrı tutulmalı ve hangi sırrın hangi ortamda yaşayacağı yazılmalıdır. Üretim sırlarının düz metin olarak sohbet içinde paylaşılması güvenlik açısından yanlış olduğu gibi teslim disiplinine de aykırıdır; kabul edilebilir yöntem parçalı paylaşım veya güvenli kasa benzeri aktarımdır.

Veritabanı tarafında şema uyuşmazlıkları, migration dosyalarının eksikliği veya yalnızca “son dump” ile yetinilmesi sık görülen hatalardır. İdeal diziliş şudur: schema değişim tarihçesi, örnek küçük veri seti (kişisel veri içermeyen), gerçek üretim dökümü için bakım penceresi planı ve bütünlük kontrolü (temel satır sayımları ve kritik tabloların doluluk eşikleri). Bu adımlar yazılı değilse alıcı “dump geldi ama beklediğim tablo yok” çaresizliği yaşar. Dump tek başına teslim sayılamaz; ilişkisel kurallar ve indeksler de hesaba katılmalıdır.

Üçüncü parti servis sözleşmeleri ve API limitleri teslim dokümanında listelenmelidir. Bir entegrasyon “çalışıyor” görünürken aslında satıcının kurumsal limitleriyle çalışıyor olabilir; devralındığında alıcı kendi kotasına taşıyınca sistem durur. Bu nedenle hangi anahtarların hangi faturalandırma hesabına bağlı olduğu önemlidir. Hesap devri mümkün değilse yeniden kayıt ve yeniden doğrulama takvimi peşinen yazılmalıdır.

Repo, commit geçmişi ve lisans uyumu

Telif ve lisans zinciri, teknik teslimin hukuki omurgasıdır. Açık kaynak bileşenlerin lisansları birbirine çakışıyorsa ticari kullanımda risk doğar; bu risk alıcıya sonradan “patlayan” bir maliyet olarak döner. Depoda gömülü büyük ikili dosyalar veya üçüncü taraf SDK’ları için yeniden indirme talimatları ayrıca eklenmelidir. Commit geçmişinin temiz olması şart değildir; fakat kritik düzeltmelerin etiketlenmiş olması arama yapılabilirliği artırır. Geçmişin tamamen silinmesi şüphe uyandırır; somut gerekçe yoksa alıcı tedirgin olur.

Mümkünse “golden” üretim etiketi ve buna karşılık gelen derleme çıktısı arşivlenmiş olmalıdır. Bu, ileride “aynı kodu aldık ama görünüm farklı” tartışmasını kısaltır. Frontend projelerinde asset optimizasyonları ve cache katmanları bazen derleme sırasında değişir; bu yüzden Node sürümü, paket yöneticisi ve kilit dosyası (lockfile) bilgisi çoğaltılabilirlik için kritiktir.

Kod incelemesi teslim sürecinin parçası olabilir. Satıcı, bilinen teknik borçları liste halinde bırakırsa inceleme odaklanır; gizlenmiş borç ise güven zedeler. Burada amaç kusursuzluk değil, keşfedilebilirlik sağlamaktır. Alıcı da incelemeyi “her satırı eleştiriyoruz” yerine risk odaklı okumalıdır.

CI/CD, dağıtım ve çalışma ortamları

Sürekli entegrasyon ve dağıtım boru hattı, modern web projelerinde üretimin kalbidir. Pipeline tanımları, gizli değişkenlerin adları ve dağıtım tetikleyicileri dokümante edilmeden teslim eksik kalır. Alıcı, pipeline’ı devralırken sık sık “token yenileme veya izin modeli” ile karşılaşır; bu yüzden ilgili kullanıcı rollerinin hangi hesaplarda tanımlanacağı açıklanmalıdır. Bulut sağlayıcılarında IAM rolleri yanlış kopyalandığında sessiz yetki genişlemesi riski doğar.

Staging ve production’ın ayrıştırılması yaygın bir iyi uygulamadır; fakat staging’de unutulan test verileri, üretimde kişisel veri içermemelidir. Veri maskeleme süreçleri veya sentetik üretim yaklaşımları varsa kısaca anlatılmalıdır. Canary dağıtımı ve geri alma düğmeleri kullanılıyorsa bunlar da teslim notlarında yer almalıdır. Dağıtımın hızı değil doğrulanabilir geri dönüş güven verir.

Loglama ve izleme altyapısı (APM, hata izleme) satıcının hesaplarında kalabilir; devralınırken maliyet ve veri saklama politikaları değişebilir. Bu geçiş planı olmadan teslim, “uygulama ayakta ama körsünüz” durumu doğurur. İzleme panolarının yeniden kurulması veya eşdeğer alternatifler için süre bütçesi alıcı modellemesine dahil edilmelidir.

Güvenlik: sırların rotasyonu ve erişim kapatma

Teslimden sonra eski sırların yaşamaya devam etmesi en tehlikeli senaryolardan biridir. API anahtarları, webhook imzaları ve ödeme tokenları için rotasyon planı yazılmalıdır; “alıcı devraldı, bitti” yaklaşımı yetersizdir. Rotasyon sırasında kesinti riski varsa bakım penceresi ve iletişim protokolü belirlenmelidir. Paylaşılmış sırlar düşman değildir ama süresi ve kapsamı sınırlanmalıdır.

Eski satıcı hesaplarının sistemde kalması, sonra kötüye kullanım veya kazara değişiklik riskini taşır. Teslim kontrol listesine “kullanıcıları kapat veya rol düşür” maddesi eklemek profesyonel bir adımdır. Çok faktörlü kimlik cihazlarının fiziksel el değiştirmesi gerekliyse bu da planlanmalıdır. Güvenlik olgunluğu yüksek projelerde asgari ayrıcalık ilkesi zorunludur.

Penetrasyon testi veya temel güvenlik taraması raporları paylaşılabiliyorsa güven artar. Paylaşılamıyorsa en azından bilinen açıkların ve geçmiş olayların özeti yazılmalıdır. Hiçbir şey yazılmaması “sorun yok” anlamına gelmez; alıcı daha kötümser varsayar.

Yedekleme, felaket kurtarma ve arşiv doğrulama

Yedeklerin nerede tutulduğu, şifreleme durumu ve geri yükleme testlerinin ne zaman yapıldığı teslim belgelerinde yer almalıdır. Yedek var gibi görünüp restore edilememesi sık yaşanır; bu yüzden küçük çaplı bir geri yükleme provası tarihi yazılı olmalıdır. Depolama maliyeti ve yaşam döngüsü (bekletme süresi) alıcıyı yakından ilgilendirir. Çevrimdışı kopya varsa erişim prosedürü açıklanmalıdır.

Felaket kurtarma planı sadece bulut sağlayıcısının SLA’sı değildir; iş sürekliliği için RTO/RPO hedefleri ve kritik bağımlılıklar listesi gerekir. E-posta hattı, ödeme uçları ve üçüncü parti SLA’ları birbirine bağlıdır. Bu kırılım teslim dokümanında yoksa alıcı ilk olayda yanlış öncelik ile müdahale eder.

Arşiv paketi oluşturuluyorsa hash doğrulaması ve tarih damgası önerilir. Bu, ileride “dosyalar değişti” iddialarında tarafsız referans sağlar. Arşiv içeriği ile repo arasındaki farklar bilinçli mi yoksa hata mı açıklanmalıdır.

Entegrasyonlar: ödeme, e-posta, kargo ve operasyon

E-ticaret veya operasyon yoğun projelerde entegrasyon sayısı fazladır. Her entegrasyon için sahiplik, faturalama ve teknik iletişim noktası yazılmalıdır. Kargo firması sözleşmesi satıcı adına ise devri mümkün mü belirsiz kalırsa teslim sonrası sevkiyat durabilir. Ödeme geçidinde “risk skoru” veya “bekleyen chargeback” birikimi varsa alıcı bunu bilmek ister çünkü nakit akış riski fiyatı etkiler.

E-posta teslimatı ve doğrulama süreçleri (SPF/DKIM/DMARC) DNS ile birlikte ele alınmalıdır. Entegrasyon dokümanında yalnızca API uçları değil, hata kodları ve yeniden deneme politikaları da kısaca yer almalıdır. “Çalışınca tamam” yaklaşımı, entegrasyonun kenar durumlarında patlar. Webhook imzaları ve gecikmeli teslim senaryoları test notlarına eklenmelidir.

Muhasebe veya ERP entegrasyonlarında para birimi ve vergi kırılımı kritik hale gelir. Bu kısımlar hukuk ve mali danışmanlıkla desteklenmelidir; teknik teslim metni en azından hangi verinin hangi sisteme aktarıldığını özetlemelidir.

Kabul testi, süre ve sorumluluk sınırları

Teslim, alıcının kabul testiyle tamamlanır; test senaryolarının taslağı önceden paylaşılmalıdır. Kritik hataların tanımı ve bunun giderim süresi için pencere yazılmalıdır. “Sınırsız destek” vaadi çoğu satıcıyı boğar; makul süre ve iletişim kanalları ile destek sınırı belirlenmelidir. Sınır yazılmayınca alıcı haklı olarak her şeyi bekler; satıcı da tükenir.

Teslim sonrası üçüncü parti servislerdeki katalog değişiklikleri, fiyat artışları veya API kırılımları satıcının kontrolünde olmayabilir. Bu harici riskler için sorumluluk paylaşımı maddesi konur. Aksi hâlde küçük bir harici değişiklik büyük suçlama doğurur. Force majeure ile teknik borç ayrımı da net olmalıdır.

Belge dışı konuşulan “şunu da hallederiz” vaatleri teslimi zehirler. Her vaat ya dokümana girer ya da resmi kapsam dışı kalır. Profesyonel ekip, vaatleri süre ve kapsamla sınırlandırır.

Dokümantasyon şablonu ve okunabilirlik

İyi dokümantasyon kısa ve tekrarlanabilir olmalıdır: kurulum, geliştirme, test, üretim dağıtımı ve acil durum başlıkları ayrılmalıdır. Uzun PDF’ler yerine depoda yaşayan Markdown dosyaları ve güncellenen bir “runbook” yaklaşımı tercih edilir. Görseller ve ekran görüntüleri değiştiğinde metin de güncellenmezse doküman yanlış güven verir.

Depoya girilen ilk okuma dosyası (README) yeni gelen mühendisin ilk 30 dakikasını hedeflemelidir: nasıl çalıştırılır, hangi sırlar gerekir, sık hatalar nelerdir. Bu bölüm eksikse devralma süresi uzar ve maliyet artar. Teknik teslimin başarısı, alıcının ilk haftada ne kadar ilerlediğiyle ölçülür.

Versiyonlama, dokümantasyon için de geçerlidir. Dosya adlarında tarih veya sürüm etiketi kullanmak karışıklığı azaltır. Özellikle çok ekip dönemi yaşayan projelerde eski notlar yanlış yönlendirir; arşivleme politikası şarttır.

Kapanış: teslim sonrası 30 günlük takip planı

Teslimin ilk 30 günü, risklerin çoğunun göründüğü dönemdir. Haftalık kısa kontrol listesi önerilir: pipeline yeşil mi, yedek restore testi yapıldı mı, izleme uyarıları anlamlı mı, DNS ve sertifikalar güncel mi. Bu ritim, satıcının sınırlı desteğini de anlamlı kullanır. Gözetimsiz izleme bile çoğu hatayı zamanında yakalar.

Teslim paketi bir kez verildi diye düşünmeyin; kritik rotasyonlar tamamlanana kadar süreç devam eder. Taraflar bu geçişi yazılı takvimde bağlar. Bu metin teknik yönlendirme sağlar; hukuki veya vergisel sonuçlar için uzman görüşü ayrı alınmalıdır. İyi dokümantasyon, düşük dram ve yüksek güven üretir; nihayetinde bu da satışın değerini tamamlar.

Minimum uygulanabilir dokunma seti (son kontrol)

Teslim öncesi son turda şu beş maddeyi yanıtlamadan paketi kilitlemeyin: üretim ve staging gizli anahtar envanteri güncel mi, kritik pipeline adımları için yedek tetikleyici tanımlı mı, depo erişimi ve dal etiketleri eşleşiyor mu, veritabanı migrasyon sırası ve geri alma yolu yazılı mı, üçüncü parti faturalandırma hesaplarında taşınma veya kapatma tarihi belli mi. Bu soruların her biri “evet” değilse teslim tamamlanmış sayılmamalıdır; çünkü eksik cevaplar ilk haftada üretim olayına dönüşür.

Son olarak, teknik teslim dokümanı bir kez oluşturulup unutulmamalıdır. Ürün yaşamaya devam ettikçe “tek doğru kaynak” güncellenmelidir. Dokümantasyonun yaşaması, sadece alıcıya değil satıcıya da fayda sağlar: destek talepleri azalır ve itibar korunur. Yaşayan doküman kültürü, satılık proje piyasasında profesyonelliğin ayırt edici işaretidir.

Ek olarak, bağımlılık grafı çıkarılabiliyorsa (paket yöneticisi veya yazılım bileşen envanteri ile) en kritik üçüncü parti bileşenler listelenmelidir. Sıfır gün açığı riski tamamen kapatılamaz; fakat hangi sürümlerin nerede kullanıldığını bilmek, olay anında yanlış yama yapmayı engeller. Bu liste ayrıca lisans uyumunun hızlı gözden geçirilmesine imkân verir.

Son bir profesyonel detay: üretim ortamında “hotfix” kültürü varsa bunun yönetişimi dokümante edilmelidir. Kimin hangi branchten ne zaman ittiği, geri alma planı ve onay kaydı tutulmuyorsa devir sonrası ilk krizde kaos çıkar. Buna küçük bir değişiklik disiplini notu eklemek, çoğu zaman mühendislik borcundan daha çok güven kazandırır.

Bu ek notlar, teslimi “mükemmel kod” iddiasına değil yönetilebilir devralmaya bağlar; profesyonel alıcı tam olarak bunu arar.

Son olarak, çok bileşenli sistemlerde “tek doğru çıkış tarihi” efsanesi sık görülür; oysa veritabanları, sıra kuyrukları, zamanlanmış işler ve dış bildirimler farklı hızlarda kapanır. Bu yüzden teslim sırasına “hayatını tamamlayıncaya kadar yan izlemede kalacak” kalemleri ayrı satır olarak eklemek, sonradan “satıcı bıraktı sandık” diyaloğunu azaltır. Yan izlemede kalma süresinin tarih olarak bitmesi gerekiyorsa bu da yazılmalıdır; yoksa sınırsız beklenti üretilir ve destek sürtüşmesi büyür.

Bu kapanış eki uyarı olarak hatırlatır: çoğu bulut ve SaaS ortamında erişim anahtarları süresiz görünse bile gerçekte süresi dolan kimlik doğrulama çıktılarının güncellenmemesi üretim duruşuna yol açar ve bu duruş sıklıkla “bir şey kırıldı” sanılarak gereksiz yere kök nedene haklı olmayan araştırma doğurur. Rotasyon tablosunun teslim sırasına yazılı girmesi, hangi sırrın hangi tarihte yenileneceğini iki tarafa da görünür kılar; böylece devir sonrası ilk haftanın yanlış suçlamalarından kaçınılır ve olay düz bir mühendislik disiplinine oturur.