Go arka uçları için CI/CD: derleme, test, migrasyon, dağıtım

Go arka uçları için CI/CD neden önemli

Manuel dağıtımlar sıkıcı, tekrarlanabilir şekilde başarısız olur. Birisi kendi dizüstünde farklı bir Go sürümüyle derler, bir ortam değişkenini unutur, bir migrasyonu atlar veya yanlış servisi yeniden başlatır. Sürüm "bende çalışıyor" durumu üretimde çalışmaz ve bunu kullanıcılar hissetmeden önce fark etmezsiniz.

Üretilmiş kod, yayın disiplinine olan ihtiyacı ortadan kaldırmaz. Gereksinimleri güncelledikten sonra bir arka ucu yeniden ürettiğinizde, elle hiç ellememiş olsanız bile yeni endpoint'ler, yeni veri şekilleri ya da yeni bağımlılıklar ekleyebilirsiniz. İşte tam da bu durumda pipeline bir güvenlik korkuluğu gibi davranmak ister: her değişiklik her seferinde aynı kontrollerden geçer.

Tahmin edilebilir ortamlar, derleme ve dağıtım adımlarınızın adını koyup tekrar edebileceğiniz koşullarda çalışması demektir. Birkaç kural çoğunu kapsar:

• Sürümleri sabitleyin (Go toolchain, base imajlar, OS paketleri).
• Bir kere derleyin, aynı artefaktı her yere dağıtın.
• Konfigürasyonu ikili dosyanın dışında tutun (her ortam için env var'lar veya config dosyaları).
• Her ortamda aynı migrasyon aracını ve sürecini kullanın.
• Rollbackleri gerçek yapın: önceki artefaktı saklayın ve veritabanıyla ne olacağını bilin.

Go arka uçları için CI/CD'nin amacı otomasyon için otomasyon değildir. Amaç daha az stresle tekrarlanabilir yayınlardır: yeniden üretin, pipeline'ı çalıştırın ve çıkanın dağıtılabilir olduğuna güvenin.

AppMaster gibi Go arka uçları üreten bir jeneratör kullanıyorsanız, bu daha da önem kazanır. Yeniden üretim bir özelliktir, ama değişiklikten üretime giden yol tutarlı, test edilmiş ve öngörülebilir olduğunda güvenli hisseder.

Çalışma ortamınızı seçin ve “tahmin edilebilir”i önceden tanımlayın

"Tahmin edilebilir", aynı girdinin nerede çalıştırılırsa çalıştırılsın aynı sonucu üretmesi demektir. Go arka uçları için CI/CD'de bu, dev, staging ve prod arasında hangi şeylerin kesinlikle aynı kalması gerektiğinde anlaşmaya varmaktan başlar.

Genelde tartışılmaz olanlar: Go sürümü, temel OS imajı, derleme bayrakları ve konfigürasyonun nasıl yüklendiğidir. Bunlardan herhangi biri ortam bazında değişirse, farklı TLS davranışları, eksik sistem paketleri ya da sadece üretimde görülen hatalar gibi sürprizler yaşarsınız.

Ortam kaymaları genellikle aynı yerlerde ortaya çıkar:

• OS ve sistem kütüphaneleri (farklı distro sürümleri, eksik CA sertifikaları, saat dilimi farkları)
• Konfigürasyon değerleri (feature flag'ler, zaman aşımılar, allowed origins, dış servis URL'leri)
• Veritabanı şekli ve ayarları (migrasyonlar, eklentiler, kollasyon, bağlantı limitleri)
• Sırlar yönetimi (nerede duruyorlar, nasıl döndürülüyor, kim okuyabiliyor)
• Ağ varsayımları (DNS, firewall'lar, servis keşfi)

Kubernetes ile VM'ler arasında seçim yapmak "hangisi daha iyi"den çok, ekibinizin hangisini sakin çalıştırabileceğiyle ilgilidir.

Kubernetes; otomatik ölçekleme, rolling update'ler ve birçok servisi çalıştırmanın standart bir yoluna ihtiyaç duyduğunuzda uygundur. Aynı zamanda pod'ların aynı imajdan çalıştırılması sayesinde tutarlılığı zorlamaya yardımcı olur. VM'ler ise bir veya birkaç servisiniz olduğunda, küçük bir ekip için ve daha az hareketli parça istediğinizde doğru seçim olabilir.

Pipeline'ı aynı tutabilirsiniz, hatta çalışma ortamları farklı olsa bile artefaktı ve onun etrafındaki sözleşmeyi standartlaştırarak. Örneğin: CI'de her zaman aynı container imajını derleyin, aynı test adımlarını çalıştırın ve aynı migrasyon paketini yayınlayın. O zaman sadece deploy adımı değişir: Kubernetes yeni image tag'ini uygular, VM'ler imajı çeker ve servisi yeniden başlatır.

Pratik bir örnek: bir ekip AppMaster'dan üretilmiş bir Go arka ucu yeniden üretir ve staging'e Kubernetes'e dağıtır ama prod için şimdilik VM kullanır. İkisi de aynı imajı çekip aynı türden bir secret store'dan konfigürasyon yüklüyorsa, "farklı çalışma zamanı" bir dağıtım detayı olur, hata kaynağı olmaz. AppMaster (appmaster.io) kullanıyorsanız, bu model yönetilen bulut hedeflerine dağıtmanızı ya da kaynak kodu dışa aktarıp kendi altyapınızda aynı pipeline'ı çalıştırmanızı sağlar.

Herkese açıklayabileceğiniz basit bir pipeline haritası

Tahmin edilebilir bir pipeline kolayca tanımlanabilir: kodu kontrol et, derle, çalıştığını kanıtla, test ettiğin aynı şeyi gönder, sonra her seferinde aynı şekilde dağıt. Bu netlik, arka ucunuz yeniden üretiliyorsa daha da önemlidir çünkü değişiklikler birden çok dosyayı etkileyebilir ve hızlı, tutarlı geri bildirim istersiniz.

Basit bir Go arka uç CI/CD akışı şöyle görünür:

• Lint ve temel kontroller
• Derleme
• Birim testleri
• Entegrasyon kontrolleri
• Paketleme (değiştirilemez artefaktlar)
• Migrasyon (kontrollü adım)
• Dağıtım

Başarısızlıkların erken durmasını sağlayacak şekilde yapılandırın. Eğer lint başarısız olursa başka bir şey çalışmamalı. Derleme başarısızsa, entegrasyon kontrolleri için veritabanı başlatmaya vakit harcamayın. Bu maliyetleri düşürür ve pipeline'ın hızlı hissettirmesini sağlar.

Her adım her commit'te çalışmak zorunda değildir. Yaygın bir ayrım:

• Her commit/PR: lint, derleme, birim testleri
• Main branch: entegrasyon kontrolleri, paketleme
• Release tag'leri: migrasyon, deploy

Hangi şeyleri artefakt olarak saklayacağınıza karar verin. Genellikle bu derlenmiş ikili veya container imajı (dağıttığınız şey), artı migrasyon logları ve test raporlarıdır. Bunları saklamak rollback ve denetimler için işleri basitleştirir çünkü tam olarak neyin test edilip yükseltildiğini gösterebilirsiniz.

Adım adım: stabil ve tekrarlanabilir bir derleme aşaması

Bir derleme aşaması tek bir soruya cevap vermeli: bugün, yarın ve farklı bir runner'da aynı ikiliyi üretebilir miyiz? Eğer bu doğru değilse, sonraki her adım (testler, migrasyonlar, deploy) güvenilir olmaktan çıkar.

Çevreyi sabitleyerek başlayın. Sabit bir Go sürümü kullanın (örneğin 1.22.x) ve sabit bir runner imajı (Linux dağıtımı ve paket sürümleri). "latest" etiketlerinden kaçının. libc, Git veya Go toolchain'deki küçük değişiklikler "bende çalışıyor" hataları yaratabilir ve bunlar çözmesi acı verir.

Module cache faydalıdır ama onu hız artışı olarak görün, doğruluk kaynağı olarak değil. Go build cache ve module download cache'i cacheleyin, ama anahtar olarak go.sum kullanın (veya bağımlılıklar değiştiğinde main'de temizleyin) ki yeni bağımlılıklar temiz indirmeyi tetiklesin.

Derlemeden önce hızlı bir kapı ekleyin. Hızlı olsun ki geliştiriciler atlamasın. Tipik bir set: gofmt kontrolleri, go vet ve (hızlı kalıyorsa) staticcheck. Ayrıca eksik veya eski üretilmiş dosyalarda hata verin; bu, yeniden üretilmiş kod tabanlarında sık görülen bir sorundur.

Yeniden üretilebilir şekilde derleyin ve sürüm bilgisini gömün. -trimpath gibi flag'ler yardımcı olur ve -ldflags ile commit SHA ve build zamanını enjekte edebilirsiniz. Her servis için tek bir adlandırılmış artefakt üretin. Bu, Kubernetes'te veya bir VM'de neyin çalıştığını takip etmeyi kolaylaştırır, özellikle arka uç yeniden üretildiğinde.

Adım adım: dağıtımdan önce sorunları yakalayan testler

Testler sadece her seferinde aynı şekilde çalışırlarsa yardım eder. Önce hızlı geri bildirime odaklanın, sonra yine de öngörülebilir sürede biten daha derin kontroller ekleyin.

Her commit'te birim testleri ile başlayın. Donmuş testlerin tüm pipeline'ı asmak yerine yüksek sesle başarısız olmasını sağlamak için zorunlu bir zaman aşımı belirleyin. Ayrıca ekibiniz için "yeterli" kapsama karar verin. Kapsam bir kupa değil, ama bir asgari sınır kalite sürüklenmesini engellemeye yardımcı olur.

Stabil bir test aşaması genellikle şunları içerir:

• go test ./... çalıştırın, paket başına zaman aşımı ve küresel job zaman aşımı ile.
• Zaman aşımına takılan herhangi bir testi gerçek bir hata olarak ele alın, "CI dalgalanıyor" demeyin.
• Kritik paketler (auth, faturalama, izinler) için kapsama beklentileri belirleyin; tüm repo için zorunlu kılmayabilirsiniz.
• Eşzamanlılığı ele alan kodlar için race detector ekleyin (kuyruklar, cache'ler, fan-out worker'lar).

Race detector değerlidir ama derlemeleri yavaşlatabilir. İyi bir uzlaşma: PR'larda ve gece çalıştırmalarında veya seçilmiş paketlerde çalıştırmak.

Dalgalı (flaky) testler derlemeyi kırmalıdır. Bir testi karantinaya almak zorundaysanız, görünür tutun: farklı bir job'a taşıyın, yine de çalışsın ve kırmızı rapor versin; bir sahibi ve düzeltilme süresi isteyin.

Hata ayıklama için test çıktısını saklayın ki her şeyi yeniden çalıştırmak zorunda kalmayın. Ham logları artı basit bir rapor (geçti/kaldı, süre ve en yavaş testler) kaydedin. Bu, özellikle yeniden üretme değişiklikleri birçok dosyayı etkilediğinde regresyonları görmek için faydalıdır.

Gerçek bağımlılıklarla entegrasyon kontrolleri, ama yavaş derlemeler olmadan

Birim testleri kodunuzun izole çalıştığını gösterir. Entegrasyon kontrolleri servisin açılıp gerçek servislerle konuştuğunda hâlâ doğru davrandığını gösterir. Bu, her şeyin bağlı olduğu durumda ortaya çıkan sorunları yakalayan güvenlik ağıdır.

Kodunuzun başlaması veya temel istekleri cevaplaması için gereken bağımlılıklar varsa geçici bağımlılıklar kullanın. İş için oluşturulmuş geçici bir PostgreSQL (ve gerekiyorsa Redis) genellikle yeterlidir. Sürümleri üretime yakın tutun, ama her üretim detayını kopyalamaya çalışmayın.

İyi bir entegrasyon aşaması kasıtlı olarak küçük olmalıdır:

• Servisi production-benzeri env var'larla başlatın (ama test sırları kullanın)
• Bir sağlık kontrolünü doğrulayın (ör. /health 200 döner)
• Bir iki kritik endpoint'i çağırıp durum kodu ve yanıt şeklini doğrulayın
• PostgreSQL'e (ve gerekiyorsa Redis'e) erişebildiğini doğrulayın

