DevOps ve Sürümler

Bir sürüm kumara dönüşmemelidir.

Sürümler tek tek kişilere ve elle yapılan işlemlere bağlı olduğunda her değişiklik gereksiz yere riskli hale gelir. İzlenebilir derleme ve teslimat süreçleri kurar, bunları kontrollerle ilişkilendirir ve hatalı bir sürümün nasıl güvenle durdurulacağını veya geri alınacağını netleştiririz.

Hizmet kapsamını görüntüleyin Projenizi görüşün

Görev tanımından belgelenmiş devire kadar.

Bu hizmet ne zaman yardımcı olur

DevOps ve Sürümler: bize verdiğiniz görev.

Manuel dağıtımları geride bırakmak
Derlemeleri ve onayları izlenebilir hale getirmek
Geliştirme ve işletimi daha yakından bütünleştirmek

Kod, altyapı, yapılandırma ve onaylar birbiriyle uyumlu olduğunda güvenilir sürümler ortaya çıkar. Mevcut teslimat yolunuzu inceler, elle yapılan işlemlerden kaynaklanan hata kaynaklarını ortadan kaldırır ve normal değişiklikler ile acil durumlar için şeffaf bir süreç kurarız. Ekibiniz hangi sürümün çalıştığını, nasıl kontrol edildiğini ve sorun durumunda hangi geri dönüş yolunun kullanılabilir olduğunu görebilmelidir.

Görev kapsamına neler dahil olabilir

Mevcut derleme, onay ve teslimat sürecinin analizi
Derlemelerin, kontrollerin ve sürümlenmiş artefaktların otomasyonu
Erişimlerin, gizli bilgilerin ve ortam yapılandırmasının ayrılması
Uyumlu veritabanı değişikliklerinin ve kontrollü yaygınlaştırmaların planlanması
Hatalı sürümlerin iptalinin, yeniden başlatılmasının ve geri alınmasının test edilmesi

Somut kapsamı, kabul noktalarını ve katkınızı teklifte belirleriz.

Genel tablo tek bakışta

Her değişiklik kontrollü bir yol gerektirir.

01
Kod
Değişikliği ve incelemeyi izlenebilir kılmak
02
Derleme
Sürümlü bir artefakt oluşturmak ve doğrulamak
03
Yaygınlaştırma
Onayı ve teslimi yönetmek
04
Gözlem
Etkiyi ölçmek ve hatalara müdahale etmek

Planlama, uygulama ve kararlar

DevOps ve Sürümler için önemli olanlar.

Bir pipeline, bir dağıtım betiğinden daha fazlasıdır

Değişiklikten üretime kadar olan yolu ele alırız: kaynak kod, bağımlılıklar, derleme, testler, artefaktlar ve onaylar. Her adımın tanımlı girdileri ve izlenebilir sonuçları olmalıdır. Amaç, aynı kontrol edilmiş yazılım sürümünü her ortam için yeniden bir araya getirmek yerine, ortamlar arasında kontrollü biçimde taşımaktır.

Pipeline'ın yetkileri ve erişim bilgileri yalnızca gerekli görevlerle sınırlandırılır. Çalıştırma ortamlarının ve bağımlılıkların güncel tutulması ve izlenebilir bir kökene sahip olması gerekir. Hangi kontrollerin bir sürümü engelleyeceği açıkça kararlaştırılır ve gerçek değişiklikler üzerinde test edilir.

Ortamları ve yapılandırmayı yönetilebilir tutmak

Test ve üretim ortamları arasındaki farklar, ancak canlıya geçişte fark edilen hatalara yol açar. Yapılandırmayı, gizli bilgileri ve altyapı tanımlarını, sapmalar görünür hale gelecek şekilde düzenleriz. Konteynerler bu konuda yardımcı olabilir, ancak net sorumlulukların veya uygun bir işletim platformunun yerini tutmaz.

Öncelik, mevcut araçlarınızla entegrasyondur. Bir ekip kendi pipeline'ını anlamalı ve hata durumunda harekete geçebilmelidir. Bu nedenle yalnızca başarı yolunu değil, başarısız derlemeleri, engellenen onayları ve bir kesintiden sonra yeniden başlatmayı da belgeleriz.

Yaygınlaştırma, izleme ve geri dönüş yolunu birlikte ele almak

Yeni sürümler kademeli olarak veya üzerinde anlaşılmış bir bakım penceresinde devreye alınabilir. Hangi seçeneğin uygun olduğu uygulamaya, veritabanına ve altyapıya bağlıdır. Onaydan önce hangi sinyallerin bir iptali tetikleyeceğini belirleriz: örneğin artan hata oranları veya bozulan bir temel süreç.

Bir uygulamanın geri alınması, verilerinin de otomatik olarak geri alınması anlamına gelmez. Bu nedenle veritabanı değişiklikleri, arka plan görevleri ve dış mesajlar da geri dönüş yoluna dahil edilmelidir. Üzerinde anlaşılan stratejiyi test eder ve ne zaman geri alma yerine düzeltici, ileri yönlü bir değişikliğin gerekli olduğunu kayıt altına alırız.

