Müşteriler ve ajanslar için kaynak kod devri kontrol listesi

Kaynak kod devriyle ne elde edilmeli

Kaynak kod devri, projenin “ajansın çalıştırdığı bir şey” olmaktan çıkarak “müşterinin sahip olabileceği bir şey” haline geldiği andır. Net bir devri yoksa, sık görülen sorunlar hızlıca ortaya çıkar: uygulama sadece bir dizüstünde derlenir, üretim bir gizli anahtara bağlıdır ve kimse o anahtarı bulamaz veya küçük bir güncelleme günler süren tahmin işine dönüşür.

Her kaynak kod devri kontrol listesinin amacı basittir: devrin ardından, müşteri ürünü inşa edebilmeli, çalıştırabilmeli ve ajansı çağırmaya gerek kalmadan dağıtabilmelidir. Bu “asla destek yok” demek değildir. Temeller tekrarlanabilir ve belgelenmiş olmalıdır ki bir sonraki kişi güvenle işe koyulsun.

Hangi teslimatların sayılacağı açık olmalıdır. En azından, eksiksiz bir devri genellikle şunlar içerir:

• Tam repository (dağıtım dosyaları ve migration betikleri dahil)
• Temiz bir makine için çalışan kurulum dokümanları
• Erişim devri (hesaplar, izinler ve sistemin nerede çalıştığı)
• Rutin işler için bir runbook (dağıtım, geri alma, yedekler, loglar)
• Müşterinin referans alabileceği son “bilinen-iyi” versiyon etiketi veya anlık görüntü

Kapsam, içerik kadar önemlidir. Bazı devriler yalnızca tek bir ortamı (örneğin üretim) kapsar. Diğerleri dev, staging ve üretimi ayrı ayar ve süreçlerle içerir. Hangi ortamların dahil olduğunu adlandırmazsanız, insanlar farklı şeyler varsayar ve kesintiler bu yüzden olur.

Başarıyı tanımlamanın pratik bir yolu doğrulama testidir: uygulamayı inşa etmeyen bir kişi kodu dışa aktarabilir (örneğin Koder.ai gibi bir platformdan), dokümanları izleyip ortam değişkenlerini ayarlayabilir, migrationları çalıştırabilir, derleyip üzerinde anlaşılan ortama deploy edebilir.

Bu kontrol listesi teknik hazır olmayı hedefler: ortam değişkenleri, gizli anahtar rotasyonu, veritabanı migrationları, dağıtım betikleri ve derleme doğrulaması. Hukuki terimler, sözleşmeler, fikri haklar veya ödeme anlaşmazlıkları bu kapsamda değildir. Onlar da önemlidir ama ayrı bir anlaşmada yer almalıdır.

Dışa aktarmadan önce: sahiplik ve zamanlamada anlaşın

Temiz bir devri, herhangi bir dışa aktarma olmadan önce başlatılan hazırlıklar başlatır. Kim neye ve ne zaman sahip olacak konusunda anlaşılırsa, son dakika sürprizlerinden—kırık dağıtımlar, ödenmemiş barındırma, eksik erişim—kaçınılır.

Devri tarihi ve kısa bir dondurma penceresi belirleyin

Bir devri tarihi seçin ve yalnızca acil düzeltmelerin girebildiği kısa bir dondurma penceresi (genellikle 24–72 saat) tanımlayın. Bu, dışa aktarılan kodla çalışan sistemin senkron kalmasını sağlar. Dondurma sırasında bir hotfix gerekiyorsa, tam olarak ne değiştiğini yazın ve bunun son dışa aktarmaya dahil edildiğinden emin olun.

Hesapların ve faturalamanın sahipliğini netleştirin

DNS, bulut barındırma ve ücretli hizmetlerin devri ardından kimin sahibi olacağına karar verin. Bu sadece evrak işi değil. Faturalama ajans kartında kalırsa, hizmetler sonradan bildirim olmadan durdurulabilir.

Somutlaştırmak için hızlı bir yol:

• DNS, barındırma ve e-posta için hesap sahibini adlandırın
• Devri tarihinden itibaren her faturayı kimin ödeyeceğini onaylayın
• Hesapların transfer edilip edilmeyeceğine veya müşterinin altında yeniden oluşturulup oluşturulmayacağına karar verin
• Her sağlayıcı için destek iletişim bilgisini kaydedin

