Geliştirme, Staging ve Production Ortamlarının Senkronizasyonu

Bir uygulamanın geliştirici bilgisayarında sorunsuz çalışıp staging ortamında hata vermesi, production ortamına çıktığında ise bambaşka bir davranış göstermesi yazılım ekiplerinin en yorucu problemlerinden biridir. On yılı aşkın süredir yazılım projelerinde gördüğüm ortak nokta şu oldu: Sorun çoğu zaman koddan önce ortamların birbirinden kontrolsüz biçimde uzaklaşmasıyla başlıyor. Geliştirme, Staging ve Production Ortamlarının Senkronizasyonu bu nedenle yalnızca DevOps ekiplerinin ilgilenmesi gereken teknik bir konu değildir. Yazılım geliştiricilerden QA ekiplerine, güvenlik uzmanlarından ürün sahiplerine kadar herkesin aynı ortam standardını anlaması gerekir. Bu rehberde development staging production ortamları nasıl senkronize edilir, dev staging prod ortamlarında konfigürasyon tutarlılığı nasıl sağlanır ve Docker Kubernetes ve CI/CD ile development staging production ortam yönetimi nasıl kurulabilir sorularını uygulamaya dönük örneklerle ele alacağız.

Development, Staging ve Production Ortamları Nedir?

Yazılım teslim sürecinde development, staging ve production ortamları farklı amaçlara hizmet eder, ancak aynı uygulamanın yaşam döngüsünü temsil eder. Development ortamı hızlı geliştirme ve geri bildirim için esnek tutulurken staging ortamı production davranışını güvenli biçimde sınamak için kullanılır. Production ise gerçek kullanıcıların eriştiği ve veri bütünlüğünün kritik olduğu canlı ortamdır. İyi tasarlanmış bir sistemde bu ortamlar tamamen aynı değildir, fakat aralarındaki teknik farklılıklar bilinçli, ölçülebilir ve belgelenmiş olmalıdır. Bu ayrım anlaşılmadan kurulan pipeline'larda hataların kaynağını bulmak zorlaşır ve küçük değişiklikler bile beklenmedik production sorunlarına dönüşebilir.

Development Ortamının Amacı

Development ortamının temel görevi geliştiricinin hızlı şekilde kod yazabilmesi, test edebilmesi ve geri bildirim alabilmesidir. Bu ortam lokal makinede, paylaşılan bir sunucuda veya geçici container yapılarında çalışabilir. Hız önemlidir, ancak hız uğruna production ile tamamen farklı runtime veya dependency kullanmak doğru değildir. Örneğin production Node.js 22 kullanıyorsa geliştiricinin Node.js 18 üzerinde çalışması gereksiz sürüm farkları oluşturabilir. Development ortamı esnek olabilir, fakat uygulamanın gerçek çalışma koşullarını mümkün olduğunca temsil etmelidir.

Staging Ortamının Amacı

Staging ortamı canlıya çıkmadan önce uygulamanın production benzeri koşullarda sınandığı güvenli geçiş noktasıdır. Burada entegrasyon testleri, UAT, migration kontrolleri, güvenlik taramaları ve deployment doğrulamaları yapılabilir. Staging'in amacı production'ın maliyet açısından birebir kopyasını oluşturmak değildir. Asıl hedef çalışma biçimi, ağ davranışı, deployment mekanizması ve konfigürasyon şemasında production'a yakın olmaktır. Böylece staging üzerinde başarıyla geçen değişikliğin production'da farklı davranma ihtimali ciddi biçimde azalır.

Production Ortamının Amacı

Production gerçek kullanıcı trafiğini, gerçek iş süreçlerini ve gerçek veriyi taşıyan ortamdır. Bu nedenle erişim, değişiklik yönetimi ve gözlemlenebilirlik açısından en sıkı politikalar burada uygulanmalıdır. Production üzerinde geliştiricilerin doğrudan manuel değişiklik yapması yerine tanımlı deployment süreçleri tercih edilmelidir. Çalışan artifact'in hangi commit'ten üretildiği, hangi konfigürasyonla başlatıldığı ve hangi migration seviyesinde olduğu izlenebilmelidir. Production güvenilirliği yalnızca güçlü sunucularla değil, tekrar üretilebilir ve denetlenebilir süreçlerle sağlanır.

Test, QA, UAT ve Preview Ortamları Nereye Oturur?

Üç temel ortam modelinin yanında test, QA, UAT ve preview ortamları da ihtiyaçlara göre kullanılabilir. Test ortamları otomatik testlerin çalıştırıldığı izole alanlar olabilirken QA ortamları kalite ekiplerinin senaryolarını yürüttüğü daha kalıcı yapılardır. UAT ortamı iş birimlerinin veya müşterinin kabul testlerini gerçekleştirmesi için tasarlanır. Preview ortamları ise genellikle her pull request için kısa süreli olarak oluşturulur ve değişikliklerin birleşmeden önce görülmesini sağlar. Bu ek ortamların değeri, görevlerinin açık biçimde tanımlanması ve ana ortam standartlarından gereksiz yere kopmamasına bağlıdır.

Her Projenin Üç Ortama İhtiyacı Var mı?

Her projenin mutlaka development, staging ve production olmak üzere üç kalıcı ortama sahip olması gerekmez. Küçük bir ekip lokal development, paylaşılan staging ve production yapısıyla oldukça sağlıklı çalışabilir. Çok basit uygulamalarda preview ortamları staging ihtiyacının bir kısmını karşılayabilir. Buna karşılık ödeme, kimlik doğrulama veya yüksek veri riski taşıyan sistemlerde staging katmanı önemli bir güvenlik ağı sağlar. Ortam sayısını proje büyüklüğünden çok değişiklik riski, ekip yapısı, mevzuat yükümlülükleri ve deployment sıklığı belirlemelidir.

Ortam Senkronizasyonu Nedir?

Ortam senkronizasyonu, farklı ortamlarda çalışan uygulamanın aynı teknik beklentilere göre davranmasını sağlama sürecidir. Buradaki hedef bütün ortamları aynı kapasiteye veya aynı verilere sahip hale getirmek değildir. Hedef, uygulamanın çalışmasını etkileyen runtime, dependency, deployment, migration, network ve configuration gibi alanlarda kontrolsüz farkların oluşmasını önlemektir. Bu yaklaşım sayesinde staging üzerinde doğrulanan davranışın production ortamına taşınabilirliği artar. Senkronizasyon iyi uygulandığında hata araştırma süresi kısalır, deployment güveni yükselir ve ekiplerin ortamlar hakkındaki belirsizliği azalır.

Environment Synchronization Ne Anlama Gelir?

Environment synchronization, ortamların tanımlı bir ortak standarda göre düzenli olarak karşılaştırılması ve uyumsuzlukların yönetilmesi anlamına gelir. Örneğin container image sürümü, migration seviyesi ve gerekli environment variable anahtarları ortamlar arasında kontrol edilebilir. Bu kontrol yalnızca deployment anında değil, planlı olarak da çalıştırılabilir. Ortaya çıkan farklar bilinçli ise kayıt altına alınır, beklenmeyen farklar ise drift olarak değerlendirilir. Böylece ortam yönetimi kişisel hafızaya değil ölçülebilir verilere dayanır.

Environment Parity Nedir?

Environment parity, farklı ortamların uygulama davranışı açısından yeterince benzer olmasını ifade eder. Buradaki ana fikir değerlerin değil yapının ve çalışma prensibinin eşleşmesidir. Production veritabanı adresi ile staging veritabanı adresı farklı olabilir, fakat iki ortamda da aynı configuration anahtarının bulunması beklenir. Aynı şekilde production daha fazla replica çalıştırabilir, ancak aynı container image ve deployment mekanizması kullanılabilir. Parity yaklaşımı farklılıkları ortadan kaldırmak yerine hangi farklılıkların kabul edilebilir olduğunu açık biçimde tanımlar.

Dev/Prod Parity Nedir?

Dev/prod parity, geliştirme koşulları ile production koşulları arasındaki gereksiz farkları azaltma prensibidir. Geliştirici aynı runtime, aynı dependency major sürümleri ve mümkün olduğunca aynı servis türleriyle çalıştığında production davranışını daha erken görebilir. Örneğin development SQLite, production PostgreSQL kullanıyorsa sorgu davranışları farklılaşabilir. Lokal geliştirmede aynı veritabanı motorunun container üzerinden kullanılması bu riski azaltır. Dev/prod parity özellikle sık deployment yapan ekiplerde yüksek değer üretir.

Senkronizasyon ile Birebir Kopyalama Arasındaki Fark

Senkronizasyon ve birebir kopyalama aynı kavram değildir. Birebir kopyalama CPU, RAM, veri, secret ve altyapı kapasitesi dahil her şeyi eşitlemeye çalışır. Senkronizasyon ise davranış açısından önemli alanları eşit tutarken güvenlik, maliyet ve ölçek nedeniyle bazı farklılıklara bilinçli olarak izin verir. Örneğin staging tek replica çalıştırırken production altı replica çalıştırabilir. Buna rağmen iki ortam aynı container image, aynı health check yapısı ve aynı deployment manifest şemasını kullanabilir.

“Works on My Machine” Problemi Nasıl Oluşur?

“Works on my machine” problemi geliştirici ortamı ile hedef ortam arasında görünmeyen farklar olduğunda ortaya çıkar. Farklı işletim sistemi, environment variable, dependency sürümü veya veritabanı motoru bu soruna neden olabilir. Manuel olarak kurulmuş development ortamları zaman içinde daha fazla sapma üretir. Container kullanımı, lock file uygulaması ve otomatik config validation bu farkları erken yakalayabilir. Sorunun çözümü geliştiriciyi suçlamak değil, ortam davranışını tekrar üretilebilir hale getirmektir.

Dev, Staging ve Production Birebir Aynı mı Olmalı?

Dev, staging ve production ortamlarının birebir aynı olması ne gereklidir ne de çoğu zaman ekonomiktir. Asıl amaç uygulamanın davranışını etkileyen unsurları aynı tutmak ve kapasite ya da güvenlik nedeniyle farklı olması gereken alanları açık biçimde ayırmaktır. Runtime, dependency sürümü, deployment artifact'i, migration mekanizması ve configuration schema genellikle eşleşmelidir. Buna karşılık replica sayısı, backup retention veya CPU kapasitesi farklı olabilir. Credentials, encryption key, API token ve müşteri verileri ise kesin biçimde birbirinden ayrılmalıdır.

Aynı Tutulması Gereken Bileşenler

Ortamlar arasında aynı tutulması gereken bileşenler doğrudan uygulama davranışını etkileyen teknik parçaları kapsar. Bu alanlarda oluşan küçük bir fark bile staging üzerinde görülemeyen production hatalarına yol açabilir. Bu nedenle runtime, dependency, database engine major sürümü ve deployment mekanizması gibi bileşenler version control veya otomasyon ile kontrol edilmelidir. Aynı artifact'in ortamlar arasında promote edilmesi bu yaklaşımın önemli parçalarındandır. Ekip içinde bu bileşenlerin hangileri için parity zorunlu olduğu açık biçimde yazılmalıdır.

Runtime Version

Programlama dili veya runtime sürümü ortamlar arasında aynı tutulmalıdır. Küçük sürüm farkları bile paket davranışlarını veya standart kütüphane sonuçlarını değiştirebilir. Runtime sürümünü Dockerfile veya benzeri tanımlarda pinlemek tekrar üretilebilirliği artırır. Lokal development için de aynı runtime sürümünü kullanan container tercih edilebilir. Böylece sürüm kaynaklı hatalar production'a ulaşmadan önce görülür.

Dependency Version

Dependency sürümleri lock file üzerinden sabitlenmelidir. Her deployment sırasında paketlerin yeniden çözümlenmesi beklenmedik değişikliklere yol açabilir. Aynı commit farklı tarihlerde farklı dependency sürümleriyle build edilmemelidir. Lock file repository içinde tutulmalı ve code review sürecine dahil edilmelidir. Bu yaklaşım artifact tekrar üretilebilirliğini de güçlendirir.

Database Engine ve Major Version

Development, staging ve production ortamlarında aynı database engine kullanmak önemlidir. Major sürüm farklılıkları SQL davranışı, index yönetimi ve veri tipi desteğini değiştirebilir. Lokal geliştirme için container kullanılması bu standardı sağlamayı kolaylaştırır. Staging özellikle production'ın database major sürümüyle eşleşmelidir. Upgrade planları önce staging üzerinde gerçek migration senaryolarıyla test edilmelidir.

Deployment Artifact

Staging üzerinde doğrulanan artifact mümkünse production'a yeniden build edilmeden promote edilmelidir. Yeniden build işlemi aynı source commit kullanılsa bile dependency veya base image farkı oluşturabilir. Artifact registry bu nedenle merkezi rol oynar. Her artifact commit, build numarası ve digest bilgisiyle ilişkilendirilebilir. Production deployment kaydında bu kimliklerin tutulması izlenebilirliği artırır.

Deployment Mekanizması

Staging ve production için tamamen farklı deployment mekanizmaları kullanmak gereksiz risk oluşturur. Staging Helm ile deploy edilirken production üzerinde manuel komut çalıştırılması test edilen sürecin değişmesine neden olur. Aynı pipeline adımları environment parametreleriyle çalıştırılmalıdır. Yetkilendirme ve approval kuralları production'da daha sıkı tutulabilir. Mekanizma aynı kalırken erişim politikası farklılaştırılabilir.

Configuration Schema

Configuration değerleri farklı olsa bile anahtar yapısı aynı olmalıdır. Bir ortamda bulunan zorunlu environment variable diğer ortamda unutulmamalıdır. Uygulama başlangıcında config schema doğrulaması yapılması bu tür hataları erken yakalar. CI pipeline içinde eksik veya tanımsız anahtar kontrolü eklemek faydalıdır. Böylece konfigürasyon davranışı kod kadar yönetilebilir hale gelir.

Migration Mekanizması

Database migration işlemleri tüm ortamlarda aynı araç ve aynı versioned dosyalar üzerinden yürütülmelidir. Development için otomatik, production için manuel SQL kullanmak zaman içinde schema drift oluşturur. Migration'lar code review sürecinden geçmeli ve sırayla promote edilmelidir. Deployment öncesi mevcut schema version kontrol edilebilir. Production üzerinde uygulanacak migration staging'de aynı artifact ile denenmelidir.

Network Davranışı

Network topolojisinin kapasitesi farklı olabilir, ancak uygulamanın karşılaştığı temel ağ davranışı benzer tutulmalıdır. TLS, reverse proxy, ingress, DNS ve firewall kuralları staging'de production'a yakın olmalıdır. Aksi halde cookie, redirect veya CORS sorunları production'a kadar görünmeyebilir. Egress kısıtları da entegrasyonların davranışını etkileyebilir. Network parity uygulama parity'sinin sık unutulan parçalarından biridir.

Bilinçli Olarak Farklı Olabilecek Bileşenler

Bazı bileşenlerin farklı olması doğal, hatta gereklidir. Production kapasitesi gerçek trafik için daha yüksek olabilirken staging maliyet kontrolü amacıyla daha küçük çalıştırılabilir. Bu farklılıkların sorun haline gelmemesi için davranışsal etkileri değerlendirilmelidir. Bir staging ortamının tek replica çalışması kabul edilebilir, fakat replica bağımlı race condition testleri gerekiyorsa ayrı bir test ortamı gerekir. Farklılıklar belgelenirse ekip hangi sonucun staging üzerinde güvenilir biçimde test edilebileceğini bilir.

CPU ve RAM

Staging sunucuları production kadar güçlü olmak zorunda değildir. Uygulamanın minimum gereksinimlerini karşılaması ve normal fonksiyonel testleri gerçekleştirebilmesi çoğu zaman yeterlidir. Performans testleri için geçici olarak production benzeri kapasite açılabilir. Kaynakların küçük olması bazı zamanlama sorunlarını görünür hale de getirebilir. Ancak çok düşük kaynak nedeniyle sürekli false positive üreten bir staging ortamı yararlı değildir.

Replica Sayısı

Production yüksek erişilebilirlik için birden fazla replica çalıştırabilir. Staging maliyeti azaltmak amacıyla bir veya iki replica ile çalışabilir. Buna rağmen session yönetimi, distributed lock veya leader election gibi davranışlar test edilecekse çoklu replica gerekir. Replica sayısı bilinçli bir environment parameter olarak yönetilmelidir. Kod içine environment adına göre gömülmemelidir.

Autoscaling Limitleri

Autoscaling minimum ve maksimum limitleri ortamın trafik profiline göre değişebilir. Staging ortamında production kadar yüksek maksimum replica sınırı gerekmeyebilir. Ancak autoscaling mekanizmasının kendisi aynı teknoloji ve metric yaklaşımını kullanmalıdır. Threshold değerleri environment-specific parametre olabilir. Load test sırasında production benzeri değerler geçici olarak uygulanabilir.

Backup Retention

Production backup retention süresi iş gereksinimleri ve mevzuat nedeniyle uzun olabilir. Staging üzerinde aynı saklama süresi hem maliyetli hem de gereksiz olabilir. Bununla birlikte backup ve restore sürecinin kendisi staging üzerinde test edilebilmelidir. Non-prod backup'larında kişisel veri bulunmaması ayrıca önemlidir. Retention farkı parity contract içinde açıkça belgelenebilir.

Veri Hacmi

Staging'in production kadar büyük veri seti taşıması zorunlu değildir. Functional parity için daha küçük ama ilişkileri doğru bir veri seti yeterli olabilir. Buna rağmen query performance veya uzun migration süreleri küçük veri üzerinde görünmeyebilir. Büyük ölçek testleri ayrı bir performans ortamında çalıştırılabilir. Veri hacmi ile veri davranışını birbirinden ayırmak maliyeti azaltırken kaliteyi korur.

Kesinlikle Ayrı Olması Gereken Bileşenler

Bazı bileşenlerin ortamlar arasında paylaşılması ciddi güvenlik ve veri bütünlüğü riskleri doğurur. Credentials, database, encryption keys, API tokens ve müşteri verileri bu grubun başında gelir. Staging uygulamasının production database'e bağlanabilmesi küçük bir konfigürasyon hatasını gerçek veri kaybına dönüştürebilir. Aynı şekilde production token'ının development makinesinde bulunması erişim alanını gereksiz yere genişletir. Ortam izolasyonu yalnızca teknik düzen değil, risk sınırlandırma mekanizmasıdır.

Credentials

Her ortam kendi credentials setine sahip olmalıdır. Development kullanıcıları production servis hesabı bilgilerini görmemelidir. Credentials merkezi secret manager üzerinden sağlanabilir. Erişim politikaları ortam rolüne göre sınırlandırılmalıdır. Böylece bir non-prod ihlali production erişimine doğrudan dönüşmez.

Database

Her environment ayrı database instance veya en azından güçlü biçimde izole edilmiş database alanı kullanmalıdır. Development uygulamasının production database'e bağlantısı network seviyesinde de engellenmelidir. Yanlış connection string tek başına production erişimi sağlamamalıdır. Staging database production şemasını temsil edebilir fakat production verisini taşımak zorunda değildir. Bu ayrım test güvenliği için temel gereksinimdir.

Encryption Keys

Encryption key'ler ortamlar arasında paylaşılmamalıdır. Production verisini şifreleyen anahtarın staging üzerinde bulunması güvenlik sınırını ortadan kaldırır. Her ortam kendi key lifecycle sürecine sahip olmalıdır. Rotation ve erişim logları ayrıca izlenmelidir. Anahtar kimlikleri konfigürasyonda bulunabilir, ancak anahtar materyali repository içine yazılmamalıdır.

API Tokens

Third-party API token'ları environment bazında ayrılmalıdır. Sandbox servisleri için sandbox token, production endpoint için production token kullanılmalıdır. Production token'ın staging üzerinde kullanılması gerçek işlem oluşturabilir. Rate limit ve erişim kapsamları da ortam bazında ayarlanmalıdır. Token dağıtımı runtime secret injection ile yapılabilir.

Customer Data

Gerçek müşteri verisinin non-prod ortamlara taşınması varsayılan yaklaşım olmamalıdır. Test için veri gerekiyorsa masking, anonymization veya synthetic data yöntemleri kullanılmalıdır. Kişisel veri içeren snapshot'lar ayrıca risk oluşturur. Non-prod erişimi production kadar sıkı değilse risk daha da büyür. Veri minimizasyonu ortam senkronizasyonunun güvenlik tarafında önemli bir ilkedir.

Environment Parity Contract Nasıl Oluşturulur?

Environment parity contract, ortamların hangi alanlarda aynı kalacağını ve hangi farkların kabul edileceğini yazılı hale getirir. Bu doküman yalnızca mimari bir açıklama değil, CI/CD kontrollerine dönüştürülebilecek teknik bir sözleşme olmalıdır. Runtime sürümü, container image kaynağı, migration aracı, config schema ve network beklentileri zorunlu alanlar arasında yer alabilir. Replica sayısı veya backup retention gibi farklılıklar ise izin verilen farklar listesine eklenebilir. Her istisnanın sahibi, nedeni ve mümkünse sona erme tarihi tanımlandığında ortam farkları kontrol altında tutulur.

Ortak Environment Standardı

Ortak environment standardı ekiplerin tüm ortamları aynı temel prensiplerle kurmasını sağlar. Bu standart isimlendirme, deployment yöntemi, logging formatı ve secret erişimi gibi konuları kapsayabilir. Standart mümkün olduğunca otomasyonla uygulanmalıdır. İnsanların dokümanı hatırlamasına bağlı sistemler zaman içinde bozulur. İyi bir standart sade, ölçülebilir ve ekip tarafından uygulanabilir olmalıdır.

Zorunlu Parity Alanları

Zorunlu parity alanları production davranışını doğrudan etkileyen bileşenlerden seçilmelidir. Runtime, dependency, artifact, migration ve configuration schema çoğu ekip için başlangıç noktasıdır. Network policy ve permission modeli de kritik uygulamalarda bu listeye eklenebilir. Her alan için nasıl doğrulama yapılacağı tanımlanmalıdır. Böylece parity soyut bir hedef olmaktan çıkar.

İzin Verilen Farklar

İzin verilen farkların ayrıca yazılması gereksiz tartışmaları azaltır. Örneğin staging iki replica, production sekiz replica çalıştırabilir. Domain, backup retention ve autoscaling sınırları da ortam bazında değişebilir. Bu farkların uygulama davranışını değiştirmediği doğrulanmalıdır. Liste zaman içinde gözden geçirilmelidir.

Exception Kaydı

Standart dışı her fark exception olarak kaydedilebilir. Exception kaydı farkın teknik nedenini ve oluşturduğu riski açıklamalıdır. Geçici çözümler kalıcı mimariye dönüşmeden önce görünür hale gelir. CI kontrolü belirli exception kimliğiyle geçici olarak bypass edilebilir. Böylece istisna yönetilebilir ve denetlenebilir olur.

Exception Owner

Her exception bir owner'a sahip olmalıdır. Owner farkın neden devam ettiğini takip eder. Sahipsiz istisnalar genellikle yıllarca sistemde kalır. Owner kişi yerine ekip rolü olarak da tanımlanabilir. Organizasyon değişikliklerinde sahipliğin aktarılması kolaylaşır.

Expiration Date

Geçici istisnalara expiration date vermek oldukça etkilidir. Tarih yaklaştığında otomatik bildirim üretilebilir. Süre uzatılacaksa yeniden değerlendirme yapılır. Böylece “şimdilik böyle” denilen farkların unutulması önlenir. Kalıcı farklar ise bilinçli biçimde permanent olarak işaretlenebilir.

Otomatik Parity Kontrolü