Araçlar göreve göre seçilir

Ortamınıza uygun teknoloji.

Git
CI/CD
Konteyner
Infrastructure as Code

Seçim, mevcut sistemlere, ekibinize ve sonraki işletime göre yapılır. Her proje burada sayılan teknolojilerin tümüne ihtiyaç duymaz.

İş birimi sorumluları ve teknik ekipler için

Uygulamanın arkasındaki kararlar.

Derleme kökeni, bağımlılıklar ve erişim sınırları

Bir pipeline, üçüncü taraf paketleri, derleme araçlarını ve çoğu zaman geniş kapsamlı erişimleri işler. Bu güven zincirini ele alır ve güvenilmeyen değişikliklerin kontrolünü üretim yetkisine sahip adımlardan ayırırız. Çalıştırma ortamlarının sınırlı hakları ve izlenebilir bir başlangıç durumu olmalıdır. Erişim bilgileri kontrollü şekilde sağlanır; bunlar ne artefaktlara ne de derleme kayıtlarına girmemelidir.

Yayınlanan bir artefakt için kaynak kod sürümü, bağımlılıklar ve tamamlanan kontroller izlenebilir olmalıdır. Bir bileşen envanteri, bilinen güvenlik açıklarının sonradan değerlendirilmesini destekler; bu açıkların istismar edilebilirliğini otomatik olarak doğrulamaz. İmzalar ve köken kanıtları yalnızca alıcı ortam da bunları kontrol ettiğinde işe yarar. Bu nedenle oluşturma, saklama ve kontrol adımlarını birlikte belirler; engellenen bileşenlerin veya güvenliği ihlal edilmiş erişimlerin nasıl ele alınacağını kararlaştırırız.

Veritabanı şemalarını ve uygulama sürümlerini birlikte teslim etmek

Kademeli bir yaygınlaştırmada eski ve yeni uygulama sürümleri aynı anda etkin olabilir. Hemen kaldırılan bir veritabanı sütunu veya değiştirilen bir mesaj biçimi, eski sürümü bozabilir. Bu nedenle uyumlu ara durumlar planlarız: önce yeni yapılar eklenir, veriler kontrollü biçimde aktarılır, çağıran sistemler yeni yapıya geçirilir ve ancak bundan sonra artık gerekmeyen kısımlar kaldırılır. Arka plan görevleri ve dış tüketiciler de bu değerlendirmeye dahildir.

Özellik anahtarları, bir işlevin dağıtımını etkinleştirilmesinden ayırabilir. Ancak bunların net bir sorumlusu, test varyantları ve planlanmış bir sona erme tarihi olmalıdır; aksi halde olası durum sayısını kalıcı olarak artırırlar. Her onay için hangi sürümlerin birlikte çalıştığı ve uygulamanın geri alınmasına hâlâ izin verilip verilmediği kayıt altına alınır. Geri döndürülemez veri değişiklikleri, çalıştırılabilir artefaktın basitçe değiştirilmesinden farklı bir strateji gerektirir.

Sürüm sinyalleri ve geliştirme akışındaki iyileştirmeler

Teknik açıdan başarılı bir teslimat, henüz başarılı bir sürüm anlamına gelmez. Canlıya geçişin ardından seçilmiş temel işlemleri, hata oranlarını ve yanıt sürelerini izleriz. Kademeli bir yaygınlaştırma, etkilenen kullanıcı grubunu sınırlayabilir; ancak bu, uygun bir mimari ve anlamlı ölçüm noktaları gerektirir. İptal eşikleri ve sorumlu kişiler değişiklikten önce belirlenir, böylece zaman baskısı altında ölçütler üzerine tartışmak gerekmez.

Süreci iyileştirmek için incelemelere yönelik bekleme sürelerini, pipeline süresini, sık yaşanan iptalleri ve başarısız değişikliklerden sonra toparlanma eforunu değerlendiririz. Bu bilgiler tek tek geliştiricileri sıralamaya değil, genel sürecin iyileştirilmesine hizmet eder. Onay süreci ardından günlerce belirsiz kalıyorsa kısa bir derleme süresinin pek faydası olmaz. Bu nedenle önlemler geliştirme, güvenlik ve işletim ile birlikte önceliklendirilir ve gerçek darboğazlara göre gözden geçirilir.

Anlaşılır çalışma sonuçları

Elinize geçecek sonuçlar.

Sonuç 01

Sürümlenmiş derleme ve dağıtım hattı

Sonuç 02

Yetkilendirme ve yapılandırma konsepti

Sonuç 03

Test edilmiş bir geri dönüş yolu içeren sürüm kontrol listesi

Örnek proje akışı

Çalışma bu şekilde ilerleyebilir.