Bunu her iki tarafın da takip edebileceği sade bir dille yazın.

Ortamları ve nerede çalıştıklarını listeleyin

Hangi ortamların olduğunu (local, staging, production) ve her birinin nerede çalıştığını kararlaştırın. Staging’in ayrı bir sunucu mu, ayrı bir veritabanı mı yoksa sadece bir özellik bayrağı mı olduğunu not edin. Koder.ai gibi bir platform kullanıldıysa, orada hangi bileşenlerin barındırıldığını ve dışa aktarma sonrası müşterinin altyapısında neyin çalışması beklendiğini de doğrulayın.

Erişimi erken toplayın

Erişimi son güne bırakmayın. Doğru kişilerin gerekli yerlere ulaşabildiğinden emin olun: repo, CI, barındırma, veritabanı ve e-posta sağlayıcısı.

Ayrıca nihai kabul testi ve onay süreci üzerinde anlaşın. Örneğin: “Müşteri temiz bir makineden derleyebilir, migrationları çalıştırabilir, staging’e deploy edebilir ve smoke testi geçer. Sonra her iki taraf yazılı onay verir.”

Repo ve dokümantasyon temelleri

İyi bir kaynak kod devri kontrol listesi, yeni bir ekibin repoyu açıp birkaç dakika içinde anlayabileceği bir repo ile başlar. Nelerin dahil olduğunu (uygulama kodu, yapılandırma şablonları, betikler) ve kasıtlı olarak nelerin hariç olduğunu (gerçek gizli anahtarlar, özel anahtarlar, büyük oluşturulmuş dosyalar) doğrulayın. Bir şey hariç bırakıldıysa, nerede olduğu ve kimin sahip olduğu belirtilsin.

Yapıyı öngörülebilir tutun. Üst düzey klasörler için net bir düzen hedefleyin: frontend/, backend/, mobile/, infra/, scripts/, ve docs/. Proje bir monorepo ise, parçaların nasıl ilişkili olduğunu ve her birinin nasıl çalıştırılacağını açıklayın.

README, projeyi inşa etmeyen birinin kullanabileceği şekilde olmalıdır. Önkoşulları ve çalışır bir geliştirme çalıştırması için en hızlı yolu, tahminde bulunmaya gerek kalmayacak şekilde kapsamalıdır.

Nelerin belgelenmesi gerektiği (asgari)

Kısa, insan diliyle bir README bölümü şunları yanıtlamalıdır:

• Bu repo neleri içerir ve ne yapar (bir paragraf)
• Tam sürümlerle önkoşullar (runtime, paket yöneticisi, gerekiyorsa Docker)
• Yerel geliştirme için tek komutla başlatma adımları (ve “başarı”nın ne olduğu)
• Testlerin nasıl çalıştırılacağı ve üretim artefaktının nasıl oluşturulacağı
• Anahtar dokümanların nerede bulunduğu: mimari notlar, migrationlar, dağıtım notları

Basit mimari notları sade bir dille ekleyin: ne kiminle konuşur ve neden. Küçük bir diyagram opsiyoneldir, ama birkaç cümle genellikle yeterlidir. Örnek: “React frontend, Go API’yi çağırır. API PostgreSQL’i okur/yazar. Arka plan işleri ayrı bir worker süreç olarak çalışır.”

Son olarak, devri için sürümlendirilmiş bir changelog veya sürüm notları ekleyin. Bu CHANGELOG.md olabilir veya hangi commit/etiketin gönderildiği ve bilinen sorunların yer aldığı kısa bir “devri sürüm notları” dosyası olabilir.

Kod Koder.ai gibi bir platformdan dışa aktarıldıysa, oluşturulan proje tipini (web, server, mobile), beklenen araç zincirini (örneğin React, Go, PostgreSQL, Flutter) ve müşterinin derlemeyi çoğaltması için desteklenen OS/araç sürümlerini not edin.

Ortam değişkenleri: envanter ve dokümantasyon

Ortam değişkenleri, “çalışan uygulamanın” devri sonrasında başarısız olmasının sık nedenidir. İyi bir kaynak kod devri kontrol listesi bunları ürünün bir parçası gibi ele alır, sonrasında unutulan bir detay değil.