Parity contract yalnızca doküman olarak kalmamalıdır. CI/CD pipeline container digest, config anahtarları ve migration seviyesini karşılaştırabilir. Infrastructure plan çıktıları environment standardıyla doğrulanabilir. Kritik farklar production promotion işlemini durdurabilir. Otomatik kontrol, environment parity kültürünü günlük geliştirme akışının parçası yapar.

Environment Drift Nedir?

Environment drift, bir ortamın tanımlanmış veya beklenen durumdan zaman içinde uzaklaşmasıdır. Drift çoğunlukla küçük ve masum görünen değişikliklerle başlar. Bir production sunucusunda manuel paket güncellemesi, staging üzerinde unutulan environment variable veya farklılaşan firewall kuralı buna örnektir. Drift görünür değilse ekip aynı sistemi test ettiğini düşünürken gerçekte farklı sistemlerle çalışır. Düzenli drift detection bu nedenle environment parity yaklaşımının vazgeçilmez parçalarından biridir.

Configuration Drift

Configuration drift, environment variable veya config dosyalarının ortamlar arasında beklenmeyen şekilde farklılaşmasıdır. Yeni anahtar yalnızca production'a eklenmiş olabilir. Eski bir config staging üzerinde kalabilir. Schema validation bu farkı erken yakalar. Config source of truth kullanımı sorunu azaltır.

Infrastructure Drift

Infrastructure drift, gerçek cloud kaynaklarının IaC tanımından uzaklaşmasıdır. Konsoldan açılan bir port buna basit bir örnektir. Terraform plan bu farkların bir kısmını gösterebilir. Planlı drift detection kontrolleri düzenli çalıştırılabilir. Beklenmeyen değişiklikler alarm üretmelidir.

Version Drift

Version drift, runtime veya servis sürümlerinin ortamlar arasında ayrışmasıdır. Production Redis 7 kullanırken staging Redis 6 üzerinde kalabilir. Bu fark yeni komut veya davranışlarda hata yaratabilir. Sürümler kodla tanımlanmalı ve düzenli karşılaştırılmalıdır. Floating version kullanımından kaçınmak önemlidir.

Database Schema Drift

Database schema drift, migration geçmişi ile gerçek şemanın uyuşmamasıdır. Manuel ALTER komutları bu sorunun yaygın nedenidir. Migration version tracking ile her ortamın seviyesi izlenebilir. Deployment öncesi beklenen migration hash'i kontrol edilebilir. Manuel schema değişiklikleri süreç dışında bırakılmalıdır.

Secret Drift

Secret drift, aynı secret şemasının ortamlar arasında uyumsuz hale gelmesidir. Secret değerleri zaten farklı olmalıdır. Sorun gerekli secret'ın bir ortamda eksik olması veya yanlış sürümün kullanılmasıdır. Secret manager metadata üzerinden varlık kontrolü yapılabilir. Secret içeriği karşılaştırılmadan schema parity sağlanabilir.

Feature Flag Drift

Feature flag drift uygulamanın farklı ortamlarda beklenmeyen özellik setleriyle çalışmasına neden olur. Staging'de kapalı olan flag production'da açık olabilir. Bu durum test kapsamını anlamsız hale getirebilir. Flag promotion süreci kullanılmalıdır. Eski flag'ler düzenli temizlenmelidir.

Network Drift

Network drift firewall, route, ingress veya DNS kurallarının ayrışmasıdır. Staging'de açık olan egress production'da kapalı olabilir. Böyle bir fark third-party entegrasyonun yalnızca production'da hata vermesine yol açar. Network policy kodla yönetilmelidir. Diff kontrolleri deployment öncesi uygulanabilir.

Permission Drift

Permission drift servis hesaplarının ortamlar arasında farklı yetki modeliyle çalışmasıdır. Staging hesabı gereğinden fazla yetkiliyse production izin hataları erken görülmez. RBAC yapısı benzer tutulmalıdır. Kimlikler farklı olsa bile rol yapısı eşleşebilir. Permission testleri kritik işlemler için otomatikleştirilebilir.

Data Drift

Data drift yalnızca veri miktarı farkı değildir. Lookup kayıtları veya business rule tabloları da ortamlar arasında farklılaşabilir. Bu fark iş mantığını değiştirebilir. Reference data migration veya seed dosyaları kullanılmalıdır. Manuel veri girişleri azaltılmalıdır.

Environment Drift Neden Oluşur?

Drift'in temel nedeni çoğu zaman teknolojiden çok süreçtir. İnsanlar acil sorunları çözmek için production üzerinde manuel değişiklik yapar, farklı ekipler kendi script'lerini oluşturur veya eski environment dosyaları unutulur. Pipeline'ların ayrışması ve floating dependency kullanımı da aynı source commit'in farklı sonuç üretmesine neden olur. Acil hotfix kaynak koda geri işlenmediğinde production bir süre sonra repository'den farklı hale gelir. Net sahiplik ve otomatik kontroller olmadığında bu küçük sapmalar birleşerek büyük ortam farklarına dönüşür.

Manuel Production Değişiklikleri

Production üzerinde manuel değişiklik hızlı çözüm gibi görünebilir. Ancak yapılan değişiklik source of truth içine dönmezse drift başlar. Aynı sorun tekrarlandığında ekip hangi durumun doğru olduğunu bilemez. Acil müdahale gerekiyorsa sonrasında Git'e geri işlenmelidir. Audit log da mutlaka korunmalıdır.

Click-Ops

Click-Ops cloud panelinden elle kaynak değiştirme alışkanlığıdır. Küçük ekiplerde başlangıçta pratik görünebilir. Zamanla hangi ayarın kim tarafından neden değiştirildiği belirsizleşir. IaC kullanımına geçiş bu farkları görünür kılar. Panel erişimi tamamen yasaklanmasa bile kontrollü tutulmalıdır.

Ortama Özel Script'ler

Her environment için farklı deployment script'i oluşturmak bakım yükünü artırır. Script'ler zamanla farklı davranışlar kazanır. Ortak bir pipeline ve environment parametreleri daha sağlıklı yaklaşım sunar. İstisnalar açık biçimde tanımlanmalıdır. Aynı kod yolu ne kadar çok kullanılırsa sürpriz o kadar azalır.

Güncellenmeyen .env Dosyaları

Lokal veya sunucu üzerinde bırakılan .env dosyaları hızla eskir. Yeni config anahtarları tüm dosyalara eklenmeyebilir. .env değerlerini kopyalamak yerine config schema merkezi tutulmalıdır. Secret değerleri repository içine eklenmemelidir. Uygulama startup sırasında eksik anahtarları kontrol etmelidir.

Farklı Deployment Pipeline'ları

Development, staging ve production için ayrı pipeline kodları zaman içinde ayrışır. Production adımlarının staging üzerinde test edilmemesi risk oluşturur. Tek bir reusable pipeline tercih edilmelidir. Environment farklılıkları parametre ve approval seviyesinde yönetilebilir. Böylece promotion zinciri daha öngörülebilir olur.

Floating Dependency Version'ları

Floating dependency sürümleri her build'in farklı paket çözmesine neden olabilir. Bugün başarılı olan build yarın farklı sonuç verebilir. Lock file ve version pinning bu riski azaltır. Paket güncellemeleri kontrollü pull request ile yapılmalıdır. Dependency değişikliği uygulama değişikliği kadar görünür olmalıdır.

latest Container Tag Kullanımı

latest etiketi hangi image'ın çalıştığını belirsiz hale getirir. Aynı tag zaman içinde farklı image digest'lerine işaret edebilir. Environment parity kontrolü bu durumda güvenilir olmaz. Immutable tag veya digest kullanmak daha güvenlidir. Production deploy kaydında digest tutulmalıdır.

Acil Hotfix'lerin Kaynağa Geri İşlenmemesi

Production üzerinde yapılan acil hotfix bazen gerekli olabilir. Sorun, bu değişikliğin source repository'ye geri dönmemesidir. Bir sonraki deployment hotfix'i silebilir. Müdahale sonrasında code, IaC veya config değişikliği mutlaka kaynak gerçekliğe işlenmelidir. Bu işlem incident kapanış kriterine eklenebilir.

Ortam Sahipliğinin Belirsiz Olması

Hiç kimsenin sahiplenmediği environment zamanla bozulur. Kim config güncelleyecek, kim drift alarmını inceleyecek ve kim exception onaylayacak bilinmelidir. Ownership matrisi basit olabilir. Önemli olan sorumlulukların görünür olmasıdır. Sahiplik özellikle staging ortamının güvenilirliği için kritiktir.

Tek Bir Source of Truth Nasıl Oluşturulur?

Tek bir source of truth oluşturmanın amacı uygulamanın beklenen durumunu merkezi ve sürümlenebilir hale getirmektir. Git bu iş için en sık kullanılan temel araçtır çünkü code review, commit geçmişi ve değişiklik takibi sağlar. Application code, infrastructure code, configuration schema, database migration, deployment manifest ve policy tanımları mümkün olduğunca repository üzerinden yönetilebilir. Secret değerleri Git'e yazılmamalıdır, ancak secret şeması veya referans isimleri sürümlenebilir. Böyle bir yapı sayesinde production'ın beklenen durumu konuşmalarla değil kod ve manifestlerle tanımlanır.

Git'i Kaynak Gerçek Olarak Kullanmak

Git yalnızca application code saklama alanı olarak görülmemelidir. Infrastructure ve deployment tanımları da burada sürümlenebilir. Pull request geçmişi değişikliğin nedenini göstermeye yardımcı olur. Rollback yapılacak durumda önceki istenen duruma dönmek kolaylaşır. GitOps yaklaşımı bu fikri daha ileri taşır.

Application Code

Application code doğal olarak source control içinde tutulmalıdır. Ancak build çıktıları source code ile karıştırılmamalıdır. Her release belirli commit ile ilişkilendirilmelidir. Commit SHA artifact metadata içine yazılabilir. Böylece production sürümü kolayca izlenir.

Infrastructure Code

Infrastructure code cloud kaynaklarının istenen durumunu tanımlar. Network, database, compute ve policy kaynakları aynı süreçten geçebilir. Manuel değişiklikler bu tanımla karşılaştırılabilir. Review süreci altyapı değişikliklerini görünür kılar. Environment bazlı parametreler ortak module içinde tutulabilir.

Configuration Schema

Configuration schema hangi anahtarların gerekli olduğunu tanımlar. Değerler ortam bazında değişse bile schema ortak kalır. Data type, zorunluluk ve default davranışı burada belirtilebilir. CI pipeline config doğrulaması yapabilir. Uygulama da startup sırasında aynı schema'yı kullanabilir.

Database Migrations

Database migrations source control içinde versioned olarak tutulmalıdır. Migration sırası değiştirilemez olmalıdır. Her ortam aynı migration geçmişini izlemelidir. Manuel SQL değişiklikleri mümkün olduğunca engellenmelidir. Böylece schema değişikliği code deployment kadar izlenebilir hale gelir.

Deployment Manifests

Kubernetes manifestleri, Helm chart'ları veya diğer deployment tanımları sürümlenmelidir. Environment overrides sınırlı ve açık tutulmalıdır. Deployment süreci bu dosyalardan çalışmalıdır. Production üzerinde farklı bir manifest kopyası tutulmamalıdır. Tek kaynak yaklaşımı drift riskini azaltır.

Policy Definitions

Güvenlik ve platform kuralları da code olarak ifade edilebilir. Public port, encryption veya approved runtime kuralları buna örnektir. Policy değişikliği pull request ile incelenebilir. CI veya admission controller bu kuralları uygulayabilir. Böylece standartlar doküman seviyesinden otomasyona taşınır.

Feature Flag Definitions

Feature flag isimleri, sahipleri ve yaşam döngüsü merkezi kayıt altında tutulmalıdır. Flag değerleri environment bazında farklı olabilir. Ancak tanımsız veya unutulmuş flag'ler drift oluşturur. Promotion akışı hangi flag'in ne zaman production'a geçeceğini göstermelidir. Eski flag'ler düzenli olarak temizlenmelidir.

Build Once, Deploy Many Yaklaşımı

Build once, deploy many yaklaşımı bir uygulama artifact'inin yalnızca bir kez üretilip aynı çıktı olarak development, staging ve production zincirinde ilerletilmesini önerir. Bu yaklaşım yeniden build nedeniyle oluşabilecek dependency, base image veya build tool farklarını ortadan kaldırır. Staging'de test edilen image ile production'da çalışan image aynı digest'e sahip olduğunda gerçek bir promotion zinciri oluşur. Environment'a özgü ayarlar image içine gömülmek yerine runtime config olarak verilmelidir. Docker Kubernetes ve CI/CD ile development staging production ortam yönetimi kuran ekipler için bu model en güçlü environment parity tekniklerinden biridir.

Her Ortam İçin Yeniden Build Etmek Neden Risklidir?

Her environment için yeniden build almak çıktıların farklılaşmasına neden olabilir. Floating dependency veya değişen base image buna örnektir. Aynı commit kullanılsa bile binary aynı olmayabilir. Bu durumda staging üzerinde test edilen artifact production'da gerçekte kullanılmamış olur. Tek build bu belirsizliği ortadan kaldırır.

CI Pipeline'da Tek Artifact Üretimi

CI pipeline testlerden sonra tek artifact üretmelidir. Artifact immutable registry içine gönderilmelidir. Commit SHA ve build metadata kaydedilebilir. Sonraki ortamlar aynı artifact referansını kullanır. Ortama özgü configuration runtime sırasında eklenir.

Dev → Staging → Production Artifact Promotion

Promotion yaklaşımı artifact'in güven seviyesini adım adım artırır. Development testleri geçen image staging'e alınır. Staging entegrasyon ve UAT testlerinden sonra production onayı verilir. Artifact yeniden oluşturulmaz. Yalnızca deployment hedefi değişir.

Immutable Artifact Nedir?

Immutable artifact yayınlandıktan sonra içeriği değişmeyen build çıktısıdır. Aynı version etiketi başka içerikle üzerine yazılmamalıdır. Container registry bu davranışı policy ile zorlayabilir. Immutable artifact audit işlemlerini kolaylaştırır. Rollback sırasında hangi çıktıya dönüldüğü kesin olarak bilinir.

Container Image Digest

Container image digest image içeriğinin benzersiz kimliğidir. Tag değişebilir, digest ise içerikle ilişkilidir. Deployment manifestinde digest kullanılması belirsizliği azaltır. Staging ve production digest karşılaştırması parity kontrolüne eklenebilir. Bu yaklaşım supply-chain güvenliğine de katkı sağlar.

Artifact Registry

Artifact registry build çıktılarının merkezi saklama alanıdır. Erişim politikaları environment rolüne göre ayarlanabilir. Image retention ve vulnerability scanning burada uygulanabilir. Promotion süreci registry metadata üzerinden izlenebilir. Registry olmadan tek artifact modelini yönetmek zorlaşır.

Production'da Hangi Artifact'in Çalıştığı Nasıl Kanıtlanır?

Production deployment kaydı image digest, commit SHA ve pipeline run kimliği içermelidir. Runtime üzerinde çalışan pod veya container digest'i ayrıca okunabilir. Bu bilgi deployment kaydıyla karşılaştırılabilir. Observability sistemine version etiketi gönderilebilir. Incident sırasında hangi kodun çalıştığı saniyeler içinde görülebilir.

Containerization ile Ortam Tutarlılığı

Containerization, uygulamanın runtime ve sistem dependency'lerini paketleyerek ortamlar arasındaki farkları azaltır. Docker kullanıldığında geliştirici, staging ve production aynı temel image üzerinden çalışabilir. Bu tek başına tüm parity sorunlarını çözmez çünkü database, network ve configuration hâlâ farklılaşabilir. Yine de runtime standardizasyonu açısından çok güçlü bir temel sağlar. Container güvenliği ve image yönetimi konusunda daha ayrıntılı bilgi için https://www.diyarbakiryazilim.com.tr/posts/konteyner-guvenligi-imaj-taramasi-ve-yetki-sinirlandirma kaynağı incelenebilir.

Docker ile Runtime Standardizasyonu

Docker runtime dependency'lerini application code ile birlikte tanımlamayı sağlar. Geliştirici aynı image tabanını lokal ortamda çalıştırabilir. Staging ve production aynı Dockerfile'dan üretilen artifact'i kullanabilir. Host işletim sistemi farklarının etkisi azalır. Bununla birlikte kernel veya architecture farkları ayrıca değerlendirilmelidir.

Base Image Version Pinning

Base image yalnızca major tag ile bırakılmamalıdır. Sabit sürüm veya digest tercih edilmelidir. Aksi halde aynı Dockerfile farklı zamanda farklı image üretebilir. Base image güncellemeleri kontrollü biçimde yapılmalıdır. Security patch süreci version pinning ile birlikte planlanmalıdır.

Dependency Lock Files

Lock file uygulama dependency ağacını sabitler. npm, pnpm, Poetry veya benzeri araçlarda bu dosya build'in önemli parçasıdır. Lock file değiştirilmeden dependency sonucu değişmemelidir. CI immutable install modunu kullanabilir. Böylece development ve production dependency seti eşleşir.

Multi-Stage Builds

Multi-stage build derleme araçlarını final image'dan ayırmaya yardımcı olur. Final runtime image daha küçük ve kontrollü olur. Build ve runtime dependency'leri açık biçimde ayrılır. Aynı Dockerfile farklı hedefler için kullanılabilir. Security scanning de daha temiz sonuç üretir.

Development ve Production Container Farkları

Development container hot reload veya debug araçları içerebilir. Production container ise minimum runtime dependency ile çalışmalıdır. Bu fark kabul edilebilir, ancak temel runtime sürümü aynı tutulmalıdır. Ortak base stage kullanmak iyi bir yöntemdir. Production davranışını lokal olarak test etmek için production target da çalıştırılabilmelidir.

Docker Compose ile Lokal Production-Like Ortam

Docker Compose geliştiricinin uygulama, database, cache ve queue gibi bağımlılıkları birlikte çalıştırmasını kolaylaştırır. Servis sürümleri production ile eşleştirilebilir. Lokal veri synthetic veya seed verisi olabilir. Network isimleri production ile aynı olmak zorunda değildir. Ama bağımlılık türlerinin ve port davranışlarının benzer olması hata yakalama oranını artırır.

Artifact Supply-Chain Güvenliği

Ortam parity yalnızca doğru artifact'in taşınmasıyla bitmez; artifact'in güvenilir kaynaktan geldiğinin de kanıtlanması gerekir. Supply-chain güvenliği build çıktısının kim tarafından, hangi source commit'ten ve hangi pipeline üzerinden üretildiğini doğrulamayı amaçlar. Digest pinning, signing, provenance, SBOM ve vulnerability scanning bu zincirin temel kontrolleridir. Production promotion öncesi güvenlik kapısı kullanılması değiştirilmiş veya riskli artifact'lerin canlıya çıkmasını önler. Bu yaklaşım özellikle çok sayıda servis ve ekip bulunan yapılarda manuel güven varsayımını azaltır.

Image Digest Pinning

Digest pinning deploy edilen image içeriğini kesin olarak sabitler. Tag reuse riskini ortadan kaldırır. Kubernetes manifesti doğrudan digest referansı kullanabilir. Promotion sırasında digest değişmediği doğrulanabilir. Bu kontrol basit ama oldukça etkilidir.

Artifact Signing

Artifact signing build çıktısının güvenilir pipeline tarafından üretildiğini doğrulamaya yardımcı olur. İmza production admission aşamasında kontrol edilebilir. İmzasız image'ların deploy edilmesi engellenebilir. Signing key erişimi sıkı tutulmalıdır. Anahtar rotation süreci ayrıca planlanmalıdır.

Provenance

Provenance artifact'in nasıl üretildiği hakkında metadata sağlar. Source commit, build sistemi ve dependency bilgileri kaydedilebilir. Incident sırasında artifact kökeni daha hızlı araştırılır. Promotion gate provenance doğrulaması yapabilir. Bu bilgi supply-chain görünürlüğünü güçlendirir.

SBOM

SBOM artifact içinde bulunan yazılım bileşenlerinin envanteridir. Güvenlik açığı duyurulduğunda hangi servislerin etkilendiği daha hızlı bulunabilir. Her build için SBOM üretilebilir. Registry veya security platformunda saklanabilir. Environment parity açısından da kullanılan dependency içeriğini doğrulamaya yardımcı olur.

Vulnerability Scanning

Container image'ları production promotion öncesinde taranmalıdır. Kritik açıklar policy'e göre deployment'ı durdurabilir. Tarama yalnızca build sırasında değil registry üzerinde de düzenli tekrarlanabilir. Yeni güvenlik açığı eski artifact'i sonradan riskli hale getirebilir. Exception süreci açıkça tanımlanmalıdır.

Production Promotion Öncesi Security Gate

Security gate artifact signature, vulnerability seviyesi ve provenance kontrolü yapabilir. Gerekiyorsa SBOM policy'leri de doğrulanabilir. Gate otomatik olmalı ve yalnızca yetkili exception ile aşılmalıdır. Sonuç deployment kaydına eklenmelidir. Böylece güvenlik kontrolü sonradan yapılan manuel iş olmaktan çıkar.

Infrastructure as Code ile Ortam Senkronizasyonu

Infrastructure as Code yaklaşımı development, staging ve production altyapısını tekrar üretilebilir tanımlar haline getirir. Sunucu, network, database, IAM ve diğer cloud kaynakları kod üzerinden yönetildiğinde ortam farkları daha kolay görülebilir. Aynı module farklı environment parametreleriyle kullanılarak kopya altyapı kodundan kaçınılabilir. Bu yöntem dev staging prod ortamlarında konfigürasyon tutarlılığı nasıl sağlanır sorusunun altyapı tarafındaki en güçlü cevaplarından biridir. Plan ve diff çıktıları sayesinde beklenen durum ile gerçek durum arasındaki fark deployment öncesinde veya düzenli kontroller sırasında yakalanabilir.

Infrastructure as Code Nedir?

Infrastructure as Code altyapının deklaratif veya programatik tanımlarla yönetilmesidir. Manuel konsol adımları yerine versioned dosyalar kullanılır. Değişiklikler code review sürecinden geçebilir. Aynı yapı tekrar üretilebilir. Drift detection için beklenen durum netleşir.

Terraform / OpenTofu

Terraform ve OpenTofu deklaratif altyapı tanımı için yaygın seçeneklerdir. Module yapısı ortak environment standardı kurmayı kolaylaştırır. Environment parametreleri tfvars gibi dosyalarla ayrılabilir. Plan çıktısı değişikliği deployment öncesinde gösterir. State yönetimi güvenli ve kontrollü tasarlanmalıdır.

Pulumi

Pulumi altyapıyı genel amaçlı programlama dilleriyle tanımlamaya olanak verir. Ekip mevcut dil bilgisini infrastructure code için kullanabilir. Stack yapısı environment ayrımını kolaylaştırır. Ortak component'ler tekrar kullanılabilir. State ve secret yönetimi yine dikkatli planlanmalıdır.

CloudFormation / Bicep

CloudFormation ve Bicep belirli cloud ekosistemlerinde native IaC yaklaşımı sunar. Provider ile daha doğrudan entegrasyon avantajı sağlayabilir. Template veya module tekrar kullanımı environment parity için önemlidir. Parametreler ortam farklarını yönetebilir. Hangi araç seçilirse seçilsin temel prensip kod üzerinden kontrollü değişikliktir.

Aynı Module'ü Tüm Ortamlarda Kullanmak