API sözleşmesi kontrolleri için, kırılınca en çok zarar verecek endpoint'lere odaklanın. Tam uçtan uca bir suite gerekmez. Birkaç istek/yanıt doğrusu yeterlidir: gerekli alanlar 400 ile reddedilir, doğrulama gereken yerde 401 döner ve mutlu yol isteği 200 ile beklenen JSON anahtarlarını döndürür.

Entegrasyon testlerini sık çalıştırılabilecek kadar hızlı tutmak için kapsamı sınırlayın ve zamanı kontrol edin. Küçük bir veri setiyle tek bir veritabanı tercih edin. Sadece birkaç istek çalıştırın. Zaman aşımı koyun ki takılı bir başlangıç saniyeler içinde hata versin, dakikalar içinde değil.

Eğer arka ucunuzu yeniden üretiyorsanız (örneğin AppMaster ile), bu kontroller ekstra ağırlığa sahiptir. Yeniden üretilmiş servisin hâlâ temiz başlayıp web veya mobil uygulamanızın beklediği API'yi konuştuğunu onaylarlar.

Veritabanı migrasyonları: güvenli sıralama, kapılar ve geri dönüş gerçeği

Migrasyonların nerede çalışacağına karar vererek başlayın. CI'de çalıştırmak hataları erken yakalamak için iyidir ama CI genelde prod'a dokunmamalıdır. Çoğu ekip migrasyonları deploy esnasında (ayrılmış bir adım olarak) veya yeni versiyon başlamadan önce bitmesi gereken ayrı bir "migrate" işi olarak çalıştırır.