Bir ürün ekibi şimdiye kadar geceleri elle teslimat yapıyordu. Yeni pipeline, sürümlenmiş bir artefakt oluşturur, temel süreçleri kontrol eder ve üretim ortamına yaygınlaştırmadan önce onay talep eder. Teslimatın ardından tanımlanmış işletim ölçütleri izlenir.

Açıklayıcı senaryo, bir müşteri referansı veya sonuç garantisi değildir.

Başlarken yardımcı olanlar

Kaynak kod yönetimi ve mevcut sürüm süreci
Kullanılabilir test ve üretim ortamları
İşletimden sorumlu kişiler ile onay ve erişim kuralları

Eksik belgeler bir engel değildir. Hangi bilgilerin önce temin edilmesi gerektiğini birlikte netleştiririz.

Projeniz ayrıntılarıyla

Değişiklikleri tekrarlanabilir şekilde işletime kadar taşımak.

Derlemeyi (build), testi, onayı ve dağıtımı birbirine bağlayan yayınlama süreçleri geliştiririz. Amaç, kaynak kodundan fiilen çalışan sürüme kadar izlenebilir bir yoldur.

Bir artefaktı ortamlar arasında taşımak

Her ortam birbirinden bağımsız olarak yeniden derlenirse, aynı sürüm etiketine rağmen farklılıklar sızabilir. Test edilen sürümün izlenebilir şekilde dağıtılması için sürümlenmiş artefaktlar ve ayrı yapılandırma planlarız. Bağımlılıklar ve paket kaynaklarına erişim, derleme sürecine dahil edilir.

Gizli bilgiler kaynak kodunda veya herkese açık derleme çıktılarında yer almamalıdır. Üzerinde anlaşılan erişim bilgisi yönetimini entegre eder ve pipeline'ın yetkilerini sınırlarız. Bir yayınlamanın yalnızca kendi somut adımı için gereken yetkilere sahip olması gerekir.

Veritabanı değişikliklerini ve geri dönüş yolunu birlikte planlamak

Uygulamanın geri alınması (rollback), zaten yürütülmüş bir veri geçişini otomatik olarak geri almaz. Bu nedenle eski ve yeni uygulama sürümleri ile veri durumları arasındaki uyumluluğu kontrol ederiz. Uygun kademeli değişiklikler, eski alanlar kaldırılmadan önce yeni alanların eklenmesine olanak tanıyabilir.

Dağıtımdan sonra yalnızca süreç durumunu değil, önemli işlevleri ve işletim göstergelerini de kontrol ederiz. Sınırlı yaygınlaştırma, özellik anahtarları veya planlı bir geri dönüş yolu, riske göre seçilir. Devir, bir sürümün ne zaman durdurulması gerektiğini ve devam etme veya geri alma kararını kimin vereceğini açıklar.

Örnek proje senaryosu

Hizmetin günlük işlere katkısı.

Örnek: Bir sürüm, ileride zorunlu hale gelecek yeni bir veri alanı ekler. Önce depolama uyumlu şekilde genişletilir, ardından mevcut veriler tamamlanır ve son olarak yeni iş kuralı etkinleştirilir. Her aşamanın kendi testleri ve uygun bir geri dönüş yolu vardır.

Bu örnek olası bir süreci açıklar ve bir müşteri referansı değildir.

Hizmet almadan önce

DevOps ve Sürümler hakkında sorularınız.

Bunun için Kubernetes kullanmamız gerekir mi?

Hayır. Güvenilir bir pipeline sanal makineler, klasik sunucular veya yönetilen platform hizmetleri için de çalışır. İşletim platformunu, gereksinimlerinize ve ekibinizin yetkinliklerine göre seçeriz. Ek karmaşıklığın gerekçelendirilebilir bir faydası olmalıdır.

Onay olmadan otomatik dağıtımlar gerekli midir?

Hayır. Otomasyon teknik adımları üstlenebilir; üretim onayları ise bilinçli olarak sorumlu kişilerde kalır. Hangi değişikliklerin otomatik olarak devam edeceğini ve hangilerinin ek bir kontrol gerektirdiğini birlikte kararlaştırırız. Acil durum değişiklikleri de belgelenmiş bir süreç gerektirir.

Mevcut pipeline'lar iyileştirilebilir mi?

Evet. Bekleme sürelerini, hataya açık adımları, yetkilendirmeleri ve kalite sinyallerini inceleriz. Bundan önceliklendirilmiş bir iyileştirme listesi ortaya çıkar. Çoğu zaman net artefakt sürümleri, daha iyi test verileri ve test edilmiş bir geri dönüş yolu, araçların tamamen değiştirilmesinden daha değerlidir.

Sonraki adım

Bugün nerede tıkandığınızı bize anlatın.

Başlangıç için uygulamanızın, sorunun ve hedefinizin kısa bir açıklaması yeterlidir. Seçtiğiniz hizmet iletişim talebinize aktarılır.

Bu hizmeti talep edin

Menü

Bir sürüm kumara dönüşmemelidir.