Ortak module kullanımı environment'ların aynı mimari kalıbı paylaşmasını sağlar. Module bug fix'i tüm ortamlar için uygulanabilir hale gelir. Kopyalanmış kod zaman içinde ayrışmaz. Parametrelerle kapasite farkları yönetilebilir. Bu yaklaşım parity ve bakım maliyeti arasında iyi denge kurar.

Environment-Specific Parameters

Her ortam için farklı olabilecek değerler açık parametreler olarak tanımlanmalıdır. Instance size, replica count veya domain buna örnektir. Parametre listesi kontrolsüz büyümemelidir. Çok fazla environment override aslında farklı mimariler oluşturabilir. Ortak default değerler tercih edilmelidir.

Duplicate IaC Kodundan Kaçınmak

Development, staging ve production için üç ayrı altyapı klasörünü kopyalamak kısa vadede kolay görünür. Ancak her değişikliğin üç yerde uygulanması gerekir. Bir ortamın unutulması drift oluşturur. Ortak module ve küçük parametre dosyaları daha sürdürülebilir olur. Kod tekrarı parity'nin doğal düşmanlarından biridir.

Infrastructure Kodunun Ortamlara Göre Parametrelenmesi

Infrastructure kodunu parametrelemek, ortak mimariyi korurken ortamların gerçek ihtiyaçlarına uyum sağlamayı mümkün kılar. Production daha güçlü instance, daha fazla replica ve daha uzun backup retention kullanabilir. Staging aynı module'ü daha düşük kapasite değerleriyle çalıştırabilir. Domain veya availability zone sayısı gibi farklılıklar açık değişkenler halinde tutulmalıdır. Parametreler arttıkça her farkın neden var olduğu belgelenmeli ve yanlışlıkla mimari ayrışma oluşup oluşmadığı düzenli olarak kontrol edilmelidir.

Instance Size

Instance size environment'a göre değişebilir. Production trafik gereksinimi daha yüksek olabilir. Staging daha küçük kaynakla fonksiyonel testleri sürdürebilir. Performans testi gerekiyorsa geçici kapasite artırımı yapılabilir. Değerler code içinde hard-code edilmemelidir.

Replica Count

Replica count environment parametresi olarak tanımlanabilir. Production yüksek erişilebilirlik için daha fazla replica kullanabilir. Staging düşük maliyet için daha az replica çalıştırabilir. Çoklu replica davranışlarının test edilmesi gerektiğinde staging ölçeklenebilir. Deployment manifest yapısı aynı kalmalıdır.

Autoscaling

Autoscaling policy mantığı ortamlar arasında benzer tutulmalıdır. Minimum ve maksimum sınırlar değişebilir. Metric türü ve scaling davranışı aynı kalabilir. Staging üzerinde policy'nin doğru tetiklendiği test edilebilir. Production kapasitesi gerçek trafik gereksinimine göre belirlenir.

Domain

Her environment ayrı domain veya subdomain kullanmalıdır. Domain değeri konfigürasyon parametresi olabilir. Uygulama kodu domain adına göre farklı business logic çalıştırmamalıdır. CORS ve cookie ayarları domain farkını dikkate almalıdır. TLS sertifikaları environment'a özgü olmalıdır.

Backup Retention

Backup retention production'da daha uzun olabilir. Staging üzerinde kısa retention maliyeti azaltır. Backup formatı ve restore yöntemi mümkün olduğunca aynı kalmalıdır. Restore testleri düzenli yapılmalıdır. Kişisel veri içeren non-prod backup'ları ayrıca kontrol edilmelidir.

Availability Zone Sayısı

Production birden fazla availability zone kullanabilir. Staging maliyet nedeniyle tek zone üzerinde çalışabilir. Bu farkın failover testlerini sınırladığı bilinmelidir. Yüksek erişilebilirlik senaryosu test edilecekse geçici production-like ortam kurulabilir. Mimari parametre yine aynı module içinde kalmalıdır.

Environment-Specific tfvars / Stack Config

Environment-specific parametre dosyaları farkları merkezi biçimde gösterir. Bu dosyalarda secret tutulmamalıdır. Code review sırasında staging ve production değerleri kolay karşılaştırılır. Default değerler ortak module içinde kalabilir. Parametre dosyası parity contract ile birlikte değerlendirilmelidir.

Infrastructure Drift Nasıl Tespit Edilir?

Infrastructure drift tespitinin temeli desired state ile actual state arasındaki farkı düzenli olarak ölçmektir. IaC kullanan ekipler plan komutları, state karşılaştırmaları ve cloud resource diff mekanizmalarıyla bu kontrolü otomatik hale getirebilir. Kontrol yalnızca deployment öncesi değil belirli aralıklarla da çalıştırılmalıdır çünkü production üzerinde beklenmedik manuel değişiklikler yapılabilir. Kritik drift oluştuğunda alarm üretilmeli ve değişikliğin bilinçli olup olmadığı incelenmelidir. Güvenli durumlarda otomatik reconciliation kullanılabilir, ancak destructive işlemler için insan onayı daha uygun olabilir.

Desired State vs Actual State

Desired state repository'de tanımlanan beklenen altyapıdır. Actual state cloud üzerinde gerçekten çalışan kaynakları temsil eder. Drift bu iki durum arasındaki farktır. Karşılaştırma düzenli yapılmalıdır. Farkın bilinçli olup olmadığı ayrıca değerlendirilmelidir.

Terraform Plan

Terraform plan mevcut state ile code arasındaki değişiklikleri gösterir. Beklenmeyen plan çıktısı drift işareti olabilir. Plan CI içinde scheduled job olarak çalıştırılabilir. Destructive değişiklikler ayrı alarm üretebilir. Plan sonucu ekip tarafından incelenebilir.

State Comparison

State verisi altyapının izlenen durumunu temsil eder. Gerçek kaynaklarla state arasında da fark oluşabilir. Refresh veya provider sorguları bu farkı görünür hale getirir. State dosyası güvenli backend üzerinde tutulmalıdır. Yetkisiz state değişikliği engellenmelidir.

Cloud Resource Diff

Cloud provider API'lerinden resource metadata okunarak karşılaştırma yapılabilir. Tag, firewall rule veya instance setting gibi alanlar kontrol edilebilir. Bu yöntem IaC dışında kalan kaynaklarda da faydalıdır. Sonuç merkezi dashboard'a gönderilebilir. Beklenmeyen farklar incident veya ticket oluşturabilir.

Scheduled Drift Detection

Drift detection günlük veya haftalık scheduled job olarak çalıştırılabilir. Kritik production altyapılarında daha sık kontrol tercih edilebilir. Sonuç yalnızca log olarak bırakılmamalıdır. Yeni drift oluştuğunda owner bilgilendirilmelidir. Uzun süredir devam eden drift ayrıca raporlanmalıdır.

Drift Alarmı

Her drift aynı önemde değildir. Public port açılması kritik alarm oluşturabilirken tag farkı düşük seviyede değerlendirilebilir. Risk sınıflandırması alarm yorgunluğunu azaltır. Alarm ilgili resource owner'a yönlendirilmelidir. Exception kaydı bulunan farklar filtrelenebilir.

Otomatik Reconciliation

Bazı drift türleri otomatik olarak desired state'e geri döndürülebilir. GitOps controller'ları bu modeli sürekli uygular. Ancak destructive değişikliklerde otomatik düzeltme dikkatle kullanılmalıdır. Önce dry-run ve policy kontrolü yapılabilir. Reconciliation sonucu audit log'a yazılmalıdır.

Production'da Manuel Değişikliklere İzin Verilmeli mi?

Production üzerinde manuel değişiklikleri tamamen yasaklamak her organizasyon için gerçekçi olmayabilir, ancak normal çalışma şekli haline gelmeleri ciddi risk oluşturur. No-ClickOps yaklaşımı günlük değişikliklerin IaC, config-as-code ve CI/CD üzerinden yapılmasını hedefler. Acil durumlar için break-glass erişim tanımlanabilir ve bu erişim güçlü audit ile sınırlandırılabilir. Manuel hotfix sonrasında yapılan değişiklik Git'e geri yazılmalı ve drift temizlenmelidir. Böylece acil müdahale kabiliyeti korunurken production'ın görünmeyen bir konfigürasyon adasına dönüşmesi engellenir.

No-ClickOps Yaklaşımı

No-ClickOps günlük production değişikliklerinin panel üzerinden yapılmamasını hedefler. Değişiklikler code ve pipeline üzerinden uygulanır. Bu yaklaşım audit ve tekrar üretilebilirlik sağlar. Read-only console erişimi yine kullanılabilir. Acil durum prosedürü ayrıca tanımlanmalıdır.

Emergency Break-Glass Access

Break-glass access olağanüstü durumda kullanılan geçici yüksek yetkidir. Normal kullanıcı hesabından ayrı tutulmalıdır. MFA ve kısa süreli token tercih edilebilir. Kullanım başladığında güvenlik kaydı oluşturulmalıdır. İşlem sonrasında kapsamlı review yapılmalıdır.

Hotfix Sonrası Git'e Geri Yazma

Manuel hotfix kalıcı çözüm değildir. Değişiklik ilgili code veya IaC tanımına geri işlenmelidir. Aynı düzeltme staging üzerinde de uygulanmalıdır. Böylece bir sonraki deployment değişikliği kaybetmez. Incident kapatılmadan önce bu adım doğrulanabilir.

Drift Reconciliation

Hotfix sonrasında actual state ile desired state yeniden eşleştirilmelidir. IaC plan çıktısı kontrol edilebilir. Gerekirse source of truth güncellenir veya manuel değişiklik geri alınır. Belirsiz durum bırakılmamalıdır. Son durum kayıt altına alınmalıdır.

Audit Trail

Production değişikliklerinin kim tarafından yapıldığı bilinmelidir. Audit trail zaman, kullanıcı, kaynak ve işlem bilgisini içermelidir. Pipeline deployment kayıtları da aynı zincire eklenebilir. Incident araştırmalarında bu bilgi önemli zaman kazandırır. Log retention güvenlik politikasına göre belirlenmelidir.

Configuration Management Nasıl Tasarlanır?

Configuration management tasarımında en önemli kural code ile environment-specific değerleri birbirinden ayırmaktır. Uygulama aynı artifact ile tüm ortamlarda çalışmalı, değişen değerler runtime sırasında config katmanından gelmelidir. Base configuration ortak default değerleri tanımlarken environment-specific overrides yalnızca gerçekten gerekli farkları içermelidir. Environment variable, config-as-code veya merkezi configuration store seçenekleri kullanılabilir. Typed configuration ve startup validation uygulanması dev staging prod ortamlarında konfigürasyon tutarlılığı nasıl sağlanır sorusuna pratik ve sürdürülebilir bir cevap verir.

Config ile Code'u Ayırmak

Environment'a özgü değerler application code içine gömülmemelidir. Aynı binary farklı environment config ile çalışabilmelidir. Böylece build once, deploy many yaklaşımı uygulanabilir. Config değişikliği ayrıca versionlanabilir. Secret değerleri farklı kanaldan sağlanmalıdır.

Base Configuration

Base configuration tüm ortamların ortak default değerlerini tanımlar. Bu dosya minimum sayıda değişken içermelidir. Environment override dosyaları yalnızca farklı değerleri belirtmelidir. Böylece hangi farkların bilinçli olduğu kolay görülür. Aşırı override parity'yi zayıflatır.

Environment-Specific Overrides

Environment-specific override domain, replica veya endpoint gibi farklılıkları taşır. Override listesi küçük tutulmalıdır. Her yeni farkın nedeni sorgulanmalıdır. Ortam adına göre code branch oluşturmak yerine değer değişikliği tercih edilmelidir. Override dosyaları code review sürecinden geçmelidir.

Environment Variable

Environment variable container ve cloud ortamlarında yaygın config mekanizmasıdır. Anahtar isimleri tüm ortamlarda aynı tutulmalıdır. Değerler deployment sistemi tarafından sağlanabilir. Hassas değerler plain text manifest içinde tutulmamalıdır. Uygulama başlangıçta tip ve zorunluluk kontrolü yapmalıdır.

Config-as-Code

Config-as-code non-secret konfigürasyonun version control içinde tutulmasını sağlar. Değişiklik geçmişi ve review süreci görünür olur. Environment dosyaları diff edilebilir. Deployment pipeline uygun config sürümünü seçebilir. Secret referansları config içinde bulunabilir ama değerler ayrı tutulmalıdır.

Central Configuration Store

Merkezi configuration store dinamik config ihtiyacı olan sistemlerde yararlıdır. Uygulamalar config'i runtime sırasında okuyabilir. Versioning ve access control kritik öneme sahiptir. Ortam namespace'leri açıkça ayrılmalıdır. Değişikliklerin audit kaydı tutulmalıdır.

Typed Configuration

Typed configuration yanlış veri tiplerini erken yakalar. Örneğin integer beklenen timeout değerinin metin gelmesi startup hatasına dönüşebilir. Schema version control içinde tutulabilir. CI config dosyalarını aynı schema ile doğrular. Runtime doğrulaması ikinci güvenlik katmanı sağlar.

Config Schema Parity Nedir?

Config schema parity, ortamların aynı configuration anahtar yapısını paylaşmasını ifade eder. Burada değerlerin aynı olması beklenmez çünkü database adresi, domain veya credentials doğal olarak farklıdır. Önemli olan gerekli anahtarların tüm ortamlarda bulunması, bilinmeyen anahtarların kullanılmaması ve veri tiplerinin eşleşmesidir. Startup validation sayesinde eksik config production deploy anında sessizce hatalı davranmak yerine açık hata verebilir. CI içinde çalışan config validation ise problemi deployment aşamasına gelmeden yakalayarak ortam senkronizasyonunu daha güvenilir hale getirir.

Aynı Anahtarlar, Farklı Değerler

Schema parity aynı anahtar setini hedefler. DATABASE_URL her ortamda bulunabilir, ancak değeri farklıdır. Aynı prensip API endpoint veya log level için geçerlidir. Bu model config yapısını öngörülebilir kılar. Secret değerlerin eşleşmesi beklenmemelidir.

Eksik Environment Variable Tespiti

Eksik environment variable uygulama başlamadan önce tespit edilmelidir. Startup validation fail-fast davranışı sağlayabilir. CI deployment manifestlerini schema ile kontrol edebilir. Eksik anahtar production incident'ına dönüşmeden görülür. Error mesajı hangi anahtarın eksik olduğunu açıkça belirtmelidir.

Unknown Config Key Kontrolü

Tanımsız config anahtarları typo veya eski ayar işareti olabilir. Schema unknown key kullanımını reddedebilir. Böylece yanlış yazılan değişken sessizce yok sayılmaz. Eski anahtarların temizlenmesi kolaylaşır. Config dosyaları zamanla sade kalır.

Startup Validation

Startup validation uygulama ayağa kalkarken config'in geçerli olduğunu doğrular. Zorunlu alan, veri tipi ve format kontrolü yapılabilir. Geçersiz config varsa servis ready durumuna geçmemelidir. Hata log'da açıkça görünmelidir. Kubernetes readiness mekanizmasıyla birlikte kullanılabilir.

CI İçinde Config Validation

CI doğrulaması deployment'tan önce geri bildirim sağlar. Her environment config dosyası ortak schema ile test edilebilir. Secret değerler okunmadan secret referansları doğrulanabilir. Pull request aşamasında hata görülebilir. Bu kontrol düşük maliyetli ama yüksek faydalıdır.

Config Versioning

Config değişiklikleri sürümlenmelidir. Hangi application version'ın hangi config schema ile uyumlu olduğu bilinebilir. Rollback sırasında config compatibility kontrol edilmelidir. Config change log tutulabilir. Büyük değişikliklerde migration yaklaşımı gerekebilir.

Secrets Ortamlar Arasında Nasıl Yönetilmeli?

Secret yönetiminin temel prensibi değerleri senkronize etmek değil, secret yapısını senkronize etmektir. Development, staging ve production kendi credentials, API token ve encryption key setlerine sahip olmalıdır. Ortamlar aynı secret isimlerini veya schema'sını paylaşabilir, ancak secret materyali kesin biçimde izole tutulmalıdır. Secret manager kullanımı erişim kontrolünü, rotation işlemini ve runtime injection sürecini merkezi hale getirir. Staging ve production arasında veritabanı migration secret ve environment variable yönetimi yapılırken bu ayrım güvenlik açısından en kritik noktalardan biridir.

Secret'lar Neden Senkronize Edilmemelidir?

Secret değerlerinin aynı olması environment izolasyonunu ortadan kaldırır. Staging token'ı ele geçirildiğinde production erişimi sağlanmamalıdır. Her environment ayrı kimlik ve credentials kullanmalıdır. Bu yaklaşım blast radius'u küçültür. Parity değerlerde değil schema'da kurulmalıdır.

Secret Schema Parity

Secret schema hangi secret'ların gerekli olduğunu tanımlar. PAYMENT_API_KEY tüm ortamlarda bulunabilir. Değer her ortamda farklıdır. CI yalnızca secret'ın varlığını kontrol edebilir. Secret içeriğini loglamak veya karşılaştırmak gerekmez.

Dev Credentials

Development credentials en düşük yetkiyle sınırlandırılmalıdır. Lokal geliştirici gerçek production servislerine erişmemelidir. Sandbox veya test hesapları tercih edilmelidir. Credentials kısa süreli olabilir. Kişisel cihazlarda kalıcı secret saklama azaltılmalıdır.

Staging Credentials

Staging credentials production modelini davranış açısından temsil etmelidir. Ancak eriştiği kaynaklar staging alanıyla sınırlı olmalıdır. IAM rol yapısı production'a benzer tutulabilir. Secret rotation staging üzerinde önce test edilebilir. Production değerleri hiçbir zaman kopyalanmamalıdır.

Production Credentials

Production credentials en güçlü erişim kontrolüne sahip olmalıdır. İnsan kullanıcıların doğrudan görmesi mümkün olduğunca engellenmelidir. Workload identity tercih edilebilir. Rotation otomasyonu uygulanmalıdır. Erişim audit log ile takip edilmelidir.

Secret Manager

Secret manager merkezi saklama ve erişim kontrolü sağlar. Uygulama runtime sırasında yetkili kimlikle secret okuyabilir. Secret repository veya image içine gömülmez. Rotation ve versioning yönetilebilir. Environment namespace'leri net biçimde ayrılmalıdır.

HashiCorp Vault

Vault merkezi secret ve dynamic credentials yönetimi için kullanılabilir. Policy tabanlı erişim modeli sunar. Kısa süreli database credentials üretmek mümkündür. Environment path'leri ayrı tutulabilir. Audit log aktif edilmelidir.

Cloud Secrets Managers

Cloud sağlayıcıların secret servisleri managed seçenek sunar. IAM entegrasyonu deployment işlemini kolaylaştırır. Secret rotation servis bazında otomatikleştirilebilir. Ortamlar ayrı hesap veya namespace kullanabilir. Erişim policy'leri minimum yetkiyle tasarlanmalıdır.

SOPS

SOPS encrypted configuration dosyalarını Git içinde yönetmek için kullanılabilir. Şifreli değer repository'de bulunabilir, anahtar erişimi ayrı tutulur. GitOps akışlarında kullanışlıdır. Decryption yalnızca yetkili pipeline veya controller tarafından yapılmalıdır. Key management süreci ayrıca güvence altına alınmalıdır.

Runtime Secret Injection

Secret image build sırasında eklenmemelidir. Runtime injection kullanılması aynı artifact'in tüm ortamlarda çalışmasını sağlar. Kubernetes Secret entegrasyonu veya secret manager CSI çözümleri kullanılabilir. Secret log'a yazılmamalıdır. Process environment kullanılıyorsa diagnostic çıktılar ayrıca kontrol edilmelidir.

Secret Rotation

Secret rotation düzenli ve test edilebilir olmalıdır. Uygulama mümkünse iki aktif credential arasında geçişi desteklemelidir. Rotation önce staging üzerinde doğrulanabilir. Eski secret kısa geçiş süresinden sonra kapatılmalıdır. Rotation başarısızlığı observability sisteminde görünmelidir.

Identity ve Access Control Ortamlarında Parity

Identity ve access control tarafında ortamlar aynı kullanıcıları veya aynı service account'ları paylaşmamalıdır, fakat permission modelinin mantığı benzer tutulmalıdır. Staging ortamında production'dan çok daha geniş yetki verilirse production'a özgü authorization hataları test edilemez. Her environment kendi service account setine sahip olurken rol ve policy şablonları ortak infrastructure code üzerinden üretilebilir. Least privilege ve workload identity bu modelin temel parçalarıdır. Production access ayrıca audit, MFA ve gerekirse just-in-time mekanizmalarıyla güçlendirilmelidir.

RBAC Yapısının Benzer Tutulması

RBAC rol yapıları ortamlar arasında aynı mantığı izlemelidir. Kimlikler farklı olabilir. Permission kapsamı production'a mümkün olduğunca benzer olmalıdır. Böylece staging üzerinde authorization sorunları görülebilir. Role definitions code olarak yönetilebilir.

Environment-Specific Service Accounts

Her environment ayrı service account kullanmalıdır. Production hesabı staging pod'una verilmemelidir. IAM policy aynı template'ten üretilebilir. Resource scope environment namespace'iyle sınırlandırılabilir. Credentials paylaşımı yapılmamalıdır.

Least Privilege

Service account yalnızca ihtiyaç duyduğu izinlere sahip olmalıdır. Geniş wildcard policy'ler test kolaylığı için kullanılmamalıdır. Staging'de gevşek permission production bug'larını gizler. Permission ihtiyacı kullanım verisiyle gözden geçirilebilir. Gereksiz yetkiler zamanla kaldırılmalıdır.

Workload Identity

Workload identity kalıcı credentials yerine runtime kimliği kullanmayı sağlar. Kubernetes workload cloud servisine doğrudan kimlik ile erişebilir. Secret dağıtım ihtiyacı azalır. Ortamlar ayrı identity kullanır. Policy template'i ortak tutulabilir.

Staging'de Production Permission Modelini Test Etmek

Staging permission modeli production ile aynı rol mantığını izlemelidir. Testler uygulamanın gerekli kaynaklara erişebildiğini doğrulamalıdır. Yasaklı erişimlerin başarısız olduğu da test edilmelidir. Bu negatif testler güvenlik için değerlidir. Production deployment öncesi permission gate kullanılabilir.

Production Access Audit

Production insan erişimi sürekli izlenmelidir. Kim, ne zaman ve hangi kaynağa erişti bilgisi tutulmalıdır. Yüksek yetki kullanımı ayrıca alarm oluşturabilir. Kullanılmayan hesaplar kapatılmalıdır. Periyodik access review uygulanmalıdır.

Database Ortamları Nasıl Ayrılmalı?

Database izolasyonu environment tasarımının en önemli güvenlik çizgilerinden biridir. Her environment kendi database'ine sahip olmalı ve connection credentials başka ortamlar tarafından kullanılamamalıdır. Development veya staging uygulamasının production database'e erişmesi yalnızca config seviyesinde değil network ve IAM seviyesinde de engellenmelidir. Staging database production şemasını ve temel davranışlarını temsil etmelidir, ancak gerçek müşteri verisini varsayılan olarak içermemelidir. Bu yapı yanlış deployment veya hatalı connection string durumunda gerçek veri üzerinde işlem yapılma riskini ciddi biçimde azaltır.

Her Environment İçin Ayrı Database

Her environment ayrı database kullanmalıdır. İzolasyon instance, cluster veya database seviyesinde kurulabilir. Risk seviyesi yüksek sistemlerde ayrı hesap veya network tercih edilebilir. Backup ve retention politikaları ortam bazında farklılaşabilir. Schema migration kaynağı yine ortak tutulmalıdır.

Dev'in Production Database'e Bağlanmasını Önlemek