Yeni bir ekibin tahmin etmeden takip edebileceği bir envanter yazarak başlayın. Basit bir dille tutun ve örnek değer formatı verin (gerçek gizli anahtarlar değil). Bir değişken isteğe bağlıysa, eksik olduğunda ne olduğunu ve hangi varsayılanın kullanıldığını söyleyin.

Envanteri sunmanın basit bir yolu:

• Değişken adı, neyi kontrol ettiği ve örnek format
• Zorunlu mu isteğe bağlı mı, artı varsa varsayılan davranış
• Nerede ayarlandığı (CI, barındırma panosu, yerel .env dosyası)
• Hangi ortamların farklı değer gerektirdiği (dev, staging, production)
• Değişikliklerden kimin sorumlu olduğu (müşteri, ajans veya ortak)

Ortam-spesifik farklılıkları açıkça belirtin. Örneğin, staging bir test veritabanına ve sandbox ödeme sağlayıcısına işaret ederken, üretim canlı hizmetleri kullanır. Ayrıca callback URL’leri, izin verilen originler veya mobil uygulama bundle identifier gibi sistemler arasında eşleşmesi gereken değerleri not edin.

Her değerin bugün nerede bulunduğunu belgeleyin. Birçok ekip değerleri farklı yerlerde tutar: geliştirme için yerel .env dosyaları, derlemeler için CI değişkenleri ve çalışma zamanı için barındırma ayarları. Koder.ai’den dışa aktarılan bir proje varsa, .env.example dosyası ekleyin ve hangi değişkenlerin ilk derlemeden önce doldurulması gerektiğine dair kısa bir not koyun.

Son olarak, repoda gizli hiçbir şey kalmadığını kanıtlayın. Sadece mevcut dosyaları kontrol etmeyin. Commit geçmişini inceleyin: kazara eklenen anahtarlar, eski .env dosyaları veya örnek konfiglerde kopyalanmış kimlik bilgileri olabilir.

Somut örnek: bir React frontend ile Go API, web uygulaması için API_BASE_URL ve backend için DATABASE_URL ile JWT_SIGNING_KEY gerektirebilir. Eğer staging farklı bir domain kullanıyorsa, her iki değeri de yazın ve nereden değiştirileceğini belirtin, böylece yeni ekip staging ayarlarını üretime göndermesin.

Gizli anahtar rotasyonu: güvenli devretme, sonra çalıştığını kanıtlayın

Devri tamamlanmış saymak için müşteri uygulamanın ihtiyaç duyduğu her kimlik bilgisine artık kontrolünün geçmesi gerekir. Bu, anahtarları sadece paylaşmak değil, döndürmek anlamına gelir. Ajansın (veya eski bir yüklenicinin) hâlâ geçerli anahtarları varsa, denetleyemeyeceğiniz bir kapı açık demektir.

Tam bir envanter yaparak başlayın. Sadece veritabanı parolalarıyla sınırlı kalmayın. Üçüncü taraf API anahtarları, OAuth istemci sırları, webhook imzalama sırları, JWT imzalama anahtarları, SMTP kimlik bilgileri, depolama erişim anahtarları ve CI içinde bekleyen geçici tokenlar dahil her şeyi sayın.

Rotasyon günü için basit bir kontrol listesi:

• Her gizli anahtarı, neyi açtığını ve şu anda nerede ayarlı olduğunu listeleyin (yerel env dosyaları, CI, barındırma panosu, vault)
• Yeni kimlik bilgilerini müşterinin hesapları altında oluşturun ve her biri için bir sorumlu (kişi ve ekip posta kutusu) atayın
• Uygulamayı yeni değerlerle güncelleyin, sonra önce staging veya test ortamına deploy edin
• Yeni değerlerin çalıştığı doğrulandıktan hemen sonra eski kimlik bilgilerini iptal edin
• Bir dahaki rotasyonun hızlı ve sıkıcı olması için tam rotasyon adımlarını yazın

Rotasyondan sonra hiçbir şeyin kırılmadığını kanıtlayın. Sadece loglara bakmak yerine hızlı “gerçek kullanıcı” testleri çalıştırın.

Gizli anahtarlara bağlı akışlara odaklanın:

• Giriş, kayıt, şifre sıfırlama ve token yenileme
• Ödemeler, e-posta gönderimi ve dosya yüklemeleri
• Webhooklar (imza doğrulama ve yeniden deneme işlemleri)
• Harici API’leri çağıran arka plan işleri veya zamanlanmış görevler
• Ayrıcalıklı endpoint’leri kullanan yönetici işlemleri