Pratik bir kural: CI'de derle ve test et, sonra migrasyonları mümkün olduğunca üretime yakın çalıştırın, üretim kimlik bilgileri ve üretim-benzeri limitlerle. Kubernetes'te bu genellikle bir one-off Job olur. VM'lerde bu, release adımında betiklenmiş bir komut olabilir.

Sıralama insanların beklediğinden daha önemlidir. Zaman damgalı dosyalar (veya ardışık numaralar) kullanın ve "sırasıyla uygula, tam bir kez" kuralını zorunlu kılın. Migrasyonları mümkün olduğunca idempotent yapın ki yeniden deneme çoğaltma yaratmasın veya yarıda çökmesin.

Migrasyon stratejisini basit tutun:

• Önce ekleyici değişiklikleri tercih edin (yeni tablolar/sütunlar, NULL olabilir sütunlar, yeni index'ler).
• Kodun bir sürüm boyunca hem eski hem yeni şemayı idare edebilecek şekilde dağıtın.
• Ancak bundan sonra kısıtlamaları kaldırın veya sıkılaştırın (sütun silme, NOT NULL yapma).
• Uzun süren işlemleri güvenli hale getirin (ör. destekleniyorsa index'leri concurrent oluşturun).

Her şey çalışmadan önce bir güvenlik kapısı ekleyin. Bu veritabanı kilidi olabilir ki aynı anda sadece bir migrasyon çalışsın, artı "zararlı değişiklikler onay olmadan olmasın" gibi bir politika. Örneğin, bir migrasyon DROP TABLE veya DROP COLUMN içeriyorsa onay olmadan pipeline'ı başarısız kılın.

Rollback acı gerçektir: birçok şema değişikliği tersine çevrilemez. Bir sütunu silerseniz veriyi geri getiremezsiniz. Geri dönüşleri ileri çözümler etrafında planlayın: yalnızca gerçekten güvenliyse down migrasyon tutun; değilse yedekler ve ileri migrasyonlarla toparlanmaya güvenin.

Her migrasyonu bir kurtarma planıyla eşleştirin: yarıda kalırsa ne yapacağınız ve uygulamayı geri almak gerekirse ne yapılacağı. Eğer AppMaster ile Go arka uçları üretiyorsanız, migrasyonları yayın sözleşmenizin bir parçası gibi ele alın ki yeniden üretilmiş kod ve şema senkron kalsın.

Paketleme ve konfigürasyon: güvenebileceğiniz artefaktlar

Bir pipeline ancak dağıttığınız şey her zaman test ettiğiniz şey olduğunda öngörülebilir hisseder. Bu, paketlemeye ve konfigürasyona bağlıdır. Derleme çıktısını mühürlü bir artefakt gibi görün ve tüm ortam farklılıklarını onun dışında tutun.

Paketleme genelde iki yoldan birini izler. Kubernetes'e dağıtıyorsanız container imajı varsayılan yoldur çünkü OS katmanını sabitler ve rollout'ları tutarlı kılar. VM'lere ihtiyacınız varsa, bir VM paketi derlenmiş ikiliyi plus çalışma zamanı için gereken küçük dosya setini (ör. CA sertifikaları, şablonlar, statik varlıklar) içeriyorsa aynı güvenilirliği sağlayabilir ve her seferinde aynı şekilde dağıtılmalıdır.

Konfigürasyon harici olmalıdır, ikiliye gömülmemeli. Çoğu ayar için environment variable'ları kullanın (portlar, DB host, feature flag'ler). Değerler uzun veya yapılandırılmışsa sadece config dosyası kullanın ve bunu ortam spesifik tutun. Bir konfigürasyon servisi kullanıyorsanız bunu bir bağımlılık gibi ele alın: kilitli izinler, denetim logları ve net bir fallback planı olsun.

Sırlar geçilmemesi gereken çizgidir. Repoya, imaja veya CI loglarına yazılmazlar. Başlangıçta bağlantı dizelerini yazdırmaktan kaçının. Sırları CI gizli deposunda tutun ve deploy zamanı enjekte edin.

Artefaktları izlenebilir kılmak için her derlemeye kimlik gömün: artefaktları commit SHA ile tag'leyin, build meta verisi (version, commit, build time) bir info endpoint'inde bulundurun ve artefakt tag'ini dağıtım loguna kaydedin. "Ne çalışıyor" sorusuna tek bir komut veya panodan cevap verebilmek kolay olsun.

Eğer Go arka uçlarını AppMaster ile üretiyorsanız, bu disiplin daha da önemli: artefakt isimlendirme ve konfigürasyon kuralları her yayını tekrar üretilebilir kılar.

Kubernetes veya VM'lere sürpriz olmadan dağıtım

Çoğu dağıtım hatası "kötü kod" yüzünden değildir. Ortam uyuşmazlıkları yüzünden olur: farklı konfig, eksik sırlar veya servis başlıyor ama gerçekten hazır değil. Amaç basit: aynı artefaktı her yere dağıtın ve sadece konfigürasyonu değiştirin.

Kubernetes: dağıtımları kontrollü rollout olarak ele alın

Kubernetes'te kontrollü bir rollout hedefleyin. Pod'ları kademeli olarak değiştirin ve platformun trafiği ne zaman göndereceğini ve takılı bir konteyneri ne zaman yeniden başlatacağını bilmesi için readiness ve liveness kontrolleri ekleyin. Kaynak istekleri ve limitleri de önemlidir; büyük bir CI runner'da çalışan bir Go servisi küçük bir node'da OOM-kill alabilir.

Konfigürasyon ve sırları imajın dışında tutun. Her commit için bir imaj derleyin, sonra deploy zamanında ortam-spesifik ayarları enjekte edin (ConfigMaps, Secrets veya sizin secret manager). Böylece staging ve production aynı kodu çalıştırır.

VM'ler: systemd çoğu ihtiyacı karşılar

Virtual machine'lere dağıtıyorsanız, systemd küçük bir orkestratörünüz olabilir. Açık bir çalışma dizini, environment dosyası ve yeniden başlatma politikası olan bir unit dosyası oluşturun. Logları log toplayıcınıza veya journald'e gönderin ki olaylarda SSH aramalarına düşülmesin.

Bir küme olmadan da güvenli rollout'lar yapabilirsiniz. Basit bir blue/green kurulumu işe yarar: iki dizin (veya iki VM) tutun, load balancer'ı değiştirin ve önceki sürümü hızlı rollback için hazır tutun. Canary benzer: küçük bir trafik dilimini yeni sürüme gönderin sonra tam geçiş yapın.

Bir dağıtımı "tamam" saymadan önce her ortamda aynı post-deploy smoke kontrolünü çalıştırın:

• Sağlık endpoint'inin OK döndüğünü ve bağımlılıkların erişilebilir olduğunu doğrulayın
• Küçük gerçek bir işlem çalıştırın (ör. bir test kayıt oluşturup okumak)
• Servis versiyonunun/build ID'nin commit ile eşleştiğini doğrulayın
• Eğer kontrol başarısız olursa geri alın ve uyarı gönderin

Eğer arka uçları yeniden üretiyorsanız (örneğin AppMaster Go backend), bu yaklaşım kararlı kalır: bir kere derle, artefaktı dağıt, ve ortam konfigürasyonu farkları ad-hoc script'ler değil sürüm farklılıkları olarak yönetsin.

Pipeline'ları güvenilmez yapan yaygın hatalar

Çoğu bozuk yayın "kötü kod" yüzünden olmaz. Pipeline her çalıştırıldığında farklı davrandığında olur. Go arka uçları için CI/CD'nin sakin ve öngörülebilir hissetmesi için şu kalıplara dikkat edin.

Sürpriz başarısızlıklara yol açan hata kalıpları

Veritabanı migrasyonlarını hiçbir koruma olmadan her deployda otomatik çalıştırmak klasik bir hatadır. Bir tabloyu kilitleyen bir migrasyon yoğun bir servisi indirebilir. Migrasyonların üretimde onay gerektirmesini, tek seferlik kilit kullanılmasını ve güvenli şekilde yeniden çalıştırılabilir olmasını sağlayın.

latest etiketleri veya sabitlenmemiş base imajlar kullanmak da kolayca gizemli hatalar yaratır. Docker imajlarını ve Go sürümlerini sabitleyin ki derleme ortamınız sürüklenmesin.

Ortamlar arasında "geçici" olarak paylaşılan tek bir veritabanı genelde kalıcı hale gelir ve test verilerinin staging'e sızmasına veya staging betiklerinin production'ı etkilemesine yol açar. Ortam başına ayrı veritabanları (ve kimlik bilgileri) kullanın.

Eksik sağlık ve readiness kontrolleri, bir dağıtımın "başarılı" görünmesine ama servis bozuk olmasına izin verir; trafik erken yönlendirilir. Uygulamanın başlayıp veritabanına bağlanabildiğini ve isteğe hizmet verebildiğini doğrulayan kontroller ekleyin.

Son olarak, sırlar, konfigürasyon ve erişim için belirsiz sahiplik, yayınları tahmin edilemez hale getirir. Sırların nasıl oluşturulacağı, döndürüleceği ve enjekte edileceği konusunda bir sahibi olmalı.

Gerçekçi bir başarısızlık örneği: bir ekip değişiklik merge eder, pipeline deploy eder ve otomatik migrasyon önce çalışır. Staging'de (küçük veri) tamamlanır, ama prod'da (büyük veri) zaman aşımına uğrar. Sabitlenmiş imajlar, ortam ayrımı ve onaylı migrasyon adımı olsaydı, deploy güvenli şekilde duracaktı.

Eğer Go arka uçlarını AppMaster ile üretiyorsanız, bu kurallar daha da önemlidir çünkü yeniden üretim birçok dosyayı aynı anda değiştirebilir. Tahmin edilebilir girdiler ve açık kapılar "büyük" değişikliklerin riskli yayınlara dönüşmesini engeller.

Tahmin edilebilir bir CI/CD kurulumu için hızlı kontrol listesi

Go arka uçları için CI/CD konusunda içgüdü kontrolü olarak bunu kullanın. Her maddede net bir "evet" diyebiliyorsanız, yayınlar daha kolaylaşır.

• Çevreyi kilitleyin, sadece kodu değil. Go sürümünü ve derleme container imajını sabitleyin, yerelde ve CI'de aynı kurulumu kullanın.
• Pipeline'ı 3 basit komuttan çalışır hale getirin. Bir komut derler, bir komut testleri çalıştırır, bir komut deploy edilebilir artefaktı üretir.
• Migrasyonları üretim kodu gibi ele alın. Her migrasyon çalıştırması için log isteyin ve uygulamanız için "geri alma"nın ne anlama geldiğini yazılı hale getirin.
• İzlenebilir değiştirilemez artefaktlar üretin. Bir kere derleyin, commit SHA ile etiketleyin ve ortamlar arasında yeniden derlemeyin.
• Hızla başarısız olan kontrollerle dağıtın. Readiness/liveness sağlık kontrolleri ekleyin ve her dağıtımda kısa bir smoke testi çalıştırın.

Production erişimini sınırlı ve denetlenebilir tutun. CI dağıtımı özel bir servis hesabı ile yapsın, sırlar merkezi olarak yönetilsin ve herhangi bir manuel üretim eylemi net bir iz bıraksın (kim, ne, ne zaman).

Gerçekçi bir örnek ve bu hafta başlayabileceğiniz sonraki adımlar

Dört kişilik küçük bir operasyon ekibi haftada bir yayın yapıyor. Ürün ekibi iş akışlarını sıkça revize ettiği için arka uçlarını sık sık yeniden üretiyorlar. Amaç basit: daha az gece müdahalesi ve kimseyi şaşırtmayan yayınlar.

Tipik bir Cuma değişikliği: customers tablosuna yeni bir alan eklemek (şema değişikliği) ve onu yazan API'yi güncellemek (kod değişikliği). Pipeline bunları tek bir yayın olarak ele alır. Bir artefakt derler, o artefakt üzerinde testleri çalıştırır ve ancak sonra migrasyonları uygulayıp dağıtır. Böylece veritabanı, ona ihtiyaç duyan koddan önce olmaz ve kod, eşleşen şema olmadan dağıtılmaz.

Bir şema değişikliği olduğunda, pipeline bir güvenlik kapısı ekler. Migrasyonun ekleyici olduğundan emin olur (ör. nullable bir sütun gibi) ve riskli işlemleri (sütun silme, büyük tablo yeniden yazma) işaretler. Eğer migrasyon riskliyse, prod'da yayın durur. Ekip ya migrasyonu daha güvenli hale getirir ya da planlı bir pencere ayarlar.

Testler başarısızsa, hiçbir şey ilerlemez. Aynı şekilde migrasyonlar ön-prod ortamında başarısız olursa süreç ilerlemez. Pipeline bir kerelik "sadece bu sefer" diye zorlamamalıdır.

Çoğu ekip için işe yarayan basit bir sonraki adımlar seti:

• Önce tek bir ortamla başlayın (kolayca sıfırlayabileceğiniz bir dev deploy).
• Pipeline her zaman tek versiyonlu bir derlenmiş artefakt üretsin.
• Migrasyonları dev'de otomatik çalıştırın, ama prod'da onay isteyin.
• Dev birkaç hafta stabil kaldıktan sonra staging ekleyin.
• Prod için yeşil testler ve başarılı bir staging deploy doğrulaması gerektiren bir kapı ekleyin.

AppMaster ile arka uçlar üretiyorsanız, yeniden üretimi aynı pipeline aşamalarının içinde tutun: yeniden üret, derle, test et, güvenli bir ortamda migrate yapın, sonra dağıtın. Üretilen kaynağı diğer kaynaklar gibi ele alın. Her yayın, aynı adımlarla etiketlenmiş bir sürümden yeniden üretilebilir olmalıdır.