Development network'ünden production database'e route açılmaması en güvenli yaklaşımdır. Yalnızca credentials ayrımı yeterli değildir. Firewall veya security group erişimi engellemelidir. Production database public erişime kapatılmalıdır. Acil yönetim erişimi kontrollü bastion veya JIT modeliyle sağlanabilir.

Staging Database Tasarımı

Staging aynı database engine ve major sürümü kullanmalıdır. Schema production'a yakın olmalıdır. Veri masked veya synthetic olabilir. Resource kapasitesi daha düşük tutulabilir. Migration ve query davranışlarının test edilebilmesi önceliklidir.

Connection Credentials Isolation

Database credentials environment bazında ayrılmalıdır. Service account yalnızca kendi database'ine bağlanabilmelidir. Connection string secret manager üzerinden sağlanabilir. Credential rotation ayrı yürütülmelidir. Production credential non-prod sistemlerde bulunmamalıdır.

Network Isolation

Database network erişimi uygulama subnet veya workload identity ile sınırlandırılabilir. Cross-environment route engellenmelidir. Network policy yanlış config'in etkisini azaltır. Monitoring yetkisiz bağlantı girişimlerini gösterebilir. İzolasyon hem güvenlik hem operasyonel güvenilirlik sağlar.

Database Schema Senkronizasyonu

Database schema senkronizasyonu manuel SQL kopyalamakla değil versioned migration akışıyla yönetilmelidir. Her schema değişikliği source control içinde migration dosyası olarak bulunmalı ve development, staging, production sırasıyla uygulanmalıdır. Migration version tracking sayesinde her environment'ın hangi seviyede olduğu ölçülebilir. Deployment öncesinde application artifact'in beklediği schema version ile mevcut database seviyesi karşılaştırılabilir. Bu yöntem schema drift'i azaltırken rollback ve incident araştırmalarında hangi değişikliğin ne zaman uygulandığını açık biçimde görmeyi sağlar.

Migration Dosyalarını Version Control'de Tutmak

Migration dosyaları application code ile birlikte sürümlenmelidir. Dosyalar uygulandıktan sonra değiştirilmemelidir. Yeni düzeltme yeni migration olarak eklenmelidir. Code review schema değişikliğini görünür hale getirir. Aynı dosya tüm environment'larda kullanılmalıdır.

Migration Version Tracking

Migration tool uygulanan version bilgisini database içinde tutabilir. Pipeline bu tabloyu okuyabilir. Beklenmeyen eksik veya ileri migration tespit edilebilir. Hash kontrolü değiştirilmiş eski dosyaları gösterebilir. Monitoring dashboard'da schema version gösterilebilir.

Dev → Staging → Production Migration Promotion

Migration önce development testlerinde doğrulanmalıdır. Daha sonra staging üzerinde gerçek deployment akışıyla uygulanmalıdır. Migration süresi ve lock davranışı izlenebilir. Onaylanan migration production'a aynı dosya olarak gider. Production için ayrı SQL kopyası oluşturulmamalıdır.

Deployment Öncesi Schema Version Kontrolü

Application belirli minimum schema version bekleyebilir. Pipeline deployment öncesi mevcut database seviyesini doğrulayabilir. Uyum yoksa deployment durdurulabilir. Bu kontrol yanlış sırada release yapılmasını engeller. Rollback senaryosu da aynı doğrulamada değerlendirilmelidir.

Schema Drift Detection

Migration geçmişi ile gerçek schema karşılaştırılabilir. Manuel index veya column değişikliği drift olarak görülebilir. Schema dump hash karşılaştırması kullanılabilir. Kritik farklar production gate'i durdurabilir. Beklenen istisnalar kayıt altına alınmalıdır.

Zero-Downtime Database Migration

Zero-downtime migration yaklaşımı schema değişikliği sırasında eski ve yeni application version'larının birlikte çalışabilmesini hedefler. Rolling deployment kullanan sistemlerde eski pod'lar kapanmadan yeni pod'lar trafiğe girebilir, bu nedenle database değişikliklerinin tek sürüme bağımlı olmaması gerekir. Expand, migrate ve contract adımlarına bölünen süreç bu riski yönetir. Önce geriye uyumlu alanlar eklenir, veri taşınır ve tüm uygulamalar yeni yapıyı kullanmaya başladıktan sonra eski alan kaldırılır. Destructive migration'lar ayrıca approval ve rollback planı gerektirir.

Expand–Migrate–Contract

Expand–migrate–contract schema değişikliğini güvenli adımlara böler. İlk adım yeni yapıyı eski uygulamayla uyumlu biçimde ekler. Sonra veri ve uygulama davranışı yeni yapıya geçirilir. Eski sürüm tamamen kalktıktan sonra artık kullanılmayan alan silinir. Bu model rolling deployment ile iyi çalışır.

Expand

Expand aşamasında yeni column veya table eklenir. Eski uygulama bu değişiklikten etkilenmemelidir. Required constraint hemen eklenmeyebilir. Default davranış geriye uyumlu tutulur. Migration hızlı ve düşük riskli olmalıdır.

Dual Compatibility

Dual compatibility döneminde eski ve yeni application version aynı database ile çalışabilir. Gerekirse iki alana birden yazma yapılabilir. Read path kademeli olarak değiştirilebilir. Observability ile veri uyumu izlenir. Bu dönem kısa ama kontrollü tutulmalıdır.

Backfill

Backfill eski veriyi yeni schema yapısına taşır. Büyük tablolar batch halinde işlenmelidir. Lock ve replication etkisi izlenmelidir. İşlem idempotent tasarlanabilir. Staging üzerinde production-like veri hacmiyle süre tahmini yapılabilir.

Contract

Contract aşamasında artık kullanılmayan eski schema kaldırılır. Tüm application instance'larının yeni sürüme geçtiği doğrulanmalıdır. Geri dönüş ihtimali değerlendirilmelidir. Destructive migration için ayrıca onay alınabilir. Bu adım çoğu zaman ayrı release olarak yapılmalıdır.

Backward-Compatible Schema Change

Schema değişiklikleri mümkün olduğunca backward-compatible tasarlanmalıdır. Yeni alan eklemek mevcut alanı yeniden adlandırmaktan daha güvenlidir. Constraint değişiklikleri aşamalı uygulanabilir. Application önce yeni alanı desteklemelidir. Eski alanın kaldırılması daha sonraki release'e bırakılabilir.

Rolling Deployment ile Migration Uyumu

Rolling deployment sırasında bir süre iki application version çalışır. Database her ikisiyle de uyumlu olmalıdır. Migration deployment öncesi veya kontrollü ara aşamada çalıştırılabilir. Readiness yalnızca application health değil schema compatibility de değerlendirebilir. Bu tasarım kesintisiz release için önemlidir.

Rollback Edilemeyen Migration'lar

Bazı migration'lar kolayca geri alınamaz. Veri silme veya irreversible transformation buna örnektir. Böyle durumlarda backup tek başına yeterli plan değildir. Forward fix stratejisi hazırlanmalıdır. Production öncesinde açık risk onayı alınmalıdır.

Destructive Migration Approval

Column silme veya veri kaybettiren işlem ayrı approval gerektirmelidir. Pipeline migration dosyasını analiz ederek destructive pattern tespit edebilir. Owner ve change window belirlenebilir. Backup doğrulaması yapılabilir. Onay kaydı deployment geçmişine eklenmelidir.

Production Verisi Staging'e Kopyalanmalı mı?

Production verisini doğrudan staging'e kopyalamak gerçekçi test verisi sağlar gibi görünse de ciddi gizlilik ve güvenlik riski oluşturur. KVKK kapsamında kişisel verinin amacı dışında ve gereksiz biçimde non-prod ortama taşınması dikkatle değerlendirilmelidir. Çoğu durumda masking, tokenization, anonymization veya synthetic data daha güvenli seçeneklerdir. Test verisi ilişkileri, edge case'leri ve hacim davranışını temsil etmelidir, fakat gerçek kişinin kimliğinin bilinmesini gerektirmemelidir. Backup ve snapshot kopyalarının da aynı veri güvenliği kurallarına tabi olduğu unutulmamalıdır.

Ham Production Verisi Kullanmanın Riskleri

Ham production verisi gerçek kişisel ve ticari bilgi içerir. Non-prod erişimi genellikle daha geniştir. Bu durum veri sızıntısı riskini artırır. Yanlış e-posta veya SMS gönderimi de gerçek kullanıcıları etkileyebilir. Varsayılan yaklaşım production verisini taşımamak olmalıdır.

KVKK ve Gizlilik

KVKK açısından veri işleme amacı ve gerekliliği değerlendirilmelidir. Test ihtiyacı her zaman gerçek kişisel veri kullanımını haklı çıkarmaz. Veri minimizasyonu uygulanmalıdır. Erişim ve retention politikaları ayrıca belirlenmelidir. Hukuki gereksinimler proje bağlamına göre uzmanlarla değerlendirilmelidir.

Data Masking

Data masking gerçek alanları güvenli temsillerle değiştirir. E-posta, telefon ve isim gibi PII alanları maskelenebilir. Referential integrity korunması gerekir. Aynı kullanıcı ilişkili tablolarda tutarlı biçimde maskelenmelidir. Masking işlemi otomatik pipeline olarak tasarlanabilir.

Tokenization

Tokenization hassas değeri anlamsız token ile değiştirir. Orijinal değer ayrı güvenli sistemde tutulabilir. Test ortamında token'dan gerçek veriye dönüş erişimi verilmemelidir. Format korunması gereken alanlarda yararlı olabilir. Token lifecycle ayrıca yönetilmelidir.

Anonymization

Anonymization kişinin yeniden tanımlanmasını engellemeyi hedefler. Yalnızca isim alanını silmek genellikle yeterli değildir. Birden fazla alan bir araya geldiğinde kişi yine belirlenebilir. Teknik ve bağlamsal risk değerlendirmesi gerekir. Kalıcı anonymization ile pseudonymization birbirinden ayrılmalıdır.

Synthetic Data

Synthetic data gerçek kişiden türetilmemiş test verisidir. Güvenlik açısından güçlü avantaj sunar. Edge case ve business rule senaryoları özel olarak üretilebilir. Dezavantajı production dağılımını tam temsil etmeyebilmesidir. Gelişmiş testlerde synthetic ve masked veri yaklaşımı birlikte kullanılabilir.

Production-Like Test Data

Production-like veri gerçek veri demek değildir. Benzer dağılım, hacim, ilişki ve edge case davranışı hedeflenmelidir. Performans testi için özellikle veri şekli önemlidir. Dataset versioned hale getirilebilir. Testler aynı veri setiyle tekrar çalıştırılabilir.

Veri Senkronizasyonunda Referential Integrity Nasıl Korunur?

Veri masking veya anonymization sırasında referential integrity bozulursa test ortamı gerçek davranışı temsil etmez. Aynı müşteri kimliği farklı tablolarda farklı değerlere dönüştürülmemelidir. Deterministic masking ve consistent pseudonymization yöntemleri bu ilişkileri korumaya yardımcı olur. Foreign key ilişkilerinin yanında free-text alanlarındaki kişisel bilgiler de temizlenmelidir çünkü not veya açıklama alanları sıkça gözden kaçar. Test dataset'inin versioned olması hangi verinin hangi test sonucu için kullanıldığını tekrar üretilebilir hale getirir.

Deterministic Masking

Deterministic masking aynı girdiyi aynı masked çıktıya dönüştürür. Böylece tablolar arası ilişki korunabilir. Salt veya key güvenli tutulmalıdır. Çıktı gerçek kişiyi açık etmemelidir. Test tekrarlarında aynı veri elde edilebilir.

Foreign Key İlişkileri

Foreign key değerleri rastgele değiştirilirse ilişkiler bozulabilir. Parent ve child kayıtlar birlikte dönüştürülmelidir. Database constraint testleri çalıştırılabilir. Masking pipeline sonunda integrity check yapılmalıdır. Hatalı dataset test sonuçlarını yanıltır.

Consistent Pseudonymization

Pseudonymization aynı kişinin farklı kayıtlarda tutarlı temsil edilmesini sağlar. Gerçek kimlik doğrudan görünmez. Re-identification anahtarı non-prod ortamdan ayrı tutulmalıdır. Test kullanıcı davranış zinciri korunabilir. Risk değerlendirmesi yine gereklidir.

Free-Text PII Temizliği

Free-text alanlar beklenmedik kişisel veri içerebilir. Sadece yapılandırılmış kolonları maskelemek yeterli olmayabilir. Regex ve veri sınıflandırma kontrolleri uygulanabilir. Kritik dataset'lerde örneklem doğrulaması yapılmalıdır. Log ve attachment verileri de unutulmamalıdır.

Test Dataset Versioning

Test dataset sürümlenirse test sonucu tekrar üretilebilir. Dataset kimliği pipeline run'a eklenebilir. Değişiklikler bilinçli şekilde yayınlanır. Eski bug senaryosu aynı dataset ile yeniden denenebilir. Çok büyük veri dosyaları ayrı artifact storage içinde tutulabilir.

Reference ve Master Data Senkronizasyonu

Reference ve master data çoğu ekipte infrastructure veya application code kadar dikkat çekmez, ancak iş davranışını doğrudan değiştirebilir. Ülke listeleri, para birimleri, lookup tabloları, feature configuration ve business rule kayıtları ortamlar arasında kontrolsüz biçimde farklılaşmamalıdır. Bu verileri manuel panel girişleriyle yönetmek drift riskini yükseltir. Seed data migration veya versioned configuration yaklaşımı kullanıldığında hangi değişikliğin ne zaman yapıldığı izlenebilir. Production davranışını etkileyen temel referans veriler mümkün olduğunca deployment sürecinin parçası olmalıdır.

Lookup Tables

Lookup table kayıtları application davranışını etkileyebilir. Manuel eklenen değerler diğer environment'larda unutulabilir. Migration veya seed script ile yönetmek daha güvenlidir. Unique key ve idempotent işlem tercih edilmelidir. Environment-specific lookup gerçekten gerekiyorsa belgelenmelidir.

Ülke ve Para Birimi Listeleri

Ülke ve para birimi listeleri ortak referans veri örnekleridir. Ortamlar arasında aynı version kullanılmalıdır. Güncelleme code review ile yapılabilir. Testler eksik veya duplicate kayıt kontrolü yapabilir. Business logic bu veri setine güvenebilir.

Feature Configuration

Feature configuration ile feature flag birbirine yakın ama farklı kavramlardır. Business parameter değerleri de uygulama davranışını değiştirebilir. Environment farkları bilinçli olmalıdır. Configuration store veya migration üzerinden yönetilebilir. Manuel panel değişikliği audit edilmelidir.

Business Rules

Database tablosunda tutulan business rule'lar gizli code gibi davranabilir. Environment'lar farklı rule seti kullanırsa test sonucu production'ı temsil etmez. Rules versioned hale getirilebilir. Değişiklik approval sürecinden geçebilir. Rule version observability metadata içine eklenebilir.

Seed Data Migrations

Seed data migration gerekli referans kayıtlarını versioned biçimde oluşturur. Script idempotent olmalıdır. Tekrar çalıştırıldığında duplicate üretmemelidir. Environment promotion zincirinde sırayla uygulanabilir. Veri değişikliği deployment history ile ilişkilendirilir.

Manuel Veri Girişini Önleme

Production panelinden manuel referans veri eklemek hızlı görünebilir. Ancak staging bu değişiklikten habersiz kalır. Mümkünse yönetim işlemi versioned workflow'a bağlanmalıdır. Manuel işlem gerekiyorsa export ve reconciliation yapılmalıdır. Audit kaydı tutulmalıdır.

Staging Production Veri Hacmini Taklit Etmeli mi?

Staging'in production kadar büyük veri taşıması her zaman gerekli değildir. Functional parity uygulamanın aynı iş kurallarını ve entegrasyon davranışını göstermesine odaklanırken scale parity performans ve kapasite sorunlarını ölçer. Küçük dataset fonksiyonel test için yeterli olabilir, fakat yavaş query, uzun migration, index problemi veya queue backlog gibi sorunları gizleyebilir. Bu nedenle yüksek hacim testlerini staging'e sürekli yüklemek yerine ayrı ve geçici load test ortamı oluşturmak maliyet açısından daha mantıklı olabilir. Hangi testin hangi ortamda yapıldığı açıkça tanımlanmalıdır.

Functional Parity vs Scale Parity

Functional parity aynı davranışı doğrulamayı hedefler. Scale parity ise aynı yük koşullarına yaklaşmayı amaçlar. İki hedef farklı altyapı ihtiyacı doğurur. Staging çoğu zaman functional parity için kullanılır. Performans için ayrı environment tercih edilebilir.

Neden Küçük Dataset Bazı Sorunları Gizler?

Küçük tablolar index olmadan da hızlı sorgulanabilir. Production veri büyüdüğünde aynı query saniyeler sürebilir. Migration lock süresi de veri miktarıyla artar. Queue veya batch işlemleri aynı şekilde farklı davranır. Bu yüzden scale test ayrıca planlanmalıdır.

Query Performance

Query performance gerçekçi cardinality ile test edilmelidir. Synthetic büyük veri bu amaçla üretilebilir. Query plan değişiklikleri izlenebilir. Critical endpoint'ler için performans budget tanımlanabilir. Production slow query verisi test senaryolarına dönüştürülebilir.

Migration Duration

Migration küçük staging database üzerinde saniyeler sürebilir. Production'da aynı işlem dakikalar veya saatler alabilir. Büyük tablo operasyonları benchmark edilmelidir. Backfill batch boyutu test edilebilir. Change window buna göre planlanabilir.

Queue Backlog

Queue davranışı düşük hacimde sorunsuz görünebilir. Production peak trafik büyük backlog oluşturabilir. Worker concurrency ve retry policy load testinde doğrulanmalıdır. Dead-letter queue kapasitesi de gözlenmelidir. Test ortamı gerçek third-party servisleri gereksiz yere tetiklememelidir.

Load Test Ortamının Ayrılması

Load test staging kullanıcılarını etkilememelidir. Ayrı geçici environment daha sağlıklı sonuç verir. Production benzeri kapasite kısa süreli açılabilir. Test sonrasında kaynaklar temizlenebilir. Maliyet ve izolasyon birlikte yönetilir.

Third-Party API'ler Ortamlar Arasında Nasıl Senkronize Edilir?

Third-party entegrasyonlarda parity sağlayabilmek için aynı API version ve benzer request akışını kullanmak gerekir, fakat endpoint ve credentials environment bazında ayrılmalıdır. Sandbox servisleri staging ve development için güvenli seçenek sunar. Payment, e-posta, SMS ve webhook entegrasyonlarında gerçek kullanıcıya işlem gitmesini engelleyen korumalar bulunmalıdır. OAuth callback domain'leri ve rate limit farkları ayrıca test edilmelidir. Sandbox davranışı production'dan çok farklıysa contract test veya mocking kullanılarak uygulamanın kendi entegrasyon davranışı güvence altına alınabilir.

Sandbox vs Production Endpoint

Sandbox endpoint test işlemleri için kullanılmalıdır. Production endpoint yalnızca canlı ortam tarafından çağrılmalıdır. Endpoint değeri config üzerinden sağlanır. API contract mümkün olduğunca aynı kalmalıdır. Sandbox kısıtları belgelenmelidir.

API Version Parity

Tüm ortamlar aynı API version'ı hedeflemelidir. Staging eski version kullanıyorsa production upgrade riski test edilemez. Version header veya endpoint açık config olabilir. Deprecation duyuruları izlenmelidir. Upgrade önce non-prod ortamda doğrulanmalıdır.

Payment Gateway

Payment entegrasyonu staging'de sandbox hesabıyla çalışmalıdır. Gerçek kart veya tahsilat işlemi oluşturulmamalıdır. Webhook akışı sandbox üzerinde test edilebilir. Error ve timeout senaryoları ayrıca simüle edilmelidir. Production credentials kesin olarak ayrılmalıdır.

E-posta ve SMS

Non-prod ortamlar gerçek müşteriye mesaj göndermemelidir. Sink mailbox veya allowlist kullanılabilir. Telefon numaraları synthetic tutulabilir. Mesaj formatı production ile aynı template üzerinden test edilebilir. Gönderim endpoint'i environment bazında değişir.

OAuth Providers

OAuth provider için ayrı application registration kullanmak güvenlidir. Callback URL ortam domain'ine göre tanımlanır. Scope yapısı production'a benzer tutulmalıdır. Client secret environment-specific olmalıdır. Redirect ve SameSite davranışı staging üzerinde test edilmelidir.

Webhooks

Webhook endpoint'leri environment bazında ayrılmalıdır. Staging sandbox event'lerini almalıdır. Signature verification aynı code ile çalışmalıdır. Retry ve ordering senaryoları test edilmelidir. Production event'lerinin staging'e yönlenmesi engellenmelidir.

Rate Limits

Sandbox rate limit production'dan daha düşük olabilir. Bu fark load test sonuçlarını etkiler. Client retry ve backoff davranışı ayrı test edilebilir. Rate limit değerleri observability içinde izlenmelidir. Production limit varsayımları dokümante edilmelidir.

Third-Party Mocking

Mock servis external dependency'yi kontrollü biçimde simüle eder. Error, timeout ve sıra dışı response senaryoları kolayca test edilir. Contract güncelliği düzenli doğrulanmalıdır. Mock production davranışından kopmamalıdır. Integration testlerin bir kısmı gerçek sandbox üzerinde de çalıştırılmalıdır.

Network Parity Nasıl Sağlanır?

Network parity uygulamanın staging ve production ortamlarında benzer bağlantı, TLS, DNS ve güvenlik davranışıyla çalışmasını sağlar. VPC veya VNet kapasitesi aynı olmak zorunda değildir, ancak subnet modeli, ingress akışı, firewall kuralları ve egress sınırları mümkün olduğunca aynı şablondan üretilmelidir. Load balancer veya reverse proxy farkı özellikle header, timeout ve redirect davranışlarını değiştirebilir. TLS termination ve DNS çözümleme de gerçek production sorunlarının yaygın kaynaklarıdır. Network infrastructure'ın IaC ile tanımlanması bu farkları görünür ve test edilebilir hale getirir.

VPC/VNet Topolojisi

Staging ve production aynı temel network topolojisini kullanabilir. CIDR blokları doğal olarak farklıdır. Public ve private subnet ayrımı korunmalıdır. Route mantığı aynı template'ten üretilebilir. Environment'lar doğrudan birbirine erişmemelidir.

Security Groups / Firewall

Firewall policy uygulamanın ihtiyaç duyduğu portları sınırlamalıdır. Staging'de her portu açmak production hatalarını gizler. Ortak security rule module kullanılabilir. Resource id'ler environment bazında değişir. Beklenmeyen public erişim policy ile engellenebilir.

Route Tables

Route table farkı external servis erişimini değiştirebilir. Staging NAT kullanırken production farklı egress yolu kullanabilir. Gereksiz farklar azaltılmalıdır. Route configuration IaC ile versionlanabilir. Drift detection bu alanı da kapsamalıdır.

Load Balancer

Load balancer timeout, header ve health check davranışını etkiler. Staging doğrudan uygulamaya trafik gönderirse production problemi görünmeyebilir. Benzer load balancer yapılandırması tercih edilmelidir. Capacity daha düşük olabilir. TLS termination davranışı aynı tutulmalıdır.

Reverse Proxy

Reverse proxy host header ve forwarding davranışını değiştirir. Uygulama gerçek client IP bilgisini farklı görebilir. Staging üzerinde aynı proxy layer kullanılmalıdır. Header güven politikası test edilmelidir. Timeout ve body size limitleri de eşleşmelidir.

TLS