Örnek: Koder.ai’den dışa aktarılan bir proje ödeme sağlayıcı ve e-posta dağıtımı kullanıyorsa, her iki anahtarı da döndürün, yeniden deploy edin, sonra küçük bir test işlem gerçekleştirin ve test e-postası gönderin. Bunlar başarılı olduktan sonra ajans sahipliğindeki anahtarları iptal edin.

Son olarak, gizli anahtarların bundan sonra nerede tutulacağını (vault, CI değişkenleri veya barındırma ayarları), kimlerin değiştirebileceğini ve bir rotasyon hata yaparsa nasıl güvenli şekilde geri alınacağını belgeleyin.

Veritabanı migrationları ve veri işlemleri

Bir devri “tamamlandı” gibi gösterebilirsiniz ama veritabanı ilk bozulan parça olabilir. Migrationları ve veriyi ayrı bir ürün olarak ele alın: sürümlü, tekrarlanabilir ve test edilmiş.

Öncelikle mevcut veritabanı sürümünü ve migrationların repoda nerede olduğunu yazın. Spesifik olun: klasör yolu, adlandırma deseni ve son migration ID’si (veya zaman damgası). PostgreSQL kullanıyorsanız (Go backend’lerde yaygın), gerekli uzantıları da not edin.

Nelerin belgelenmesi gerekir (başkası çalıştırabilsin diye)

Kısa bir runbook şu soruları yanıtlamalıdır:

• Hangi komut migrationları çalıştırır ve işleri hangi sırayla yapmak gerekir (veritabanı oluştur, migrationları uygula, sonra seedleri çalıştır)
• Ortama göre nasıl farklılık gösterir (local, staging, production), “güvenli mod” bayrakları varsa bunlar
• Migrationların deploy sırasında otomatik mi yoksa elle mi çalıştığı ve kimlerin çalıştırmaya yetkili olduğu
• Seed veri stratejisi: yok, demo için, veya minimal gerekli kayıtlar (yönetici kullanıcı, varsayılan ayarlar)
• Geri alma planı: nelerin geri alınabildiği ve nelerin alınamayacağı (örneğin yıkıcı sütun silmeleri)

Geri almalar dürüstçe ele alınmalı. Bazı değişiklikler yalnızca yedekten geri yükleme ile tersine çevrilebilir. Bunu basit bir dille belirtin ve bunu bir yedek adımıyla eşleştirin (deploy öncesi anlık görüntü, geri yükleme sürecinin doğrulanması).

Devir tamamlanmadan önce mümkünse production verisinin bir kopyasında migrationları çalıştırın. Bu yavaş sorguları, eksik indexleri ve “boş veride çalışıyor” sorunlarını yakalar. Gerçekçi bir test, kodu dışa aktarıp ortam değişkenlerini ayarlamak, anonimleştirilmiş bir dökümü geri yüklemek ve sonra migrationları sıfırdan uygulamaktır. Bu tek egzersiz, devrin büyük bir bölümünü doğrular.

Uygulama Koder.ai üzerinde oluşturulup dışa aktarıldıysa, migration dosyalarının ve seed betiklerinin dışa aktarmaya dahil olduğundan ve backend başlatma süreci tarafından hâlâ doğru şekilde referanslandığından emin olun.

Derleme ve CI: tekrarlanabilir kılın

Devri, bir başkasının temiz bir makineden uygulamayı sıfırdan yeniden derleyebilmesi tamamlar. Kaynak kod devri kontrol listeniz, tam derleme komutlarını, gerekli sürümleri ve beklenen çıktıyı (örneğin: “web paketinin /dist içinde olması”, “API ikili dosya adı”, “Flutter APK konumu”) içermelidir.

Aslında kullandığınız araçları ve paket yöneticilerini yazın, neyi kullandığınızı düşündüğünüzü değil. Tipik bir yığın için bu React web uygulaması için Node.js (ve npm veya pnpm), sunucu için Go toolchain, yerel kurulum için PostgreSQL istemci araçları ve mobil için Flutter SDK olabilir.