TLS yalnızca production özelliği olmamalıdır. Staging HTTPS üzerinden çalışmalıdır. Certificate issuer farklı olabilir. Uygulamanın secure cookie ve redirect davranışı böylece test edilir. Eski protocol ve cipher policy'leri ayrıca kontrol edilebilir.

DNS

DNS environment domain'lerini servislerle eşler. Staging ve production ayrı zone veya subdomain kullanabilir. TTL değerleri farklı olabilir. Uygulama hostname'e bağlı gizli davranış içermemelidir. DNS failover senaryoları kritik sistemlerde test edilebilir.

Egress Rules

Egress kontrolü hangi external servislere çıkılabileceğini sınırlar. Staging tamamen açık, production kısıtlıysa entegrasyon hatası canlıda ortaya çıkabilir. Required destination listesi ortak policy'den üretilebilir. IP yerine service identity tercih edilebilir. Beklenmeyen outbound trafik izlenmelidir.

TLS ve DNS Farkları Production Hatalarına Nasıl Yol Açar?

TLS ve DNS farklılıkları çoğu zaman kod doğru olduğu halde yalnızca production'da görülen hatalara yol açar. Staging HTTP kullanırken production HTTPS kullanıyorsa secure cookie, redirect ve mixed-content davranışları test edilmemiş olur. Domain farklılıkları SameSite, CORS ve OAuth callback davranışlarını etkileyebilir. Certificate validation test ortamında devre dışı bırakılmışsa production certificate chain sorunları geç fark edilir. Bu nedenle staging ortamının gerçek domain yapısını kopyalaması gerekmez, fakat aynı protokol ve güvenlik davranışını temsil etmesi önemlidir.

Certificate Validation

Certificate validation non-prod ortamda kapatılmamalıdır. Self-signed sertifika kullanılacaksa trust chain doğru kurulmalıdır. Expiration ve hostname kontrolü çalışmalıdır. Third-party TLS bağlantıları da doğrulanmalıdır. Production policy mümkün olduğunca staging'de test edilmelidir.

HTTPS Redirect

HTTP'den HTTPS'e redirect davranışı uygulama veya load balancer seviyesinde olabilir. Staging aynı akışı kullanmalıdır. Infinite redirect hataları ancak bu şekilde görülür. Proxy header ayarları doğru olmalıdır. Health check endpoint'i ayrı davranabilir.

Cookie Secure Flag

Secure flag bulunan cookie yalnızca HTTPS üzerinden gönderilir. Staging HTTP çalışırsa authentication davranışı farklılaşır. Bu nedenle HTTPS kullanımı önemlidir. Cookie domain'i environment'a göre ayarlanabilir. Security flag'leri production'dan gevşetilmemelidir.

SameSite

SameSite policy cross-site authentication ve embedded kullanım senaryolarını etkiler. Domain yapısı değiştiğinde sonuç farklı olabilir. OAuth flow staging üzerinde gerçek HTTPS domain ile test edilmelidir. Browser davranışı dikkate alınmalıdır. Policy application code içinde açıkça tanımlanmalıdır.

CORS

CORS allowed origin listesi environment bazında farklı değer taşır. Ancak policy mantığı aynı olmalıdır. Wildcard staging kullanmak production hatalarını gizleyebilir. Frontend ve API domain kombinasyonu test edilmelidir. Preflight request'leri automated test içine alınabilir.

Domain-Specific Behaviour

Application domain adına göre bilinçsiz business logic çalıştırmamalıdır. Environment detection için hostname kullanmak kırılgan bir yöntemdir. Açık config tercih edilmelidir. Domain yalnızca routing veya cookie gibi gerekli alanlarda kullanılmalıdır. Preview environment'lar bu hatayı hızla görünür hale getirir.

Feature Flag'ler Ortamlar Arasında Nasıl Yönetilir?

Feature flag yönetimi deployment ile release kavramlarını birbirinden ayırmaya yardımcı olur. Kod production'a deploy edilmiş olabilir, fakat özellik flag kapalı olduğu için kullanıcıya açılmayabilir. Development, staging ve production flag değerlerinin farklı olması normaldir, ancak farkların bilinçli ve izlenebilir olması gerekir. Flag promotion ve approval workflow kullanıldığında hangi özelliğin hangi environment'ta aktif olduğu görülebilir. Kill switch incident sırasında hızlı kapatma sağlarken stale flag cleanup yapılmaması zamanla application logic'i gereksiz biçimde zorlaştırır.

Deploy ile Release Arasındaki Fark

Deploy kodun environment'a taşınmasıdır. Release özelliğin kullanıcıya açılmasıdır. Feature flag bu iki adımı ayırabilir. Aynı artifact tüm ortamlarda bulunabilir. Kullanıcı görünürlüğü kontrollü olarak değiştirilebilir.

Development Flag Configuration

Development yeni feature'ları erken test etmek için flag'i açık kullanabilir. Geliştirici kişisel override yapabilir. Default değer merkezi tanımdan gelmelidir. Test kombinasyonları otomatikleştirilebilir. Flag dependency'leri belgelenmelidir.

Staging Flag Configuration

Staging UAT için production'a yakın flag seti taşımalıdır. Yeni özellik test süresince açık olabilir. Production'a geçmeden önce beklenen final durum kaydedilmelidir. Flag drift check yapılabilir. Approval sonucu promotion kaydına eklenebilir.

Production Flag Configuration

Production flag değişikliği kontrollü release mekanizmasıdır. Yetkili roller sınırlandırılmalıdır. Değişiklik audit edilmelidir. Metric ve error rate flag ile ilişkilendirilebilir. Sorun halinde hızlı rollback yerine flag kapatma kullanılabilir.

Flag Promotion

Flag promotion staging'de doğrulanan configuration'ın production'a kontrollü taşınmasıdır. Tam kopyalama her zaman doğru değildir. Hangi değerlerin taşınacağı açık olmalıdır. Promotion pull request veya approval ile yapılabilir. Değişiklik geçmişi korunmalıdır.

Approval Workflow

Kritik feature flag değişiklikleri approval gerektirebilir. Product ve engineering owner birlikte karar verebilir. Yüksek riskli flag için change window uygulanabilir. Küçük flag'ler otomatik yayınlanabilir. Süreç risk seviyesine göre ayarlanmalıdır.

Kill Switch

Kill switch problemli feature'ı hızlı kapatmayı sağlar. Uygulama restart gerektirmemesi avantajdır. Flag sistemi unavailable olduğunda default davranış belirlenmelidir. Kritik path için fail-safe tercih edilmelidir. Kill switch düzenli test edilmelidir.

Stale Feature Flag Cleanup

Kalıcı hale gelen flag code'dan kaldırılmalıdır. Eski branch'ler logic karmaşasını artırır. Owner ve expiration date tutulabilir. Düzenli stale flag raporu oluşturulabilir. Cleanup normal engineering backlog'un parçası olmalıdır.

Background Job ve Queue Parity

Background job ve queue sistemleri ortam parity çalışmalarında sıkça gözden kaçar. Web uygulaması staging'de doğru çalışırken gerekli worker deploy edilmemişse asenkron işlemler sessizce tamamlanmayabilir. Worker sayısı kapasite nedeniyle farklı olabilir, ancak queue isimleri, retry policy, timeout ve dead-letter davranışı aynı standardı izlemelidir. Cron job'ların bazıları non-prod ortamda gerçek dış sistemleri tetiklememek için kapalı tutulabilir, fakat bu fark bilinçli biçimde belgelenmelidir. Queue health ve worker version bilgileri observability sistemine dahil edilmelidir.

Worker Sayısı

Production daha fazla worker çalıştırabilir. Staging daha düşük concurrency kullanabilir. Worker image version ana application artifact ile uyumlu olmalıdır. Concurrency-sensitive bug testleri ayrıca yapılmalıdır. Worker count environment parametresi olabilir.

Queue İsimleri

Queue isimleri environment namespace'i içermelidir. Production ve staging aynı fiziksel queue'yu paylaşmamalıdır. Logical naming pattern aynı kalabilir. Yanlış environment mesaj tüketimi engellenmelidir. IAM policy queue scope'u sınırlandırmalıdır.

Retry Policy

Retry policy environment'lar arasında benzer olmalıdır. Staging'de retry kapalıysa production davranışı görülmez. External sandbox limitleri nedeniyle süre farklılaştırılabilir. Backoff algoritması aynı kalmalıdır. Retry metric'leri izlenmelidir.

Dead-Letter Queue

Dead-letter queue başarısız mesajları izole eder. Staging ve production ayrı DLQ kullanmalıdır. Retention farklı olabilir. Re-drive işlemi test edilmelidir. Alert eşikleri environment kapasitesine göre ayarlanabilir.

Timeout

Timeout değerleri uygulama davranışını ciddi biçimde etkiler. Staging'de çok yüksek timeout production hatasını gizleyebilir. Ortak default kullanılmalıdır. External servis farkı gerekiyorsa exception belgelenebilir. Timeout metric ve trace verisinde görünmelidir.

Scheduled Tasks / Cron Jobs

Cron job'lar environment'a göre dikkatle yönetilmelidir. Gerçek faturalama veya mesaj gönderimi staging'de çalışmamalıdır. Ancak job code'unun test edilmesi gerekir. Safe mode veya sandbox dependency kullanılabilir. Schedule farklılığı config olarak açıkça belirtilmelidir.

Production'da Çalışıp Staging'de Unutulan Worker Riski

Yalnızca production'da çalışan worker staging testlerini eksik bırakır. Deployment manifest parity kontrolü worker deployment'larını karşılaştırabilir. Test amaçlı düşük replica ile staging'de çalıştırmak daha sağlıklıdır. External side effect gerekiyorsa mock servis kullanılabilir. Worker inventory environment contract'a eklenmelidir.

Runtime ve Dependency Version Parity

Runtime ve dependency version parity aynı application code'un farklı ortamlarda aynı teknik koşullarla çalışmasını sağlar. Programming language, framework, OS base image, database, Redis veya message broker major sürümlerinin ayrışması beklenmedik davranışlar doğurabilir. Lockfile application dependency setini sabitlerken container image system dependency'lerini kontrol altında tutar. Floating version kullanımı build tekrar üretilebilirliğini zayıflatır. Sürüm yükseltmeleri önce development ve staging zincirinde doğrulanmalı, daha sonra aynı artifact ve uyumlu infrastructure güncellemesiyle production'a taşınmalıdır.

Programming Language Version

Dil runtime sürümü açıkça pinlenmelidir. Lokal development aynı major ve minor sürümü kullanmalıdır. Runtime image tag'i floating olmamalıdır. Upgrade compatibility testleri çalıştırılmalıdır. Version bilgisi health endpoint'te gösterilebilir.

Framework Version

Framework dependency lockfile içinde sabitlenmelidir. Minor upgrade bile davranış değiştirebilir. Otomatik dependency botları pull request oluşturabilir. Testler başarılı olmadan upgrade merge edilmemelidir. Production artifact yalnızca doğrulanmış dependency setini taşımalıdır.

OS / Base Image

Base image libc, certificate ve system library davranışını etkiler. Development host farklı olsa bile container aynı base image kullanabilir. Base image security patch düzenli yapılmalıdır. Digest veya sabit tag tercih edilmelidir. Architecture farkları ayrıca test edilmelidir.

Database Version

Database major version parity kritik öneme sahiptir. Query planner veya SQL syntax değişebilir. Staging production upgrade öncesi doğrulama alanı olmalıdır. Extension sürümleri de kontrol edilmelidir. Managed database otomatik upgrade ayarları izlenmelidir.

Redis / Message Broker Version

Cache ve broker sürümleri uygulama protokolünü etkileyebilir. Staging eski sürüm kullanırsa upgrade riski görünmez. Container veya managed service version pinlenebilir. Client library compatibility test edilmelidir. Cluster mode farkları ayrıca değerlendirilmelidir.

Dependency Lockfile

Lockfile repository'nin zorunlu parçası olmalıdır. CI clean install kullanmalıdır. Lockfile ile manifest uyumsuzluğu build'i durdurabilir. Merge conflict sonrası dosya yeniden doğrulanmalıdır. Dependency update geçmişi review edilebilir.

Floating Version'lardan Kaçınma

latest veya geniş semver aralığı beklenmedik upgrade getirebilir. Production build'in içeriği zamanla değişmemelidir. Version pinning repeatable build sağlar. Güncellemeler planlı yapılabilir. Otomasyon sürüm yeniliğini yine takip edebilir.

Timezone, Locale ve Encoding Ortam Farkları

Timezone, locale ve encoding farklılıkları özellikle tarih, para, dosya adı ve metin işleme kodlarında şaşırtıcı environment bug'larına yol açabilir. Backend sistemlerde UTC kullanmak zaman hesaplarını sadeleştirir, kullanıcıya gösterim ise açık locale bilgisiyle yapılabilir. Decimal ve currency formatları sistem locale'ine bırakılmamalıdır. UTF-8 standardı uygulama, database ve messaging katmanlarında ortak tutulmalıdır. Case-sensitive filesystem farkları da macOS veya Windows üzerinde görünmeyen ama Linux production ortamında çıkan import hatalarının önemli nedenlerinden biridir.

UTC Kullanımı

Backend timestamp değerlerini UTC tutmak güvenli bir varsayımdır. Kullanıcı timezone'u presentation katmanında uygulanabilir. Cron job schedule açık timezone ile tanımlanmalıdır. Database session timezone kontrol edilmelidir. Daylight saving testleri ayrıca yapılmalıdır.

Locale-Sensitive Date Formatting

Date formatting sistem locale'ine bağlı bırakılmamalıdır. Aynı tarih farklı ortamda farklı string üretebilir. API ISO format kullanabilir. UI kullanıcı locale'ine göre gösterim yapabilir. Testler explicit locale ile çalıştırılmalıdır.

Decimal ve Currency

Ondalık ayırıcı locale'e göre değişebilir. Finansal hesaplar string formatına bağlı yapılmamalıdır. Decimal type tercih edilmelidir. Currency code açık şekilde taşınmalıdır. Testler farklı locale kombinasyonlarını kapsamalıdır.

UTF-8

UTF-8 uygulama katmanlarında ortak encoding standardı olmalıdır. Database collation ayrıca kontrol edilmelidir. Queue message encoding açık olmalıdır. Dosya import işlemleri encoding hatasına karşı doğrulanmalıdır. Türkçe karakter testleri özellikle değerlidir.

Case-Sensitive Filesystem

Bazı development filesystem'leri büyük ve küçük harfi aynı kabul edebilir. Linux production ortamında bu davranış farklı olabilir. Yanlış import path yalnızca production'da hata verebilir. Container ile lokal test bu riski azaltır. CI Linux runner üzerinde build çalıştırmalıdır.

Environment-Specific Bug Örnekleri

Yanlış timezone günlük raporun bir saat kaymasına neden olabilir. Locale farkı decimal parsing hatası oluşturabilir. Case-sensitive dosya adı deployment sonrasında module not found hatasına dönüşebilir. TLS domain farkı cookie'nin gönderilmesini engelleyebilir. Parity testlerinin amacı tam olarak bu sınıf sorunları erken yakalamaktır.

Kubernetes Ortamlarında Senkronizasyon

Kubernetes environment parity için güçlü imkanlar sunar, ancak çok sayıda override kullanıldığında ortamlar hızla birbirinden uzaklaşabilir. Cluster version, Helm chart, CRD, network policy, resource request ve admission policy gibi alanlar düzenli karşılaştırılmalıdır. Base values ortak yapılandırmayı taşırken environment overrides yalnızca kapasite veya domain gibi gerekli farkları içermelidir. Kubernetes manifestleri version control içinde tutulmalı ve image digest üzerinden immutable artifact kullanılmalıdır. Development için lokal Kubernetes şart değildir, ancak staging ve production aynı deployment modelini mümkün olduğunca paylaşmalıdır.

Kubernetes Version Parity

Cluster version farkı API davranışını değiştirebilir. Staging production upgrade öncesi yeni version üzerinde test edilebilir. Uzun süre kalıcı version farkı bırakılmamalıdır. Deprecated API taraması CI içinde yapılabilir. Upgrade sırası planlı olmalıdır.

Helm Charts

Helm chart ortak deployment template'i sağlayabilir. Chart version tüm environment'larda izlenmelidir. Environment farkları values dosyalarında tutulabilir. Chart içinde environment adına göre aşırı conditional kullanımından kaçınılmalıdır. Render edilmiş manifest CI'da doğrulanabilir.

Base Values

Base values ortak config'i içerir. Image repository, port ve probe gibi alanlar burada bulunabilir. Ortam dosyaları yalnızca override yapar. Bu yaklaşım farkları açık hale getirir. Base değişiklik tüm environment'lar için test edilmelidir.

Environment Overrides

Override dosyaları küçük tutulmalıdır. Replica, domain veya resource limit gibi alanlar değişebilir. Aynı key'in farklı anlamda kullanılması önlenmelidir. Diff tool ile environment values karşılaştırılabilir. Beklenmeyen fark parity ihlali olarak işaretlenebilir.

CRD Version'ları

CRD version farkı controller davranışını değiştirebilir. Staging ve production aynı operator major sürümünü kullanmalıdır. Upgrade compatibility kontrol edilmelidir. Manifest schema validation CI içinde çalışabilir. Deprecated CRD version'ları zamanında temizlenmelidir.

Network Policies

Network policy staging'de production'a yakın olmalıdır. Tamamen açık namespace gerçek permission sorunlarını gizler. Environment selector farklı olabilir. Policy template ortak tutulabilir. Connection testleri deployment sonrasında çalıştırılabilir.

Resource Requests ve Limits

Resource değerleri kapasiteye göre değişebilir. Ancak request ve limit mekanizmasının kendisi tüm ortamlarda kullanılmalıdır. Staging limitsiz, production limitli olmamalıdır. OOM ve throttling davranışı staging'de görülebilir. Değerler gözlemlenebilirlik verisiyle ayarlanmalıdır.

Admission Policies

Admission policy production güvenlik standardını enforce eder. Staging aynı policy setiyle test alanı olabilir. Privileged container veya latest tag gibi hatalar erken engellenir. Development cluster daha esnek olabilir. Production promotion öncesi aynı policy CI'da da çalıştırılabilir.

GitOps ile Dev, Staging ve Production Yönetimi

GitOps yaklaşımı Kubernetes ve benzeri platformlarda desired state'in Git repository üzerinden yönetilmesini sağlar. Controller repository'deki tanım ile cluster'ın gerçek durumunu karşılaştırır ve gerekirse reconciliation uygular. Bu model manuel production değişikliklerini görünür hale getirir ve environment drift'i sürekli kontrol eder. Argo CD veya Flux gibi araçlarla environment repository yapısı, pull request tabanlı promotion ve audit geçmişi oluşturulabilir. GitOps kullanmak tek başına iyi environment tasarımı sağlamaz, ancak source of truth prensibini uygulamak için güçlü bir operasyon modeli sunar.

GitOps Nedir?

GitOps desired state'in Git üzerinden yönetilmesidir. Deployment değişikliği repository commit'i ile başlar. Controller cluster durumunu izler. Fark oluştuğunda reconciliation yapabilir. Git geçmişi doğal audit kaydı sağlar.

Desired State

Desired state uygulamanın ve infrastructure'ın beklenen halidir. Manifest, chart veya config ile tanımlanabilir. Gerçek cluster bu tanımla karşılaştırılır. Manuel değişiklik drift olarak görülür. İstisnalar bilinçli yönetilmelidir.

Reconciliation

Reconciliation actual state'i desired state'e yaklaştırır. Controller belirli aralıklarla kontrol yapar. Drift otomatik düzeltilebilir. Destructive durumlarda policy sınırlaması uygulanabilir. Sonuç observability sistemine gönderilmelidir.

Argo CD

Argo CD GitOps deployment modeli için kullanılabilir. Application tanımları environment repository'den okunabilir. Sync durumu drift görünürlüğü sağlar. Manual veya automatic sync tercih edilebilir. Production approval organizasyon politikasına göre eklenebilir.

Flux

Flux da Git tabanlı reconciliation yaklaşımı sunar. Image automation ve manifest update akışları oluşturulabilir. Environment repository yapısı kontrollü tutulmalıdır. Secret yönetiminde encrypted source kullanılabilir. Policy ve audit yaklaşımı ayrıca tasarlanmalıdır.

Environment Repository Yapısı

Repository yapısı environment farklarını kolay karşılaştırılabilir hale getirmelidir. Base ve overlay modeli kullanılabilir. Production dosyalarının kopyası staging olarak tutulmamalıdır. Ortak module tercih edilmelidir. Ownership ve review kuralları klasör bazında uygulanabilir.

Pull Request ile Infrastructure Promotion

Promotion Git değişikliği olarak yapılabilir. Staging'de doğrulanan artifact digest production manifestine pull request ile taşınır. Review sırasında diff açıkça görülür. Approval sonrası controller deployment yapar. Bu model değişiklik kaydını otomatik olarak korur.

CI/CD Pipeline'da Environment Promotion

CI/CD pipeline environment promotion modelinde değişiklikler belirli kalite adımlarından geçerek production'a ilerler. Feature branch veya pull request aşamasında unit test ve lint çalışır, ardından development veya preview deployment yapılabilir. Staging promotion sonrasında integration test, end-to-end test ve UAT uygulanır. Production approval yalnızca gerekli gate'ler başarılı olduğunda açılmalıdır. Kurumsal dev staging production ortam kurulumu ve DevOps otomasyon hizmeti tasarlarken pipeline'ın yeniden build yerine aynı artifact promotion mantığını kullanması hem güvenilirliği hem audit kabiliyetini artırır.

Feature Branch / Pull Request

Değişiklik pull request ile review sürecine girer. Unit test ve static check otomatik çalışabilir. Preview environment oluşturulabilir. Artifact adayı burada üretilebilir. Merge koşulları policy ile belirlenir.

Development Deployment

Development deployment hızlı geri bildirim sağlar. Shared environment veya ephemeral environment kullanılabilir. Aynı deployment mekanizması tercih edilmelidir. Debug ayarları daha açık olabilir. Production secret ve gerçek veri kullanılmamalıdır.

Automated Tests

Automated tests promotion zincirinin ilk güvenlik kapısıdır. Unit, integration ve contract test seviyeleri birlikte kullanılabilir. Test sonucu artifact ile ilişkilendirilmelidir. Flaky test'ler sürekli göz ardı edilmemelidir. Başarısız test production promotion'ı durdurmalıdır.

Staging Promotion

Staging'e yeni artifact yeniden build edilmeden taşınmalıdır. Migration ve configuration validation çalıştırılabilir. Deployment sonrası smoke test yapılmalıdır. Artifact digest kaydedilmelidir. Staging approval sonucu production adayını belirler.

Integration Tests

Integration test gerçek service boundary'lerini doğrular. Database, queue ve third-party sandbox kullanılabilir. Network ve permission sorunları bu aşamada görülür. Test data kontrol altında tutulmalıdır. Sonuç production gate'e dahil edilebilir.

UAT

UAT business beklentilerinin karşılandığını doğrular. Staging veya ayrı UAT environment kullanılabilir. Test edilen artifact production adayıyla aynı olmalıdır. Feature flag durumu kayıt altına alınmalıdır. Onay sonucu deployment kaydına bağlanabilir.

Production Approval

Production approval risk seviyesine göre manuel veya otomatik olabilir. Kritik sistemlerde iki aşamalı onay tercih edilebilir. Düşük riskli küçük release'ler otomatik geçebilir. Approval artifact ve test sonuçlarına dayanmalıdır. Sadece “hazır görünüyor” yaklaşımı yeterli değildir.

Production Deployment

Production deployment aynı artifact ve aynı mekanizmayla yapılmalıdır. Environment-specific config runtime sırasında uygulanır. Health check ve rollout durumu izlenir. Error rate artarsa rollback veya roll-forward başlatılır. Deployment metadata observability sistemine gönderilmelidir.

Production Promotion Gate'leri

Production promotion gate'leri canlıya çıkacak değişikliğin belirlenmiş kalite, güvenlik ve parity koşullarını karşıladığını doğrular. Unit, integration ve end-to-end testlerin yanında security scan, migration check, environment parity check ve artifact signature verification uygulanabilir. Her ekip tüm gate'leri aynı katılıkta kullanmak zorunda değildir, ancak riskli sistemlerde bu kontrollerin otomatik olması büyük avantaj sağlar. Manual approval özellikle destructive migration veya yüksek etkili release'lerde ek güvenlik katmanı sunar. Change window uygulaması da operasyon ekiplerinin yüksek riskli değişiklikleri uygun zaman aralığında yönetmesine yardımcı olur.

Unit Test

Unit test hızlı geri bildirim sağlayan ilk katmandır. Business logic küçük parçalar halinde doğrulanır. Test sonucu build ile ilişkilendirilir. Başarısız test artifact promotion'ını durdurur. Coverage tek başına kalite ölçüsü olarak kullanılmamalıdır.

Integration Test

Integration test service dependency'lerini birlikte doğrular. Gerçek database veya broker kullanılabilir. Sandbox endpoint'ler tercih edilir. Network ve permission hataları ortaya çıkabilir. Test data izole tutulmalıdır.

End-to-End Test

End-to-end test kullanıcı akışını baştan sona doğrular. Kritik iş senaryolarına odaklanılmalıdır. Aşırı büyük ve yavaş suite deployment süresini uzatabilir. Smoke subset production sonrası da çalıştırılabilir. Test sonucu artifact digest ile bağlanabilir.

Security Scan

Security scan dependency ve container açıklarını kontrol edebilir. Threshold policy tanımlanmalıdır. False positive için exception süreci bulunmalıdır. Scan sonucu build metadata içinde saklanabilir. Eski artifact'ler düzenli yeniden taranabilir.

Database Migration Check

Migration check beklenen schema değişikliklerini analiz eder. Destructive işlem varsa özel approval isteyebilir. Mevcut schema version doğrulanır. Migration staging üzerinde uygulanmış olmalıdır. Süre tahmini ve rollback planı ayrıca değerlendirilebilir.

Environment Parity Check

Parity check staging ve production yapılarını karşılaştırır. Runtime, config schema, artifact ve infrastructure version kontrol edilebilir. Bilinçli farklar registry üzerinden hariç tutulur. Beklenmeyen fark gate'i durdurur. Sonuç release raporuna eklenir.

Artifact Signature Verification

Signature verification yalnızca güvenilir pipeline artifact'lerini kabul eder. İmzasız image production'a çıkamaz. Public key veya trust policy merkezi tutulur. Key rotation planlanmalıdır. Verification sonucu audit edilir.

Manual Approval

Manual approval insan değerlendirmesi gereken release'ler için kullanılabilir. Onay sahibi açıkça tanımlanmalıdır. Approval bilgiye dayanmalıdır. Test ve risk özeti reviewer'a gösterilmelidir. Gereksiz approval adımları süreçte darboğaz oluşturabilir.

Change Window

Change window yüksek riskli release'leri uygun saatlere sınırlar. Destek ekibinin hazır olduğu zaman tercih edilebilir. Düşük riskli sürekli deployment için her zaman gerekli değildir. Risk tabanlı yaklaşım daha etkilidir. Emergency change prosedürü ayrıca bulunmalıdır.

Environment Parity Otomatik Olarak Nasıl Test Edilir?

Environment parity otomatik test edildiğinde ortamların aynı olduğuna dair varsayım yerine ölçülebilir kanıt elde edilir. Pipeline container image digest, runtime version, config schema, migration level, infrastructure plan ve network policy farklarını kontrol edebilir. Secret değerleri karşılaştırılmaz, yalnızca gerekli secret referanslarının bulunup bulunmadığı doğrulanır. Integration test'ler infrastructure parity'nin uygulama davranışına gerçekten yansıdığını gösterir. Kontroller deployment gate veya scheduled job olarak çalıştırıldığında drift'in ne zaman başladığı daha kolay tespit edilir.

Container Image Comparison

Staging ve production image digest'leri karşılaştırılabilir. Promotion öncesi aynı digest beklenebilir. Canary senaryosunda birden fazla digest bilinçli olabilir. Expected artifact listesi deployment kaydından alınır. Tag karşılaştırması tek başına yeterli değildir.

Runtime Version Comparison

Runtime version health endpoint veya image metadata üzerinden okunabilir. Beklenen version parity contract içinde tanımlıdır. Fark oluşursa alert üretilebilir. Development için tolerans policy'si farklı olabilir. Production ve staging daha sıkı eşleştirilebilir.

Config Schema Comparison

Config key listeleri değerler gösterilmeden karşılaştırılabilir. Eksik ve extra anahtar raporlanır. Secret key isimleri de bu kontrole dahil edilebilir. Type schema ayrıca doğrulanabilir. Environment-specific izinli farklar listeden çıkarılır.

Database Migration Version

Migration version database metadata tablosundan okunabilir. Staging production'dan ileride olabilir çünkü release adayı orada test edilir. Production promotion öncesi beklenen seviyeler doğrulanır. İleri veya eksik migration alarm oluşturur. Hash mismatch özellikle kritik kabul edilmelidir.

Infrastructure Diff

IaC rendered output iki environment arasında normalize edilerek karşılaştırılabilir. Parametreye bağlı kapasite farkları filtrelenir. Beklenmeyen resource türü farkı parity ihlalidir. Plan çıktısı scheduled kontrol olarak kullanılabilir. Sonuç dashboard'a gönderilebilir.

Network Policy Diff

Network policy rule set'leri karşılaştırılabilir. IP veya namespace gibi environment değerleri normalize edilebilir. Port ve protocol farkları daha anlamlıdır. Beklenmeyen açık egress alarm oluşturabilir. Test bağlantıları diff kontrolünü tamamlar.

Required Secret Presence

Secret içeriğine dokunmadan varlık kontrolü yapılabilir. Uygulamanın istediği secret listesi schema'dan gelir. Secret manager metadata sorgulanır. Eksik secret deployment'ı durdurur. Permission problemi ayrı hata olarak raporlanır.

Integration Tests

Static parity kontrolü her davranış farkını yakalayamaz. Integration test gerçek runtime akışını doğrular. Database, network ve permission birlikte test edilir. Staging production-like koşullarda çalışmalıdır. Kritik testler deployment gate içinde tutulabilir.

Environment Parity Score Oluşturmak

Environment parity score, çok sayıda teknik kontrolü tek bir görünür metriğe dönüştürmek için kullanılabilir. Infrastructure, configuration, runtime, database, network ve security alanlarına ayrı puanlar verilebilir. Ancak tek toplam skor kritik bir hatayı gizlememelidir; örneğin production database erişim kuralı yanlışsa diğer alanların yüksek puanı deployment'a izin vermemelidir. Bu nedenle minimum threshold yanında blocker kontroller tanımlanmalıdır. Score zaman içindeki trendi göstererek environment drift'in arttığını veya platform çalışmalarının parity seviyesini iyileştirdiğini görmeye yardımcı olur.

Infrastructure Score

Infrastructure score ortak resource ve policy uyumunu ölçebilir. Beklenen module version kontrol edilir. İzinli kapasite farkları hariç tutulur. Manuel resource farkı puanı düşürür. Kritik security drift doğrudan blocker olabilir.

Configuration Score

Configuration score schema eşleşmesini değerlendirebilir. Eksik key yüksek ceza alabilir. Bilinmeyen key düşük veya orta risk sayılabilir. Secret değerleri score'a dahil edilmez. Config version uyumu ayrıca ölçülebilir.

Runtime Score

Runtime score language, framework ve base image version'larını karşılaştırır. Major fark en yüksek risktir. Patch farkı policy'ye göre toleranslı olabilir. Immutable image kullanımı puana katkı sağlayabilir. Artifact digest ayrı kontrol olarak tutulabilir.

Database Score

Database score engine, major version ve migration seviyesini ölçer. Schema drift varsa puan düşer. Production ve staging veri miktarı farklılığı cezalandırılmamalıdır. Backup policy ayrı değerlendirilebilir. Destructive pending migration blocker sayılabilir.

Network Score

Network score ingress, egress, TLS ve policy yapısını karşılaştırır. Environment-specific CIDR normalleştirilir. Açık public port ciddi risk kabul edilir. DNS isimleri farklı olabilir. Network davranış testi score'u tamamlar.

Security Score

Security score secret isolation, IAM ve policy uyumunu ölçebilir. Production credentials'ın non-prod ortamda bulunması doğrudan kritik ihlaldir. MFA ve audit policy ayrıca değerlendirilebilir. Artifact signature kontrolü puana eklenebilir. Security blocker'lar toplam skordan bağımsız çalışmalıdır.

Deployment Öncesi Minimum Threshold

Minimum threshold release kararını standartlaştırır. Örneğin toplam skor yüzde doksanın altındaysa promotion durabilir. Ancak kritik kontrol başarısızsa skor yüksek olsa bile deployment yapılmamalıdır. Threshold ekip deneyimine göre ayarlanabilir. False positive oranı düzenli incelenmelidir.

Bilinçli Ortam Farkları Nasıl Dokümante Edilir?

Bilinçli environment farklarının yazılı ve merkezi biçimde tutulması parity yönetiminin önemli bir parçasıdır. Intentional Differences Registry her farkın nedenini, risk seviyesini, owner bilgisini, approval kaydını ve mümkünse sona erme tarihini içerir. Böylece otomatik parity kontrolleri her farklılığı hata olarak işaretlemek yerine kayıtlı istisnaları tanıyabilir. Periyodik review sırasında artık gerekli olmayan farklar kaldırılır. Bu yaklaşım “staging zaten farklı” gibi belirsiz ifadelerin yerine açık, ölçülebilir ve sahipliği belirli bir işletim modeli getirir.

Intentional Differences Registry

Registry kabul edilen environment farklarının merkezi listesidir. Machine-readable format kullanılırsa CI doğrudan okuyabilir. Her kayıt benzersiz kimlik taşımalıdır. Farkın kapsamı açık olmalıdır. Eski kayıtlar düzenli temizlenmelidir.

Farkın Nedeni

Her farkın gerekçesi yazılmalıdır. “Maliyet” tek başına yeterli açıklama olmayabilir. Hangi kaynağın neden küçültüldüğü belirtilmelidir. Davranışsal etkisi değerlendirilmelidir. Gelecek ekip üyeleri karar bağlamını anlayabilmelidir.

Risk Seviyesi

Fark düşük, orta veya yüksek risk olarak sınıflandırılabilir. Risk seviyesi review sıklığını etkiler. Network ve permission farkları genellikle daha dikkatli ele alınmalıdır. Kapasite farkları çoğu zaman daha düşük risklidir. Sınıflandırma ortak kriterlere dayanmalıdır.

Owner

Her farkın teknik owner'ı bulunmalıdır. Owner farkın hâlâ gerekli olup olmadığını takip eder. Takım bazlı sahiplik personel değişikliklerinde daha dayanıklıdır. Owner bilgisi alarm routing için de kullanılabilir. Sahipsiz kayıt oluşturulmamalıdır.

Approval

Yüksek riskli farklar approval gerektirebilir. Security veya platform ekibi reviewer olabilir. Onay tarihi ve gerekçesi saklanmalıdır. Otomatik gate bu kaydı kontrol edebilir. Approval kalıcı izin anlamına gelmemelidir.

Son Kullanma Tarihi

Geçici farklara son kullanma tarihi verilmelidir. Tarih geldiğinde kontrol otomatik failure üretebilir. Uzatma için yeniden review gerekir. Kalıcı farklar açıkça işaretlenebilir. Expiration unutulmuş workaround'ları azaltır.

Periyodik Review

Registry aylık veya çeyreklik gözden geçirilebilir. Kullanılmayan exception'lar temizlenir. Risk seviyesi yeniden değerlendirilir. Owner bilgisi güncellenir. Review sonucu platform health raporuna eklenebilir.

Staging Production ile Aynı Boyutta Olmalı mı?

Staging'in production ile aynı boyutta olması çoğu proje için gerekli değildir. Production-like kavramı production-sized anlamına gelmez; önemli olan application ve infrastructure davranışının benzer olmasıdır. Küçük staging ortamı maliyeti azaltır, yönetimi kolaylaştırır ve sürekli açık tutulabilir. Buna karşılık load testing, migration benchmark, concurrency veya failover testleri yapılacaksa production'a daha yakın geçici kapasite gerekebilir. Kalıcı olarak büyük staging tutmak yerine ihtiyaca göre ölçeklenen test ortamları birçok ekip için daha ekonomik bir çözümdür.

Production-Like ≠ Production-Sized

Production-like aynı çalışma prensibini ifade eder. Aynı CPU miktarını ifade etmez. Staging aynı container, network ve deployment modelini kullanabilir. Kaynak kapasitesi daha düşük tutulabilir. Test amacına göre geçici büyütme yapılabilir.

Küçük Staging Kullanmanın Avantajları

Küçük staging cloud maliyetini azaltır. Environment sürekli kullanılabilir halde tutulabilir. Drift kontrolü daha sık yapılabilir. Geliştiricilerin hızlı test yapması kolaylaşır. Kapasite sınırları ayrıca dokümante edilmelidir.

Hangi Durumlarda Aynı Kapasite Gerekir?

Bazı testler kapasite davranışına doğrudan bağlıdır. Performans ve failover buna örnektir. Kalıcı staging yerine geçici production-like test ortamı kullanılabilir. Testten sonra kaynaklar silinebilir. Böylece maliyet kontrollü tutulur.

Load Testing

Load testing gerçekçi concurrency ve trafik gerektirir. Production kapasitesine yakın altyapı sonuçları iyileştirir. External servisler mock veya sandbox kullanılabilir. Test izolasyonu önemlidir. Metric ve trace birlikte analiz edilmelidir.

Migration Benchmark

Migration süresi veri hacmi ve hardware kapasitesine bağlıdır. Production benzeri test daha doğru tahmin verir. Büyük tablolar synthetic veriyle doldurulabilir. Lock davranışı izlenmelidir. Sonuç change window planında kullanılabilir.

Concurrency Testing

Concurrency bug'ları tek replica ortamda görünmeyebilir. Birden fazla application ve worker instance çalıştırılmalıdır. Race condition ve distributed lock senaryoları test edilmelidir. Resource sayısı production'a yakın seçilebilir. Sonuçlar tekrar üretilebilir testlere dönüştürülmelidir.

Failover Testing

Failover birden fazla zone veya replica gerektirebilir. Küçük staging bu davranışı temsil etmeyebilir. Geçici HA environment oluşturulabilir. Failure injection kontrollü yapılmalıdır. Recovery metric'leri kaydedilmelidir.

Preview ve Ephemeral Environments

Preview ve ephemeral environment yaklaşımı her pull request veya branch için kısa süreli production-like test alanı oluşturur. Bu ortamlar frontend, API ve gerekli dependency'leri izole biçimde çalıştırarak değişikliğin merge edilmeden önce görülmesini sağlar. Synthetic data kullanılması gerçek müşteri verisi riskini azaltır. TTL ve otomatik cleanup mekanizması olmazsa yüzlerce unutulmuş environment maliyet oluşturabilir. Infrastructure template ve shared managed servislerin dengeli kullanımı, ephemeral environment'ları küçük ve orta ölçekli ekipler için oldukça verimli hale getirir.

Pull Request Başına Geçici Ortam

Her pull request için environment otomatik oluşturulabilir. Review yapan kişi çalışan uygulamayı doğrudan görebilir. Artifact aynı pipeline tarafından üretilir. Merge veya close sonrasında environment kaldırılır. Maliyet etiketi branch ile ilişkilendirilebilir.

Branch Preview

Branch preview özellikle frontend ve API değişikliklerinde hızlı geri bildirim sağlar. Unique domain atanabilir. OAuth callback veya CORS config otomatik üretilebilir. Production secret kullanılmamalıdır. Environment ownership branch sahibiyle eşleştirilebilir.

Production-Like Dependencies

Preview ortamı aynı dependency türlerini kullanmalıdır. Database ve queue daha küçük olabilir. Shared servis kullanılıyorsa data isolation sağlanmalıdır. External API sandbox endpoint'e yönlenmelidir. Network policy template'i production modelini takip edebilir.

Synthetic Data

Synthetic data ephemeral environment için idealdir. Environment kurulurken seed edilebilir. Test senaryoları repeatable olur. Gerçek kullanıcı bilgisi kullanılmaz. Dataset küçük ve hızlı yüklenebilir olmalıdır.

TTL

Her ephemeral environment sona erme süresine sahip olmalıdır. Uzun süre açık kalan ortam otomatik silinebilir. Aktif review varsa TTL uzatılabilir. Resource label expiration bilgisini taşıyabilir. Cleanup job düzenli çalışmalıdır.

Otomatik Cleanup

Pull request kapandığında infrastructure silinmelidir. Cleanup başarısız olursa alarm üretilebilir. Orphan resource taraması ayrıca yapılmalıdır. Database snapshot gibi kalıcı kaynaklar unutulmamalıdır. Maliyet raporu cleanup etkinliğini gösterebilir.

Maliyet Kontrolü

Preview ortamların sayısı hızlı artabilir. Scale-to-zero veya shared dependency modeli kullanılabilir. Resource quota uygulanmalıdır. TTL maliyet kontrolünün önemli parçasıdır. Ortam başına maliyet metriği ekiplerle paylaşılabilir.

Blue-Green ve Canary Deployment Ortam Senkronizasyonunu Nasıl Etkiler?

Blue-green ve canary deployment teknikleri production içinde aynı uygulamanın birden fazla sürümünün kısa süre birlikte çalışmasını gerektirir. Bu nedenle environment parity kavramı yalnızca dev, staging ve production arasında değil aynı production environment içindeki release grupları arasında da önem kazanır. Blue ve green deployment'lar aynı network, config schema ve database ile uyumlu olmalıdır. Canary sürüm sınırlı trafik alırken metric ve error rate karşılaştırması yapılabilir. Ortak database kullanıldığı için schema değişikliklerinin backward-compatible tasarlanması bu yöntemlerde özellikle önemlidir.

Deployment Environment ile Release Environment Farkı

Deployment environment fiziksel veya mantıksal çalışma alanıdır. Release environment belirli kullanıcı grubuna sunulan version olabilir. Feature flag veya traffic routing bu ayrımı oluşturur. Aynı production cluster içinde iki release çalışabilir. Observability version bazında ayrım yapmalıdır.

Blue-Green

Blue-green modelinde iki tam application seti bulunur. Biri aktif trafik alırken diğeri yeni version'ı taşır. Test sonrası trafik yeni sete geçirilir. Database compatibility kritik öneme sahiptir. Eski set belirli süre rollback için tutulabilir.

Canary

Canary yeni version'a trafiğin küçük bölümünü yönlendirir. Error rate ve latency izlenir. Sağlıklıysa trafik oranı artırılır. Aynı config schema kullanılmalıdır. Segment bazlı rollout yapılabilir.

Traffic Shifting

Traffic shifting load balancer veya service mesh üzerinden yapılabilir. Yüzde bazlı dağıtım kontrollü rollout sağlar. Session affinity davranışı dikkate alınmalıdır. Metric version label içermelidir. Sorun halinde trafik hızla eski version'a döndürülebilir.

Feature Flag

Feature flag canary ile birlikte kullanılabilir. Kod deploy edilirken özellik sınırlı kullanıcıya açılabilir. Deployment ve business release ayrı kontrol edilir. Flag configuration version bazında gözlenmelidir. Eski flag cleanup unutulmamalıdır.

Ortak Database Uyumluluğu

İki application version aynı database ile çalışabilir olmalıdır. Destructive migration hemen yapılmamalıdır. Expand–migrate–contract yaklaşımı uygundur. Backward-compatible schema change tercih edilmelidir. Contract aşaması rollout tamamen bittikten sonra yapılmalıdır.

Rollback ve Roll-Forward Stratejisi

Rollback stratejisi yalnızca önceki container image'a dönmekten ibaret değildir. Config değişikliği, feature flag durumu ve database migration uyumluluğu da geri dönüş kararını etkiler. Immutable artifact sayesinde previous version hızlıca yeniden deploy edilebilir. Database değişikliği irreversible ise roll-forward çoğu zaman rollback'ten daha güvenli olabilir. Her release için hangi bileşenlerin geri alınabilir olduğu önceden bilinmeli ve incident sırasında karar vermeyi kolaylaştıracak runbook hazırlanmalıdır.

Previous Artifact'e Rollback

Önceki artifact registry'de immutable olarak tutulmalıdır. Digest deployment history içinde bulunur. Rollback aynı pipeline mekanizmasıyla yapılmalıdır. Config compatibility kontrol edilmelidir. Database schema eski version ile uyumlu olmalıdır.

Config Rollback

Config değişikliği application rollback olmadan da sorun çıkarabilir. Config versioning önceki duruma dönmeyi kolaylaştırır. Secret rotation gibi değişiklikler ayrı değerlendirilmelidir. Rollback audit edilmelidir. Dynamic config için hızlı geri dönüş mekanizması bulunmalıdır.

Feature Flag Kill Switch

Problem yalnızca yeni feature'daysa kill switch en hızlı çözüm olabilir. Artifact rollback gerekmez. Flag kapatıldığında metric değişimi izlenmelidir. Default davranış test edilmiş olmalıdır. Incident sonrasında root cause düzeltilmelidir.

Database Migration Problemi

Database migration rollback'in en zor kısmıdır. Data kaybı varsa eski artifact'e dönmek yeterli olmayabilir. Backward compatibility bu yüzden önemlidir. Irreversible migration ayrı approval gerektirmelidir. Forward fix planı önceden düşünülmelidir.

Forward-Compatible Değişiklik

Forward-compatible değişiklik sonraki application version'ların güvenle çalışmasını sağlar. Yeni alan eklemek bunun örneğidir. Eski code yeni alanı görmezden gelebilir. Deployment sırası esnekleşir. Rolling release daha güvenli olur.

Roll-Forward Ne Zaman Daha Güvenlidir?

Database değişikliği geri alınamıyorsa roll-forward daha doğru olabilir. Küçük code fix hızlı hazırlanabiliyorsa veri restore etmekten daha az risklidir. Incident severity ve recovery time birlikte değerlendirilmelidir. Runbook olası senaryoları tanımlamalıdır. Karar observability verisine dayanmalıdır.

Observability Ortamlar Arasında Nasıl Senkronize Edilir?

Observability yapısı staging ve production arasında benzer değilse production sorunlarını non-prod ortamda araştırmak zorlaşır. Log formatı, metric isimleri, trace propagation, health check ve readiness probe davranışı ortak tutulmalıdır. Environment tagging verinin birbirine karışmasını engeller ve aynı dashboard'un farklı environment'lar için kullanılmasını sağlar. Synthetic monitoring staging üzerinde deployment sonrası smoke test görevi görebilir. Production'daki alarm eşikleri daha katı olabilir, ancak ölçülen sinyaller mümkün olduğunca aynı standardı izlemelidir.

Aynı Log Formatı

Tüm environment'lar aynı structured log formatını kullanmalıdır. Field isimleri değişmemelidir. Environment ve version label eklenmelidir. Secret veya PII loglanmamalıdır. Aynı query production ve staging üzerinde çalışabilmelidir.