Bağımlılık kurulumlarını öngörülebilir kılın. Kilit dosyalarının (package-lock.json, pnpm-lock.yaml, go.sum, pubspec.lock) commit edildiğini doğrulayın ve yeni bir bilgisayarda veya temiz bir konteynerde taze kurulum yaparak çalıştığını kanıtlayın.

CI’nin ne yaptığını adım adım yakalayın ki gerekirse başka bir CI sağlayıcısına kopyalanabilsin:

• Bağımlılıkları kur (kilit dosyalarıyla)
• Testleri ve lint kontrollerini çalıştır
• Derleme çıktıları (web bundle, sunucu ikilisi, mobil derleme)
• Artefakt üretimi (zip, Docker imajı, release paketi)
• Logları ve derleme meta verisini sakla (sürüm, commit, tarih)

Derleme zamanı konfigürasyonunu çalışma zamanı konfigürasyonundan ayırın. Derleme zamanı konfigürasyonu derlenen şeyi değiştirir (örneğin web bundle’a gömülü bir API base URL). Çalışma zamanı konfigürasyonu uygulama başladığında enjekte edilir (veritabanı URL’leri, API anahtarları, özellik bayrakları). Bu ikisini karıştırmak “CI üzerinde çalışıyor ama dağıtımdan sonra bozuluyor” sorunlarının sık nedenidir.

Basit bir yerel doğrulama tarifi sağlayın. Kısa bir komut seti bile yeterlidir:

# Web
pnpm install
pnpm test
pnpm build

# API
go test ./...
go build ./cmd/server

# Mobile
flutter pub get
flutter test
flutter build apk

Koder.ai gibi bir platformdan dışa aktarıyorsanız, deploy sırasında kullanılan üretilmiş CI dosyalarını veya derleme önayarlarını ekleyin ki müşteri aynı derlemeyi platform dışından da tekrarlayabilsin.

Dağıtım betikleri ve sürüm süreci

İyi bir kaynak kod devri kontrol listesi sadece “işte repo” demekle kalmaz. Ayrıca uygulamanın kaynak koddan çalışan bir servise nasıl gittiğini ve kimin düğmeye bastığını açıklar.

Öncelikle dağıtımların bugün nasıl yapıldığını yazın: tamamen manuel (biri sunucuda komutları çalıştırıyor), CI tarafından tetiklenen bir pipeline mı yoksa barındırılan bir platform mu kullanılıyor. Konfiglerin nerede tutulduğunu ve hangi ortamların olduğunu belirtin (dev, staging, production).

Sürüm adımlarını tekrarlanabilir kılın. Sürecin bir kişinin 12 komutu hatırlamasına bağlı olması yerine bu komutları betik haline getirin ve gerekli izinleri not edin.

Dağıtım paketine nelerin dahil edilmesi gerekir

Müşteriye ilk günden dağıtım yapabilmesi için yeterli bilgiyi verin:

• Derleme ve çalıştırma komutları (Node, Go, Flutter vb. için tam sürümler)
• Dağıtım betikleri (shell betikleri, Makefile hedefleri veya pipeline konfigleri)
• Gerekli erişimler: bulut hesap rolleri, container registry, DNS, veritabanı admin
• Ortam kurulumu notları: env varların nerede ayarlandığı ve ortamlar arası farkları
• Sürüm isimlendirmesi: tag/release ve hangi sürümün neyin çalıştığını belirleme yöntemi

Kesinti beklentileri üzerinde anlaşın. “Sıfır kesinti” gerekiyorsa bunun pratikte ne anlama geldiğini belirtin (blue-green, rolling deploy, migration için salt okunur pencere). Kesinti kabul edilebilirse, net bir pencere tanımlayın.

Statik varlıklar ve önbellekler sık rastlanan başarısızlık noktalarıdır. Varlıkların nasıl oluşturulduğunu ve sunulduğunu, cache temizlemenin ne zaman yapılacağını ve bir CDN kullanılıp kullanılmadığını not edin.

Gerçekte uygulayabileceğiniz bir geri alma

Geri alma kısa, test edilmiş bir tarif olmalıdır ve bir etiket veya sürüm ID’sine bağlı olmalıdır. Örneğin: önceki etiketi deploy et, gerekiyorsa önceki veritabanı anlık görüntüsünü geri yükle ve cache’leri geçersiz kıl.