Aynı Metric İsimleri

Metric isimleri application version'a göre değişmemelidir. Environment label ayrım sağlar. Dashboard template tekrar kullanılabilir. SLO metric'leri staging üzerinde de görülebilir. Cardinality kontrollü tutulmalıdır.

Distributed Tracing

Trace propagation tüm servislerde aynı standardı izlemelidir. Staging entegrasyon hatalarını görmeyi kolaylaştırır. Sample rate production'da farklı olabilir. Trace environment ve version tag'i taşımalıdır. Sensitive attribute filtrelenmelidir.

Health Check

Health endpoint temel process durumunu göstermelidir. Çok ağır dependency kontrolü liveness içine eklenmemelidir. Endpoint contract tüm environment'larda aynı olmalıdır. Monitoring düzenli çağırabilir. Build version bilgisi güvenli biçimde eklenebilir.

Readiness Probe

Readiness servis trafiğe hazır mı sorusunu yanıtlar. Database veya migration uyumu burada değerlendirilebilir. Staging ve production aynı probe mantığını kullanmalıdır. Timeout değerleri dikkatle ayarlanmalıdır. Yanlış probe deployment loop'una neden olabilir.

Synthetic Monitoring

Synthetic monitoring gerçek kullanıcı akışına benzeyen testler çalıştırır. Staging deployment sonrası smoke test için uygundur. Production'da düşük etkili sentetik transaction kullanılabilir. Test hesabı gerçek müşteriden ayrı tutulmalıdır. Sonuç release version ile ilişkilendirilebilir.

Environment Tagging

Her log, metric ve trace environment label taşımalıdır. Version ve region bilgisi de eklenebilir. Dashboard filtreleri kolaylaşır. Cross-environment karşılaştırma yapılabilir. Yanlış production verisinin staging dashboard'unda görünmesi önlenir.

Staging Production Incident'larını Yeniden Üretebilmeli mi?

İyi bir staging ortamı production incident'larının önemli bölümünü güvenli şekilde yeniden üretebilmelidir, ancak gerçek production verisini veya secret'larını kopyalamak zorunda değildir. Production config snapshot'ının secret içermeyen kısmı, artifact digest'i ve sanitized request bilgisi incident reproduction ortamına taşınabilir. Gerekirse kısa süreli özel bir environment oluşturularak hata izole biçimde incelenebilir. Privacy ve güvenlik sınırları her zaman korunmalıdır. Reproducibility yalnızca debugging hızını artırmaz, aynı hatanın regression test olarak sisteme eklenmesini de kolaylaştırır.

Reproducibility

Incident koşulları mümkün olduğunca tekrar üretilebilir olmalıdır. Artifact version bilinmelidir. Config ve feature flag state kaydedilmelidir. Request context sanitize edilerek saklanabilir. Sonuç regression test'e dönüştürülebilir.

Production Config Snapshot

Config snapshot secret içermeyen değerleri kaydedebilir. Version ve timestamp bilgisi tutulmalıdır. Dynamic config de snapshot içine dahil edilebilir. Incident sırasında staging'e güvenli biçimde uygulanabilir. PII veya credential filtrelenmelidir.

Sanitized Request Replay

Request replay hata senaryosunu hızlı yeniden üretir. Payload içindeki kişisel veriler temizlenmelidir. Authentication token gerçek değer olmamalıdır. Synthetic identity kullanılabilir. Side effect oluşturan endpoint'ler sandbox'a yönlendirilmelidir.

Incident Reproduction Environment

Kritik incident için geçici environment oluşturulabilir. Production artifact ve sanitized config kullanılabilir. Gerekli dataset minimal tutulmalıdır. Investigation bittikten sonra environment silinmelidir. Erişim yalnızca incident ekibiyle sınırlandırılmalıdır.

Privacy ve Güvenlik Sınırları

Debugging ihtiyacı veri güvenliği kurallarını ortadan kaldırmaz. Production secret kopyalanmamalıdır. Kişisel veri masking uygulanmadan taşınmamalıdır. Investigation log'ları kontrollü tutulmalıdır. Environment cleanup tamamlandığında geçici veriler de silinmelidir.

Ortam Güvenliği Nasıl Farklılaşmalı?

Development, staging ve production ortamlarının güvenlik seviyesi aynı olmak zorunda değildir, ancak production modelinden tamamen kopuk bir staging ortamı da doğru değildir. Development erişimi geliştiriciler için daha açık olabilirken production erişimi least privilege, MFA, just-in-time access ve güçlü audit logging ile sınırlandırılmalıdır. Staging production permission modelini mümkün olduğunca temsil etmelidir. Ortam kimlikleri, credentials ve network sınırları kesin biçimde ayrı tutulmalıdır. Güvenlikte parity, aynı secret'ları paylaşmak değil aynı güvenlik prensiplerini farklı risk seviyelerine uygun biçimde uygulamak anlamına gelir.

Dev Access

Developer environment erişimi ekip üyeleri için hızlı olmalıdır. Ancak production kaynaklarına transit erişim sağlamamalıdır. Shared dev ortamında role-based access kullanılabilir. Secret scope minimum tutulmalıdır. Hassas test verisi kullanılmamalıdır.

Staging Access

Staging access development'tan daha kontrollü olabilir. QA ve engineering ekipleri yetkili rol ile erişir. Production'a benzer permission modeli test edilir. Gerçek müşteri verisi bulunmamalıdır. Admin erişimi audit edilebilir.

Production Access

Production access minimum kişiyle sınırlandırılmalıdır. İnsan erişimi gerektiğinde JIT tercih edilebilir. MFA zorunlu tutulabilir. Service access workload identity üzerinden yapılabilir. Tüm yönetim işlemleri loglanmalıdır.

Least Privilege

Her kullanıcı ve workload yalnızca gerekli yetkiyi almalıdır. Geniş admin rolü varsayılan olmamalıdır. Permission review düzenli yapılmalıdır. Kullanılmayan yetki kaldırılmalıdır. Access request süreci açık olmalıdır.

MFA

MFA production yönetim erişiminde önemli güvenlik katmanıdır. Özellikle cloud console ve secret manager için uygulanmalıdır. Break-glass account da kontrollü MFA sürecine sahip olmalıdır. Recovery prosedürü güvenli tutulmalıdır. MFA logları access audit ile ilişkilendirilebilir.

Just-in-Time Access

Just-in-time access kalıcı yüksek yetki yerine geçici yetki verir. Kullanıcı ihtiyaç olduğunda erişim talep eder. Yetki süre sonunda otomatik kapanır. Approval ve reason kaydedilebilir. Bu model standing privilege riskini azaltır.

Audit Logging

Audit log production değişikliklerini incelemek için temel veridir. Kimlik, zaman, resource ve action bilgisi bulunmalıdır. Loglar değiştirilemez saklama politikasına alınabilir. Hassas değerler log içine yazılmamalıdır. Alert sistemi kritik işlemleri takip edebilir.

Environment Synchronization ve KVKK

Environment synchronization çalışmaları kişisel verinin production dışına taşınmasını gerektirmez. Tam tersine iyi tasarlanmış environment yönetimi production verisini non-prod ortamlardan uzak tutmayı kolaylaştırır. KVKK açısından data minimization, masking, anonymization, retention ve access control kararları test ortamlarında da dikkate alınmalıdır. Backup ve snapshot dosyaları ana database kadar hassas olabilir ve unutulan kopyalar ciddi risk oluşturabilir. Teknik ekiplerin test ihtiyacı ile kişisel veri işleme gereksinimini birbirinden ayırması güvenli ve sürdürülebilir bir yaklaşım sağlar.

Production Verisinin Non-Prod'a Taşınması

Production verisi non-prod ortama varsayılan olarak taşınmamalıdır. Gerçek ihtiyaç varsa kapsam sınırlanmalıdır. Masking veya anonymization uygulanmalıdır. Taşıma süreci kayıt altına alınmalıdır. İş tamamlandığında veri güvenli biçimde silinmelidir.

Data Minimization

Test için yalnızca gerekli veri alanları kullanılmalıdır. Tüm production snapshot'ını almak kolay ama risklidir. Minimal dataset daha hızlı da çalışır. PII alanları çıkarılabilir. İhtiyaç düzenli olarak yeniden değerlendirilmelidir.

Masking ve Anonymization

Masking test davranışını korurken hassas alanları değiştirir. Anonymization geri döndürülemez kimlik kaldırmayı hedefler. Teknik yöntem veri yapısına göre seçilmelidir. Referential integrity korunmalıdır. Sonuç örneklem kontrolleriyle doğrulanabilir.

Non-Prod Data Retention

Non-prod veri sonsuza kadar tutulmamalıdır. TTL veya retention policy uygulanabilir. Eski test dataset'leri otomatik silinebilir. Snapshot retention ayrıca kontrol edilmelidir. Silme işlemi audit edilebilir.

Non-Prod Ortamlardaki Access Control

Non-prod ortam güvenliksiz alan olarak görülmemelidir. Özellikle masked bile olsa hassas veriye erişim sınırlandırılmalıdır. Role-based access uygulanabilir. Shared account kullanımından kaçınılmalıdır. Access log tutulmalıdır.

Backup ve Snapshot'larda Kişisel Veri

Backup dosyaları production verisinin tam kopyasını içerebilir. Non-prod restore işlemi bu veriyi beklenmedik yere taşıyabilir. Snapshot sharing kapatılmalıdır. Encryption ve access policy uygulanmalıdır. Retention süresi veri politikasına uygun olmalıdır.

Policy as Code ile Ortam Standartları

Policy as Code yaklaşımı environment standartlarını yalnızca dokümanda bırakmak yerine otomatik olarak uygulamayı sağlar. Production'a açık public port, encryption zorunluluğu, required tag, approved runtime version veya latest container tag yasağı gibi kurallar CI ve deployment katmanında doğrulanabilir. IaC dışı deployment'lar policy ile engellenebilir. Bu kontroller staging üzerinde de çalıştığında production'a gelmeden önce hatalar görülür. Policy sonuçlarının açıklayıcı olması önemlidir çünkü geliştiricinin yalnızca “deployment reddedildi” değil hangi standardın ihlal edildiğini anlaması gerekir.

Production'a Açık Public Port Kontrolü

Policy beklenmeyen public port açılmasını engelleyebilir. Yalnızca allowlist içindeki portlara izin verilebilir. Staging aynı rule ile test edilebilir. Exception için approval gerekir. Drift detection mevcut kaynakları da kontrol etmelidir.

Encryption Requirement

Database ve storage encryption zorunlu tutulabilir. IaC plan policy tarafından kontrol edilir. Şifrelemesiz kaynak production'a deploy edilemez. Key ownership ayrıca doğrulanabilir. Staging policy'yi önceden test eder.

Required Tags

Resource tag'leri owner ve environment bilgisini taşıyabilir. Policy eksik tag bulunan kaynağı reddedebilir. Cost allocation kolaylaşır. Incident sırasında sahiplik bulunur. Tag standardı tüm environment'larda aynı olabilir.

Approved Runtime Versions

Organization desteklenen runtime version listesini tanımlayabilir. Eski veya EOL version deployment'ı engellenebilir. Upgrade için geçiş süresi verilebilir. CI image metadata'yı kontrol edebilir. Exception süreli tutulmalıdır.

No-Latest-Tag Policy

latest tag immutable deployment prensibini bozar. Policy manifest içinde latest kullanımını reddedebilir. Digest veya immutable version tag zorunlu tutulabilir. Bu kural staging ve production için uygulanmalıdır. Development daha esnek olabilir.

IaC Deployment Zorunluluğu

Production resource'larının yalnızca IaC üzerinden oluşturulması policy ile desteklenebilir. Manuel resource creation permission'ı kısıtlanabilir. Break-glass access ayrı tutulur. Drift daha kolay tespit edilir. Resource ownership source repository ile ilişkilendirilebilir.

CI/CD Gate Olarak Policy Check

Policy check pull request aşamasında çalıştırılmalıdır. Geliştirici hızlı geri bildirim alır. Aynı policy deployment admission katmanında tekrar uygulanabilir. İki katman yanlış bypass riskini azaltır. Sonuç pipeline artifact olarak saklanabilir.

Open Source ve İşbirliği Ekosistemi

Ortam senkronizasyonu için kullanılan araçlar tek bir vendor'a bağlı olmak zorunda değildir. Git, Docker, Kubernetes, Terraform veya OpenTofu, Helm, SOPS ve Vault gibi açık kaynak çözümler birlikte kullanılarak esnek bir pipeline oluşturulabilir. Önemli olan araç sayısını artırmak değil her aracın açık bir sorumluluk taşımasıdır. Platform ekibi standart ve otomasyon sağlarken application ekipleri bu standartları günlük geliştirme akışında kullanmalıdır. İyi işbirliği modeli, environment yönetimini yalnızca DevOps ekibinin sorunu olmaktan çıkarır ve ürün ekiplerinin ortak sorumluluğuna dönüştürür.

Git

Git source of truth için temel altyapıyı sağlar. Code, IaC ve config geçmişi tutulabilir. Pull request review mekanizması değişikliği görünür kılar. Branch protection policy uygulanabilir. Git tek başına deployment sistemi değildir.

Docker

Docker runtime paketleme standardı sağlar. Aynı image environment'lar arasında promote edilebilir. Dependency farkları azalır. Security scanning pipeline'a eklenebilir. Image version pinning zorunlu tutulmalıdır.

Kubernetes

Kubernetes declarative deployment modeli sunar. Environment namespace veya cluster bazında ayrılabilir. Resource ve network policy code olarak yönetilebilir. GitOps ile reconciliation uygulanabilir. Gereksiz platform farklarından kaçınılmalıdır.

Terraform / OpenTofu

Terraform ve OpenTofu infrastructure source of truth oluşturabilir. Module reuse environment parity sağlar. Plan çıktısı drift görünürlüğü sunar. State güvenli backend'de tutulmalıdır. Parametreler farkları kontrollü hale getirir.

Argo CD

Argo CD Git repository ile Kubernetes state arasında reconciliation yapabilir. Drift UI üzerinden görülebilir. Application promotion Git değişikliğiyle yapılabilir. Access control önemlidir. Otomatik sync production policy'ye göre yapılandırılabilir.

Flux

Flux GitOps controller olarak sürekli reconciliation sağlar. Image automation özellikleri kullanılabilir. Repository tasarımı parity yönetimini etkiler. Secret çözümü ayrıca planlanmalıdır. Alert ve notification entegrasyonu kurulabilir.

Helm

Helm ortak Kubernetes template'lerini yönetmek için kullanılabilir. Base chart environment farklarını azaltır. Values override kontrollü tutulmalıdır. Chart version promotion takip edilebilir. Render edilen manifest policy check'ten geçebilir.

SOPS

SOPS encrypted config'i repository içinde tutmayı kolaylaştırır. Encryption key access ayrı yönetilir. GitOps akışına uygundur. Decryption yalnızca hedef environment kimliğiyle yapılmalıdır. Key rotation düzenli planlanmalıdır.

Vault

Vault secret ve dynamic credential yönetimi sağlar. Environment path'leri ayrılabilir. Application runtime identity ile secret okuyabilir. Audit ve rotation özellikleri kullanılabilir. Policy tasarımı minimum yetkiyi hedeflemelidir.

Açık Kaynak Tool'larla Vendor-Neutral Pipeline

Vendor-neutral pipeline taşınabilirliği artırabilir. Ancak her tool için operasyon maliyeti vardır. Küçük ekip gereksiz platform yükü oluşturmamalıdır. Standard interface ve open format tercih edilebilir. Araç seçimi ekip kapasitesine göre yapılmalıdır.

Platform Ekibi ile Uygulama Ekiplerinin İşbirliği

Platform ekibi reusable template ve guardrail sağlar. Application ekipleri service-specific ihtiyaçları tanımlar. Ortam parity ortak metric olabilir. Geri bildirim döngüsü standartların kullanılabilir kalmasını sağlar. Sahiplik tek ekipte toplanmamalıdır.

Environment Ownership Modeli

Environment ownership net olmadığında config güncelleme, drift düzeltme ve incident sorumluluğu kolayca birbirine karışır. Developer, DevOps veya platform ekibi, QA, security ve production owner rollerinin sınırları açık biçimde tanımlanmalıdır. Developer application runtime ve deployment requirements konusunda sorumluluk alırken platform ekibi ortak infrastructure ve automation standardını yönetebilir. QA staging readiness ve test kapsamını, security ise policy ve erişim kontrollerini takip edebilir. Environment SLA ve fark onay süreci de bu sorumluluk modelinin parçası olmalıdır.

Developer Sorumlulukları

Developer application code ve config schema'nın sahibidir. Migration dosyalarını doğru üretmelidir. Health check ve observability standardına uymalıdır. Lokal parity gereksinimlerini takip etmelidir. Production davranışını yalnızca platform ekibine bırakmamalıdır.

DevOps / Platform Team

Platform ekibi shared pipeline ve infrastructure template sağlar. Guardrail ve policy'leri yönetir. Drift monitoring platformunu işletir. Developer experience iyileştirilmelidir. Ekibin görevi ticket kapısı olmak değil self-service sağlamaktır.

QA

QA staging environment'ın test edilebilir durumda olduğunu doğrular. Test data kalitesini takip eder. Environment kaynaklı test failure'larını görünür kılar. UAT readiness raporu oluşturabilir. Parity sorunlarını platform ekibiyle paylaşır.

Security

Security access, secret ve policy standardını belirler. Production exception'larını risk açısından değerlendirir. Audit review yapabilir. Supply-chain gate'lerini tanımlayabilir. Geliştiricinin güvenli çözümü kolay kullanabilmesi önemlidir.

Production Owner

Production owner release riskini ve operasyonel sağlığı takip eder. Change approval bu role bağlı olabilir. Incident ve rollback kararında sorumluluk taşır. SLO ve capacity bilgisine hakim olmalıdır. Platform ve product ekipleriyle koordinasyon sağlar.

Farkları Kim Onaylar?

Fark onayı risk türüne göre değişebilir. Security farkını security owner değerlendirebilir. Capacity farkı platform ekibi tarafından onaylanabilir. Business davranış farkında product owner görüşü gerekebilir. Approval matrisi önceden tanımlanmalıdır.

Environment SLA

Her environment aynı SLA'e sahip olmak zorunda değildir. Production en yüksek kullanılabilirlik hedefini taşır. Staging çalışma saatlerinde desteklenebilir. Preview environment kısa ömürlüdür. Beklentiler yazılı olduğunda yanlış öncelik tartışmaları azalır.

Ortam Senkronizasyonu Maliyeti Nasıl Optimize Edilir?

Environment parity yüksek cloud maliyeti anlamına gelmez. Staging kaynakları küçültülebilir, çalışma saatleri dışında kapatılabilir veya düşük trafik servisleri scale-to-zero modeline geçirilebilir. Preview environment'lar yalnızca aktif pull request süresince açık tutulabilir. Shared non-critical services dikkatli izolasyonla kullanılabilir. Maliyet azaltırken korunması gereken ana nokta runtime, deployment, config schema, permission ve network davranışının production modelinden gereksiz biçimde kopmamasıdır.

Staging'i Küçültmek

Staging capacity production'dan daha düşük olabilir. Replica ve instance size küçültülebilir. Minimum functional test ihtiyacı korunmalıdır. Performance testi ayrı ortamda yapılabilir. Resource parametreleri IaC içinde açıkça tutulmalıdır.

Scheduled Shutdown

Gece ve hafta sonu staging kapatılabilir. Database gibi stateful servisler ayrıca planlanmalıdır. Sabah otomatik startup çalışabilir. Test pipeline aktifken shutdown yapılmamalıdır. Maliyet tasarrufu ölçülebilir.

Scale-to-Zero

Serverless veya uygun workload'larda scale-to-zero kullanılabilir. İlk istek cold start oluşturabilir. Bu davranış test süresini etkileyebilir. Production aynı modelde değilse fark belgelenmelidir. Preview environment için özellikle yararlıdır.

Ephemeral Preview Environments

Kalıcı shared development yerine geçici preview kullanılabilir. Kaynaklar yalnızca ihtiyaç sırasında açılır. TTL otomatik cleanup sağlar. Shared dependency maliyeti düşürebilir. Data isolation mutlaka korunmalıdır.

Shared Non-Critical Services

Bazı non-critical servisler development ortamları arasında paylaşılabilir. Queue namespace veya database schema izolasyonu uygulanmalıdır. Production hiçbir zaman aynı servis instance'ını paylaşmamalıdır. Shared kullanımın test etkisi değerlendirilmelidir. Capacity conflict monitoring ile izlenebilir.

Parity'yi Bozmadan Maliyet Azaltma

Maliyet azaltma davranış yerine kapasite üzerinden yapılmalıdır. Aynı container ve deployment modeli korunabilir. Sadece replica veya CPU düşürülebilir. Kritik performance testleri geçici kapasiteyle yapılabilir. Bu yaklaşım parity ile bütçe arasında denge kurar.

Küçük Ekipler İçin Minimum Environment Yapısı

Küçük ekiplerin çok sayıda cluster ve servis kurması gerekmez. İyi tasarlanmış lokal development, paylaşılan staging ve production üçlüsü çoğu küçük ürün için yeterli olabilir. Basit bir CI/CD pipeline, temel IaC, secrets manager ve migration pipeline eklendiğinde önemli parity riskleri kontrol altına alınabilir. Önce tekrar üretilebilirlik ve güvenli deployment sağlanmalı, daha sonra ihtiyaç oldukça preview veya GitOps gibi ek katmanlar eklenmelidir. Platformu gereğinden fazla büyütmek küçük ekipte bakım yükünü artırabilir ve asıl ürün geliştirme hızını düşürebilir.

Local Development

Lokal development container ile standardize edilebilir. Database ve cache Docker Compose üzerinden çalıştırılabilir. Runtime version production ile eşleşir. Synthetic seed data kullanılır. Geliştirici hızlı reset yapabilmelidir.

Shared Staging

Tek shared staging küçük ekip için yeterli olabilir. Production-like deployment mekanizması kullanılmalıdır. Test data kontrollü tutulmalıdır. Deployment ownership açık olmalıdır. Environment drift düzenli kontrol edilmelidir.

Production

Production ayrı infrastructure ve credentials kullanmalıdır. Deployment yalnızca pipeline üzerinden yapılmalıdır. Backup ve monitoring minimum gereksinimdir. İnsan erişimi sınırlandırılmalıdır. Rollback prosedürü dokümante edilmelidir.

Basit CI/CD

Pipeline önce test sonra build yapabilir. Tek artifact registry'ye gönderilir. Staging deployment otomatik olabilir. Production manuel approval içerebilir. Aynı artifact promote edilmelidir.

IaC

Basit Terraform veya benzeri IaC bile büyük fayda sağlar. Network ve compute tanımları sürümlenir. Environment parameter dosyaları ayrılır. Manuel cloud değişikliği azalır. Küçük ekipte bile drift görünür olur.

Secrets Manager

Secret dosyalarını paylaşmak yerine managed secret store kullanılabilir. Environment path'leri ayrılır. Production secret sadece production workload tarafından okunur. Rotation planlanabilir. Lokal development için ayrı test credentials sağlanır.

Migration Pipeline

Migration dosyaları repository içinde tutulmalıdır. Staging üzerinde otomatik uygulanabilir. Production deployment öncesi kontrol çalışır. Destructive migration approval isteyebilir. Schema version izlenmelidir.

Kurumsal Ekipler İçin Referans Mimari

Kurumsal ekiplerde environment yapısı daha fazla kontrol ve ayrıştırma gerektirebilir. Developer environment, pull request preview, integration, staging veya UAT ve production katmanları farklı test amaçlarına hizmet eder. Merkezi artifact registry, configuration store, secrets management, GitOps controller ve observability platform bu environment'ların ortak servislerini oluşturabilir. Bu tasarımda her environment'ın sahibi, SLA'i ve parity contract içindeki rolü tanımlanmalıdır. Diyarbakır Yazılım Topluluğu tarafından paylaşılan çalışma ve proje yaklaşımını incelemek isteyenler https://www.diyarbakiryazilim.com.tr/projects adresindeki içeriklerden de yararlanabilir.

Developer Environment

Developer environment kişisel veya shared olabilir. Hızlı feedback önceliklidir. Runtime standardı production'a yakın tutulur. Gerçek customer data kullanılmaz. Self-service reset önemli bir özelliktir.

Pull Request Preview

Preview environment değişikliği merge öncesi görünür hale getirir. Her branch için otomatik provisioning yapılabilir. TTL cleanup maliyeti kontrol eder. Synthetic data kullanılır. Security policy production template'inden türetilebilir.

Integration Environment

Integration ortamı birden fazla servisin birlikte test edildiği alan olabilir. Shared dependency sürümleri kontrollü tutulur. Contract test sonuçları izlenebilir. Deploy sırası otomasyonla yönetilir. Environment contention planlanmalıdır.

Staging / UAT

Staging veya UAT production release adayını doğrular. Aynı artifact burada test edilir. Production-like network ve permission modeli uygulanır. Masked veya synthetic veri kullanılır. Business acceptance sonucu kayıt altına alınır.

Production

Production yüksek erişilebilirlik ve güvenlik gerektirir. Artifact promotion kontrollü yapılır. Change audit ve observability zorunludur. Access en düşük yetki prensibiyle sınırlandırılır. Incident runbook hazır tutulur.

Artifact Registry

Registry tüm build çıktılarının merkezi deposudur. Immutable image policy kullanılabilir. Vulnerability scan entegre edilir. Promotion metadata tutulur. Retention policy maliyet kontrolü sağlar.

Configuration Store

Configuration store non-secret dynamic değerleri merkezi yönetebilir. Environment namespace'i açık tutulmalıdır. Versioning sağlanmalıdır. Audit log değişiklikleri gösterir. Application startup fallback davranışı tanımlanmalıdır.

Secrets Management

Merkezi secret platform environment izolasyonunu güçlendirir. Dynamic credential tercih edilebilir. Rotation otomatik hale getirilebilir. İnsan erişimi minimum tutulur. Audit tüm secret okuma işlemlerini izler.

GitOps Controller

GitOps controller desired state'i sürekli uygular. Drift görünür hale gelir. Environment promotion pull request ile yönetilebilir. Sync policy risk seviyesine göre değişebilir. Production değişiklikleri audit edilebilir.

Observability Platform

Ortak observability platform log, metric ve trace verisini birleştirir. Environment tag ile ayrım yapılır. Dashboard template'leri paylaşılır. Deployment event'leri metric timeline'a eklenir. Incident correlation hızlanır.

Geliştirme, Staging ve Production Senkronizasyonu İçin Adım Adım Yol Haritası

Geliştirme, Staging ve Production Ortamlarının Senkronizasyonu tek seferde tamamlanan bir altyapı projesi değildir. En sağlıklı yaklaşım mevcut durumu ölçmek, en büyük drift kaynaklarını belirlemek ve otomasyonu aşamalı olarak artırmaktır. İlk aşamada environment envanteri ve diff analizi yapılır, ardından parity contract ve source of truth oluşturulur. Container, IaC, config schema, secret management ve migration pipeline daha sonra aynı deployment zincirine bağlanır. Son adımda drift detection, parity testleri ve intentional differences registry sürekli operasyon modeline dönüştürülür.

1. Mevcut Ortamların Envanterini Çıkarın

İlk olarak hangi environment ve servislerin bulunduğunu listeleyin. Runtime, database, network ve deployment bilgilerini kaydedin. Kimlerin eriştiğini belirleyin. Manuel kaynakları ayrıca işaretleyin. Envanter parity çalışmasının temelini oluşturur.

2. Dev–Staging–Prod Diff Analizi Yapın

Ortamlar arasında teknik karşılaştırma yapın. Version, config, network ve infrastructure farklarını çıkarın. Farkları bilinçli veya drift olarak sınıflandırın. Risk seviyesini belirleyin. En yüksek riskli farklardan başlayın.

3. Parity Contract Oluşturun

Hangi alanların aynı olması gerektiğini yazın. İzin verilen farkları ayrıca belirtin. Exception sürecini tanımlayın. Owner ve expiration mekanizması ekleyin. Contract machine-readable hale getirilebiliyorsa otomasyon kolaylaşır.

4. Kod ve Infrastructure'ı Git'e Alın

Application code zaten Git'te olabilir. Infrastructure ve deployment tanımlarını da ekleyin. Config schema sürümlensin. Manual script'leri repository'ye taşıyın. Secret değerleri kesinlikle eklemeyin.

5. IaC Standardı Oluşturun

Ortak module yapısı oluşturun. Environment parametrelerini ayırın. Duplicate infrastructure code'u azaltın. State backend güvenli tutulmalıdır. Plan review süreci belirlenmelidir.

6. Container ve Dependency Version'larını Pinleyin

Runtime ve base image version'larını sabitleyin. Lockfile kullanımını zorunlu hale getirin. latest tag kullanımını kaldırın. Artifact digest kaydedin. Controlled update süreci kurun.

7. Configuration Schema'yı Merkezileştirin

Gerekli config anahtarlarını tek schema altında tanımlayın. Type ve required bilgisini ekleyin. CI validation çalıştırın. Startup validation uygulayın. Unknown key kullanımını yakalayın.

8. Secret'ları Ortam Bazında Ayırın

Her environment ayrı secret setine sahip olsun. Production credentials non-prod erişimine kapatılmalıdır. Secret manager kullanın. Runtime injection uygulayın. Rotation politikasını tanımlayın.

9. Database Migration Pipeline'ı Kurun

Migration dosyalarını version control içinde tutun. Staging üzerinde otomatik doğrulayın. Schema version tracking ekleyin. Destructive migration gate kullanın. Production change kayıtlarını saklayın.

10. Tek Artifact Promotion Modeline Geçin

Her environment için yeniden build almayı bırakın. CI tek artifact üretsin. Registry immutable storage sağlasın. Staging ve production aynı digest'i kullansın. Environment config runtime sırasında verilsin.

11. CI/CD Promotion Gate'leri Ekleyin

Test ve security kontrollerini pipeline'a yerleştirin. Migration ve parity check ekleyin. Riskli release için approval kullanın. Sonuçları artifact metadata ile ilişkilendirin. Gate'leri gereksiz yere çoğaltmayın.

12. Drift Detection Kurun

IaC plan scheduled çalıştırılabilir. Config ve version drift ayrıca kontrol edilir. Kritik farklar alarm üretir. Owner'a otomatik routing yapılır. Intentional difference registry ile false positive azaltılır.

13. Parity Testlerini Otomatikleştirin

Container digest ve runtime version karşılaştırın. Config schema ve migration level kontrol edin. Network policy diff ekleyin. Required secret presence doğrulayın. Sonucu parity score olarak raporlayabilirsiniz.

14. Intentional Differences Registry Oluşturun

Bilinçli farkları merkezi listeye alın. Reason, risk, owner ve expiration ekleyin. CI bu kayıtları okuyabilir. Eski exception'lar düzenli temizlenir. Registry canlı doküman olarak yönetilmelidir.

15. Sürekli Review ve Cleanup Yapın

Environment standardı bir kez kurulup unutulmamalıdır. Aylık veya çeyreklik review yapılabilir. Eski flag, secret ve resource'lar temizlenir. Parity score trendi izlenir. Incident'lardan yeni kontroller çıkarılmalıdır.

En Sık Yapılan Hatalar

Environment yönetiminde en sık yapılan hatalar genellikle iyi niyetli kısa yolların zaman içinde kalıcı hale gelmesinden kaynaklanır. Production'ı birebir kopyalamaya çalışmak gereksiz maliyet üretirken staging'i aşırı farklı bırakmak test değerini düşürür. Her environment için ayrı build almak, latest tag kullanmak veya production secret'larını non-prod ortama taşımak ciddi risk oluşturur. Manuel migration, Click-Ops ve maskesiz production data kullanımı da drift ve güvenlik problemlerinin temel kaynaklarıdır. Bu hataların ortak çözümü source of truth, otomatik promotion ve açık parity contract yaklaşımıdır.

Staging'i Production'ın Birebir Kopyası Yapmaya Çalışmak

Birebir kopya yüksek maliyet oluşturabilir. Her kapasite farkı parity problemi değildir. Davranışsal eşleşmeye odaklanılmalıdır. Security ve credentials zaten ayrı olmalıdır. Production-like yaklaşımı daha gerçekçidir.

Staging'i Production'dan Fazla Farklı Bırakmak

Aşırı küçük veya farklı staging test değerini azaltır. Farklı runtime kullanmak özellikle risklidir. Network ve permission modeli gevşetilmemelidir. Bilinçli farklar registry içinde tutulmalıdır. Kritik parity alanları otomatik kontrol edilmelidir.

Her Ortam İçin Ayrı Build Almak

Ayrı build farklı dependency sonucu üretebilir. Staging testinin production artifact'i doğruladığı garanti edilemez. Tek artifact modeli kullanılmalıdır. Environment config runtime sırasında uygulanmalıdır. Registry digest promotion'ı kolaylaştırır.

latest Docker Tag Kullanmak

latest image kimliğini belirsiz hale getirir. Aynı tag başka içerikle değişebilir. Rollback zorlaşır. Digest veya immutable tag kullanılmalıdır. Policy latest kullanımını engelleyebilir.

Ortama Göre Farklı Kod Çalıştırmak

Environment adına göre code branch oluşturmak risklidir. Production path'i staging'de test edilmemiş olabilir. Farklı davranış config veya feature flag ile yönetilmelidir. Aynı code artifact tüm ortamlarda çalışmalıdır. İstisnalar minimum tutulmalıdır.

Production Secret'larını Staging'e Kopyalamak

Bu yaklaşım environment izolasyonunu yok eder. Staging breach production erişimine dönüşebilir. Sandbox credentials kullanılmalıdır. Secret schema aynı olabilir. Secret değerleri kesinlikle ayrı tutulmalıdır.

Dev ve Production Database'i Paylaştırmak

Development yanlışlıkla gerçek veriyi değiştirebilir. Test script'i destructive işlem çalıştırabilir. Network seviyesinde erişim kapatılmalıdır. Her environment ayrı database kullanmalıdır. Production veri kopyaları da kontrollü olmalıdır.

Migration'ları Manuel Çalıştırmak

Manuel migration schema drift üretir. Hangi script'in çalıştığı belirsizleşebilir. Versioned migration pipeline kullanılmalıdır. Production için approval eklenebilir. Uygulanan version kaydedilmelidir.

Production Verisini Maskesiz Staging'e Kopyalamak

Maskesiz veri ciddi privacy riski oluşturur. Non-prod erişimi genellikle daha geniştir. Synthetic veya anonymized veri tercih edilmelidir. Gerekiyorsa deterministic masking uygulanmalıdır. Snapshot retention ayrıca kontrol edilmelidir.

Feature Flag Drift'ini İzlememek

Flag farkı staging testini anlamsız hale getirebilir. Promotion öncesi flag state kontrol edilmelidir. Critical flag'ler approval gerektirebilir. Stale flag cleanup yapılmalıdır. Version ve owner bilgisi tutulmalıdır.

Staging Permission'larını Production'dan Çok Gevşek Tutmak

Staging admin yetkili çalışırsa production authorization sorunu görülmez. RBAC modelinin mantığı eşleşmelidir. Service account'lar ayrı olmalıdır. Least privilege test edilmelidir. Negative permission testleri eklenebilir.

Network Farklarını İhmal Etmek

Network parity application kadar önemlidir. TLS, DNS ve firewall farkları yalnızca production hatası oluşturabilir. IaC template kullanılmalıdır. Egress policy staging'de test edilmelidir. Network diff otomatik çalıştırılabilir.

Click-Ops ile Production Değişikliği Yapmak

Manuel console değişikliği source of truth'u bozar. Acil durumda gerekebilir. Ancak işlem sonrasında Git'e geri yazılmalıdır. Audit tutulmalıdır. Normal değişiklik yolu IaC olmalıdır.

Acil Hotfix'i IaC'ye Geri İşlememek

Hotfix repository'ye dönmezse bir sonraki deployment değişikliği siler. Drift kalıcı hale gelir. Incident kapanışında reconciliation yapılmalıdır. Git commit ilgili incident ile ilişkilendirilebilir. Review normal süreçten geçmelidir.

Intentional Differences'ları Dokümante Etmemek

Dokümansız fark zamanla drift gibi görünür. Ekip neden var olduğunu unutabilir. Registry reason ve owner bilgisi tutmalıdır. Expiration date eklenmelidir. Otomatik parity check registry'yi okuyabilir.

Environment Parity'yi Manuel Kontrol Etmek

Manuel checklist bir süre sonra atlanır. İnsan karşılaştırması büyük sistemlerde ölçeklenmez. Kritik alanlar CI ile otomatik doğrulanmalıdır. Dashboard trend gösterebilir. İnsan review istisna ve risk kararına odaklanmalıdır.

Sonuç

Geliştirme, Staging ve Production Ortamlarının Senkronizasyonu güçlü bir DevOps pratiği olmanın ötesinde, yazılım teslim sürecindeki belirsizliği azaltan temel bir mühendislik disiplinidir. Aynı artifact'i promote etmek, configuration schema'yı ortak tutmak, secret'ları ortam bazında ayırmak, migration'ları versionlamak ve infrastructure drift'i otomatik izlemek bu disiplinin temel taşlarıdır. Küçük ekipler birkaç basit otomasyonla başlayabilir, kurumsal yapılar ise parity contract, GitOps, policy as code ve kapsamlı promotion gate'leriyle süreci ileri taşıyabilir. DevOps ortam yönetimi ve CI/CD danışmanlığı yakınımda şeklinde çözüm arayan ekipler, Diyarbakır Yazılım Topluluğu'nun yaklaşımı ve topluluk çalışmaları hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilir. Projenizde environment drift, CI/CD, container, Kubernetes veya deployment standardı konusunda daha sağlam bir yapı kurmak istiyorsanız https://www.diyarbakiryazilim.com.tr üzerinden Diyarbakır Yazılım Topluluğu'na ulaşabilirsiniz.

Sık Sorulan Sorular

Environment parity konusu farklı ekip yapıları ve altyapı tercihlerine göre değişen çok sayıda pratik soruyu beraberinde getirir. Tek bir reçete yerine risk, ekip büyüklüğü ve deployment sıklığı birlikte değerlendirilmelidir. Aşağıdaki sorular development, staging ve production yönetiminde en sık karşılaşılan karar noktalarını özetler. Cevapların ortak noktası her ortamı birebir kopyalamak değil, davranışı etkileyen farkları kontrol altında tutmaktır. Otomasyon ve source of truth yaklaşımı bu soruların büyük bölümünde ortak çözüm temelini oluşturur.

Development, staging ve production ortamları nedir?

Development geliştiricilerin hızlı değişiklik yaptığı ortamdır. Staging production öncesi doğrulama alanıdır. Production gerçek kullanıcı trafiğini taşır. Bu ortamların amaçları farklıdır. Buna rağmen runtime, artifact ve deployment gibi davranışsal bileşenlerde yüksek parity hedeflenmelidir.

Environment parity nedir?

Environment parity ortamların application davranışı açısından yeterince benzer olmasıdır. Değerlerin birebir eşleşmesi gerekmez. Configuration schema, runtime ve deployment mekanizması gibi alanlar uyumlu tutulur. Credentials ve gerçek database gibi hassas kaynaklar ayrı olur. Parity bilinçli farkları da açıkça tanımlar.

Dev, staging ve production tamamen aynı mı olmalıdır?

Hayır, tamamen aynı olmaları gerekmez. Production kapasitesi daha yüksek olabilir. Secret ve database kesinlikle ayrı olmalıdır. Davranışsal bileşenler ise mümkün olduğunca eşleştirilmelidir. İzin verilen farklar dokümante edilmelidir.

Staging production ile aynı sunucu boyutunda mı olmalıdır?

Çoğu durumda hayır. Staging daha küçük kapasiteyle çalışabilir. Functional parity için aynı application ve infrastructure modeli daha önemlidir. Performance testlerinde geçici olarak production benzeri kapasite açılabilir. Kalıcı büyük staging her ekip için gerekli değildir.

Production verisi staging'de kullanılabilir mi?

Ham production verisi varsayılan olarak kullanılmamalıdır. Privacy ve KVKK riskleri değerlendirilmelidir. Masking, anonymization veya synthetic data tercih edilebilir. Gerçek veri gerekiyorsa minimum kapsam kullanılmalıdır. Retention ve erişim sıkı biçimde kontrol edilmelidir.

Ortamlar arasında environment variable'lar nasıl yönetilir?

Aynı key schema'sı tüm ortamlarda kullanılmalıdır. Değerler environment bazında değişebilir. Config validation CI ve startup aşamasında yapılmalıdır. Secret değerler ayrı secret manager üzerinden gelmelidir. Unknown veya eksik key'ler deployment öncesi yakalanmalıdır.

Secret'lar dev, staging ve production arasında aynı olmalı mı?

Hayır, secret değerleri aynı olmamalıdır. Her environment ayrı credentials kullanmalıdır. Secret isimleri veya schema ortak olabilir. Production secret non-prod ortamdan erişilememelidir. Rotation süreçleri de environment bazında yönetilmelidir.

Database schema nasıl senkronize edilir?

Versioned migration dosyaları kullanılmalıdır. Migration'lar development, staging ve production sırasıyla promote edilmelidir. Schema version tracking uygulanmalıdır. Manuel SQL değişiklikleri engellenmelidir. Drift detection gerçek schema ile migration geçmişini karşılaştırabilir.

Infrastructure drift nasıl tespit edilir?

IaC desired state ile cloud actual state karşılaştırılır. Terraform plan veya benzeri diff araçları kullanılabilir. Scheduled drift detection düzenli çalıştırılmalıdır. Kritik farklar alarm oluşturmalıdır. Bilinçli farklar exception registry üzerinden hariç tutulabilir.

Aynı Docker image staging'den production'a nasıl taşınır?

CI tek container image üretmelidir. Image registry'ye immutable tag veya digest ile gönderilir. Staging aynı digest'i deploy eder. Testlerden sonra production manifestine aynı digest promote edilir. Production için yeniden build alınmaz.

Feature flag'ler ortamlar arasında nasıl yönetilir?

Feature flag tanımları merkezi tutulmalıdır. Değerler environment bazında farklı olabilir. Staging ve production arasındaki fark bilinçli olmalıdır. Promotion ve approval akışı kullanılabilir. Eski flag'ler düzenli temizlenmelidir.

Terraform ile dev, staging ve production nasıl ayrılır?

Ortak module kullanmak iyi başlangıçtır. Environment-specific tfvars veya stack config ile kapasite ve domain değerleri ayrılabilir. State dosyaları birbirinden izole tutulmalıdır. Duplicate infrastructure code'dan kaçınılmalıdır. Plan çıktıları ortam farklarını görünür hale getirir.

GitOps environment synchronization için uygun mudur?

Evet, özellikle Kubernetes tabanlı yapılarda uygundur. Git desired state olarak kullanılır. Controller actual state'i sürekli karşılaştırır. Drift otomatik görünür hale gelir. Production promotion pull request üzerinden yönetilebilir.

Environment parity CI/CD pipeline içinde nasıl test edilir?

Pipeline runtime version, image digest ve config schema kontrol edebilir. Migration version ve infrastructure diff eklenebilir. Required secret presence doğrulanabilir. Bilinçli farklar registry üzerinden filtrelenir. Kritik uyumsuzluk production promotion'ı durdurur.

“Works in staging but fails in production” problemi nasıl çözülür?

Önce staging ve production arasındaki farklar sistematik biçimde çıkarılmalıdır. Artifact digest, runtime, config, permission, network ve database version kontrol edilmelidir. Farkın nedeni bulunduktan sonra parity contract güncellenmelidir. Aynı sınıf sorunu yakalayan otomatik test eklenmelidir. Hedef yalnızca mevcut incident'ı çözmek değil tekrarını önlemektir.

Geliştirme, staging ve production ortamları nasıl senkronize edilir?

Geliştirme, staging ve production ortamları ortak source of truth, IaC, containerization ve CI/CD promotion modeli kullanılarak senkronize edilir. Runtime, dependency, deployment artifact'i, migration mekanizması ve configuration schema gibi davranışsal alanlar aynı tutulur. Environment'a özgü değerler açık parametreler ve secret store üzerinden yönetilir. Infrastructure drift, config drift ve schema drift otomatik kontrollerle düzenli izlenir. Bu yaklaşım Geliştirme, Staging ve Production Ortamlarının Senkronizasyonu için tekrar üretilebilir ve denetlenebilir bir temel oluşturur.

Development, staging ve production ortamlarında konfigürasyon farklılıkları nasıl yönetilmelidir?

Konfigürasyon farklılıkları ortak base configuration ve sınırlı environment-specific override modeliyle yönetilmelidir. Anahtar schema'sı aynı kalırken database URL, domain veya kapasite gibi değerler farklı olabilir. Zorunlu config anahtarları CI içinde doğrulanmalıdır. Secret değerleri config dosyalarından ayrı tutulmalıdır. Bilinçli her farklılık mümkünse parity contract veya intentional differences registry içinde belgelenmelidir.

Veritabanı şeması, environment variable ve uygulama sürümleri ortamlar arasında nasıl tutarlı tutulur?

Database schema versioned migration dosyalarıyla yönetilir. Environment variable'lar ortak configuration schema üzerinden doğrulanır. Application version ise tek build artifact'inin environment'lar arasında promote edilmesiyle sabit tutulur. Pipeline her deployment öncesinde migration seviyesi, config schema ve artifact digest kontrolü yapabilir. Bu üç kontrol birlikte uygulandığında en yaygın environment drift kaynaklarının önemli bölümü otomatik olarak engellenir.

CI/CD pipeline’ları ile geliştirme, staging ve production ortamlarına güvenli ve kontrollü deployment nasıl yapılır?

CI/CD pipeline önce testleri çalıştırmalı ve tek immutable artifact üretmelidir. Aynı artifact development veya preview ortamından staging'e, ardından production'a promote edilmelidir. Staging aşamasında integration test, migration check, security scan ve parity kontrolü yapılabilir. Production promotion risk seviyesine göre otomatik veya manuel approval içerebilir. Deployment sonrasında health, error rate ve rollout durumu observability sistemi üzerinden izlenmelidir.

Development, staging ve production ortam senkronizasyonu konusunda yakınımda DevOps danışmanlığı veya eğitim nerede bulabilirim?

Yerel topluluklar ve teknik eğitim grupları DevOps ortam yönetimi, CI/CD, container ve infrastructure automation konusunda güçlü bir başlangıç noktası sunabilir. Diyarbakır ve çevresinde yazılım ekosistemi, eğitimler ve teknik çalışmalar hakkında bilgi edinmek için Diyarbakır Yazılım Topluluğu'nun içeriklerini inceleyebilirsiniz. Topluluk hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir. Proje ve çalışma örneklerini görmek için https://www.diyarbakiryazilim.com.tr/projects adresine göz atabilirsiniz. Güncel erişim ve iletişim için https://www.diyarbakiryazilim.com.tr adresi üzerinden topluluğa ulaşabilirsiniz.