Uygulama Koder.ai üzerinde oluşturulup dışa aktarıldıysa, müşterinin kodu hızlıca çalışan bir sürümle eşleştirebilmesi için en son bilinen iyi anlık görüntüyü ve tam dışa aktarma sürümünü belirtin.

Adım adım: dışa aktarmadan sonra derlemeyi doğrulayın

Doğrulama, devrin gerçek olup olmadığını öğrendiğiniz andır. Amaç basittir: yeni biri dışa aktarılan kodu alıp kurup tahminde bulunmadan aynı uygulamayı çalıştırabilmelidir.

Başlamadan önce, “doğru”nun nasıl göründüğünü kaydedin: çalışan uygulamanın sürümü, mevcut commit/tag (varsa) ve karşılaştırmak için bir veya iki ana ekran veya API yanıtı. Dışa aktarma bir platformdan geldiyse (Koder.ai gibi), test ettiğiniz son durumu kanıtlamak için anlık görüntü veya dışa aktarma zaman damgasını not edin.

1. Dışa aktarma üretimle eşleşiyor mu kontrol edin: commit geçmişini, sürüm notlarını veya derleme meta verisini kontrol edin. Çalışan uygulamayla görünen bir versiyon dizisini veya küçük bir davranışı (belirli bir ayar veya UI etiketi gibi) karşılaştırın.
2. Ortam değişkenlerini ve gizli anahtarları ayarlayın: hedef ortam konfigürasyonunu oluşturun (local ve staging). Sağlanan env var envanterini kullanın ve repoda hiçbir şeyin sert kodlanmadığından emin olun.
3. Bağımlılıkları kurun ve testleri çalıştırın: temiz bir kurulum yapın (önceden varolan node_modules/vendor klasörleri olmadan). Birim testleri ve belge edildiği şekilde lint kontrollerini çalıştırın.
4. Migrationları çalıştırın ve yerelde başlatın: veritabanını ayağa kaldırın, migrationları sırayla uygulayın ve uygulamayı başlatın. Uygulamanın temel veriyi okuyup yazabildiğini ve bekleyen migration olmadığını doğrulayın.
5. Staging’e deploy edin, smoke test yapın, sonra promote edin: üretimde kullanacağınız aynı betik/pipeline ile deploy edin. Staging beklentileri karşıladıktan sonra promote edin.

Smoke testleri kısa ve riskle ilişkili tutun:

• Giriş/çıkış (veya bir test kullanıcı oluşturma)
• Bir temel iş akışını uçtan uca test et (oluştur-düzenle-kaydet)
• Geçerli ise bir e-posta/webhook/ödeme callback’i
• Temel hata işleme (hatalı giriş, eksik kayıt)
• Loglarda tekrarlayan çöküşler veya gizli anahtarla ilgili hatalar yok

Bir şey başarısız olursa, tam komutu, hata çıktısını ve kullanılan env varları kaydedin. Bu ayrıntı, sahiplik değiştiğinde saatler kazandırır.

Yaygın devri hataları ve nasıl önlenir

Devri bir kriz ortamına çevirmenin en hızlı yolu “kod yeterli” varsayımıdır. İyi bir kaynak kod devri kontrol listesi, müşterinin gerçekten uygulamayı değiştirebilip çalıştırıp sürdürüp sürdüremeyeceğini belirleyen küçük, sıkıcı detaylara odaklanır.

Devri en çok zorlaştıran hatalar

Çoğu sorun birkaç tekrarlayan paternin içine düşer:

• Gizli anahtarlar döndürülmemiştir, böylece eski ajans parolaları, API anahtarları veya bulut tokenları devrin ardından hâlâ çalışır.
• Ortam değişkenleri eksiktir çünkü bazı değerler sadece CI ayarlarında veya barındırma panosunda durur, repoda değil.
• Üretimde yapılan tek seferlik değişiklikler unutulur: hızlı bir hotfix, manuel veri düzenlemesi veya doğrudan sunucuda ayar değişikliği.
• Migrationlar yerelde çalışırken üretimde izinler, uzantılar veya şema sahipliği eksikliğinden başarısız olur.
• Geri alma planı yoktur ve geri dönülecek etiketli bir sürüm (veya sürüm notu) yoktur.

Bunları nasıl önlersiniz (haftalar eklemeden)

Rotasyon ve erişim temizliğini “zaman bulunca yapılacak” bir işe değil planlı bir göreve dönüştürün. Ajans hesaplarının kaldırılacağı, servis anahtarlarının yeniden üretileceği ve müşterinin yalnızca kendi kimlik bilgileriyle deploy edebildiğini onaylayacağı bir tarih belirleyin.

Ort değişkenleri için repo, CI sistemi ve barındırma UI’sı olmak üzere üç yerden basit bir envanter çıkarın. Sonra bunu temiz bir makinede veya konteynerde temiz bir derlemeyle doğrulayın.

Migrationlar için production deployunun kullanacağı aynı veritabanı rolüyle testi gerçekleştirin. Üretim ek adımlar (uzantı etkinleştirme gibi) gerekiyorsa bunları yazın ve sahipliği netleştirin.

Gerçekçi bir örnek: Koder.ai’den dışa aktarılan bir projede müşteri deploy başarılı olur ama arka plan işler başarısızdır çünkü bir kuyruk URL’si yalnızca barındırma panosunda ayarlanmıştır. Basit bir env var denetimi bunu yakalardı. Bunu etiketli bir sürüm ve belgelenmiş bir geri alma (örneğin “v1.8.2 etiketini yeniden deploy et ve son anlık görüntüyü geri yükle”) ile eşleştirin, böylece ekip kesintiden kaçınır.

Son kontrol listesi, basit bir örnek ve sonraki adımlar

Bu kaynak kod devri kontrol listesinden yalnızca bir sayfayı saklayacaksanız, bu sayfayı tutun. Amaç basittir: temiz bir clone yeni bir makinede çalışmalı, yeni anahtarlarla çalışmalı ve veritabanı güvenle ileri taşınabilmelidir.

Hızlı kontroller (bunları temiz bir clone'dan çalıştırın)

Bu kontrolleri projeyi daha önce görmemiş bir dizüstünde (veya temiz bir konteyner/VM) çalıştırın. Eksik dosyaları, gizli varsayımları ve eski kimlik bilgilerini yakalamanın en hızlı yolu budur.

• Sıfırdan derle: bağımlılıkları kurun, testleri çalıştırın (varsa) ve elle düzenleme yapmadan release build üretin.
• Konfig çalışıyor: belgelenen ortam değişkenlerini ayarlayın ve uygulamanın temiz bir konfig dosyası veya env ile açıldığını doğrulayın.
• Gizli anahtarlar döndürüldü: uygulamanın yeni anahtarlarla çalıştığını doğrulayın, sonra eski anahtarları iptal edin ve hiçbir şeyin kırılmadığını teyit edin.
• Migrationlar temiz çalışıyor: boş bir veritabanıyla başlayın, migrationları çalıştırın, sonra uygulamayı başlatın ve bir temel akışı test edin.
• Dağıtım yolu gerçek: dağıtım betiğini veya CI iş akışını bir kez çalıştırın ve aynı çıktıyı ürettiğini doğrulayın.

Basit bir devri örneği

Bir ajans React frontend, Go API ve PostgreSQL veritabanını devreder. Müşteri ekibi repoyu klonlar, sağlanan .env.example dosyasını gerçek env değişkenlerine kopyalar ve veritabanı, e-posta sağlayıcısı ve üçüncü taraf API’ler için tamamen yeni kimlik bilgileri oluşturur. go test (veya kararlaştırılan test komutu) çalıştırılır, React uygulaması derlenir, migrationlar temiz bir Postgres örneğine uygulanır ve her iki servis başlatılır. Son olarak, belgelenmiş betik kullanılarak deploy edilir ve aynı commit’in daha sonra yeniden derlenebildiği doğrulanır.

Sonraki adımlar

Devri kısa ve sahipliği net tutun. 30–60 dakikalık bir yürütme genellikle uzun bir dokümantasyondan daha etkilidir.

• Bir walkthrough planlayın ve kararları kaydedin (kimin deploylara, gizli anahtarlara ve veritabanı değişikliklerine sahip olduğu).
• Üretim için bir sahip ve bir yedek atayın.
• Nihai “kabul derlemesi” commit hash’inde anlaşın ve etiketleyin.
• Koder.ai ile oluşturduysanız, kaynak kodu dışa aktarın, sonra ilk müşteri deployu sırasında anlık görüntü ve geri alma kullanarak riski azaltın.