Devreye alma yolu ile yayın yaşam döngüsünü hızlandırın: Bölüm 1 – IBM Blogu

Birçok kuruluş için buluta yolculuk, teknik borç maliyetlerini azaltır ve CapEx'ten OpEx'e hedefler. Bu içerir yeniden mimari için microservices, kaldır ve değiştir, yeniden platform oluşturma, yeniden düzenleme, değiştirme ve daha fazlası. Gibi uygulamalar DevOps, Bulut yerel, sunucusuz ve site güvenilirliği mühendisliği (SRE) Olgunlaştıkça, odak noktası önemli düzeylerde otomasyona, hıza, çevikliğe ve BT ile iş uyumuna doğru kayıyor (kurumsal BT'nin mühendislik organizasyonlarına dönüşmesine yardımcı oluyor).

Birçok kuruluş, bulut yolculuklarından gerçek değer elde etmekte zorlanıyor ve aşırı harcama yapmaya devam edebilir. Çoklu analistler İşletmelerin %90'ından fazlasının, çoğunlukla önemli getiriler elde etmeden, bulutta aşırı harcama yapmaya devam ettiğini bildirdi.

Değerin gerçek özü, işletme ve BT'nin yüksek hızda yeni yetenekler oluşturmak için işbirliği yapmasıyla ortaya çıkar ve bu da daha fazla geliştirici üretkenliği ve pazara sunma hızı sağlar. Bu hedefler bir gerektirir hedef işletim modeli. Uygulamaların buluta hızla dağıtılması yalnızca sürekli entegrasyon, dağıtım ve test (CI/CD/CT) ile geliştirmenin hızlandırılmasını gerektirmez, aynı zamanda yönetişim riski ve uyumluluk (GRC), değişiklik yönetimi gibi birden fazla grubu içeren tedarik zinciri yaşam döngüsünün hızlandırılmasını da gerektirir. , operasyonlar, esneklik ve güvenilirlik. Kuruluşlar sürekli olarak ürün ekiplerinin konseptten dağıtıma her zamankinden daha hızlı geçmesini sağlayacak yollar arıyor.

Önce otomasyon ve DevSecOps liderliğindeki yaklaşım

Kuruluşlar, hız ve ölçeğe uygun yeni yaşam döngüsü ve dağıtım modellerini dikkate almak yerine, genellikle mevcut uygulama tedarik zinciri süreçlerindeki bulut dönüşüm öğelerini yeniliyor. Uygulama yaşam döngüsünü otomasyon öncelikli bir yaklaşımla yeniden tasarlayan kuruluşlar, bulut dönüşümünün potansiyelini gerçekleştiren mühendislik odaklı ürün yaşam döngüsünü hızlandırmayı teşvik ediyor. Örnekler şunları içerir:

• Mimari ve tasarım sürecini standartlaştıran desen tabanlı mimari (ekiplerin desenleri ve teknolojiyi seçme veya yeni desenleri birlikte oluşturma özerkliği vardır).
• Güvenlik ve uyumluluk boyutlarına hitap eden ve bu gereksinimlerin izlenebilirliğini sağlayan modeller.
• Birden fazla kesişen kaygının kodlanmasına yardımcı olan kod olarak modeller (bu aynı zamanda kalıpların olgunluğuna ilişkin iç kaynak modelini de destekler ve yeniden kullanılabilirliği teşvik eder).
• Yaşam döngüsü boyunca kullanılabilecek DevOps işlem hattı odaklı etkinlikler.
• Güvenlik ve uyumluluk incelemeleri için gereken belirli verilerin otomatik olarak oluşturulması.
• Sınırlı veya hiç manuel müdahale olmadan operasyonel hazırlık incelemeleri.

İşletmeler bulut yerelini ve her şeyi kod olarak benimsedikçe, koddan üretime olan yolculuk, müşterilere değer sunmanın kritik bir yönü haline geldi. Bu karmaşık süreç genellikle “konuşlandırma yolu", bir kuruluşun yazılımı verimli, güvenilir ve uygun ölçekte sunma becerisini önemli ölçüde etkileyebilecek bir dizi karmaşık adımı ve kararı kapsar. Mimari, tasarım, kod geliştirme, testten dağıtım ve izlemeye kadar dağıtım yolundaki her aşama benzersiz zorluklar ve fırsatlar sunar. IBM®, günümüzde mevcut olan karmaşıklıkların üstesinden gelirken, kesintisiz ve etkili bir devreye alma yoluna ulaşmanıza yönelik stratejileri ve hedef durum modunu ortaya çıkarmanıza yardımcı olmayı amaçlamaktadır.

Kuruluşlara yazılım teslim hatlarını düzene koyma, pazara sunma süresini kısaltma, yazılım kalitesini artırma ve üretim ortamlarında sağlam operasyonlar sağlama konusunda güç veren en iyi uygulamalar, araçlar ve metodolojilerin tümü incelenecektir.

Bu serinin ikinci yazısı Sürekli gelişen kurumsal bulut tabanlı yazılım geliştirme ortamında, kuruluşların yazılım tedarik zinciri yaşam döngülerini hızlandırmalarına yardımcı olacak bir olgunluk modeli ve yapı taşları sağlar.

Dağıtım yolu: Mevcut görünüm ve zorluklar

Aşağıdaki şema, tipik kapılarla kurumsal yazılım geliştirme yaşam döngüsünün (SDLC) görünümünü özetlemektedir. Akış kendini açıklayıcı olsa da önemli olan, yazılım tedarik zinciri sürecinin bunu şelale ve aralıklı çevik modellerin bir kombinasyonu haline getiren çeşitli yönlerinin olduğunu anlamaktır. Buradaki zorluk, bir uygulamanın (veya bunun bir yinelemesinin) inşa-dağıtım zaman çizelgesinin, genellikle manuel olarak kalan birçok ilk ve son kilometre faaliyetinden etkilenmesidir.

SDLC'nin geleneksel doğasıyla ilgili temel zorluklar şunlardır:

1. Geliştirme aşamasına geçmek için mimari ve tasarım aşamasında geliştirme öncesi bekleme süresi 4-8 haftadır. Bunun nedeni:
   • Gizlilik endişeleri, veri sınıflandırması, iş sürekliliği ve mevzuata uygunluk dahil olmak üzere olumsuz iş etkilerinin oluşmamasını sağlamak için birden fazla ilk adım incelemesi (ve bunların çoğu manueldir).
   • Geliştirme döngülerindeki çevik ilkelere rağmen (örneğin, yalnızca tam tasarım onayından sonra ortamın sağlanması) sıralı yürütme gerektiren, şelale veya yarı çevik kalan, kuruluş çapında SDLC süreçleri.
   • “Benzersiz” olarak algılanan uygulamalar, derinlemesine incelemeye ve müdahalelere tabi olup hızlandırma fırsatları sınırlıdır.
   • Böyle bir standardizasyon gibi tutarlı bir çabanın ve değişim aracılı yönlendirmenin eksikliğinden dolayı kalıplara dayalı mimariyi ve geliştirmeyi kurumsallaştırmadaki zorluklar.
   • Genellikle manuel veya yarı manuel süreçleri içeren güvenlik kontrollerine ve yönergelerine bağlılıkla, geliştirme hızını etkileyen bir güvenlik kültürü.
2. Aşağıdaki nedenlerden dolayı ortamın ve CI/CD/CT araç entegrasyonunun sağlanması için geliştirme bekleme süresi:
   • Manuel veya yarı otomatik ortam sağlama.
   • Desenler (kağıt üzerinde) yalnızca kural koyucu rehberlik amaçlıdır.
   • Bir araya getirilmesi çaba gerektiren parçalı DevOps araçları.
3. Geliştirme sonrası (son mil) canlıya geçişten önceki bekleme süresi aşağıdaki nedenlerden dolayı kolayca 6-8 hafta veya daha fazladır:
   • Standart SAST/SCA/DAST'ın ötesinde güvenlik ve uyumluluk incelemelerinden geçmek için manuel kanıt toplama (güvenlik yapılandırması, 2. gün kontrolleri, etiketleme ve daha fazlası gibi).
   • Operasyon ve dayanıklılık incelemeleri için manuel kanıt toplama (bulut operasyonlarını ve iş sürekliliğini desteklemek gibi).
   • BT hizmetini ve olay yönetimini ve çözümünü desteklemek için hizmet geçişi incelemeleri.

Dağıtım yolu: Hedef durum

Hedef durumu dağıtmanın yolu, darboğazları en aza indiren ve yazılım tedarik zinciri dönüşümünü hızlandıran akıcı ve verimli bir süreç gerektirir. Bu ideal durumda, dağıtım yolu, çevik ve DevOps ilkelerini takip ederek tasarımın (ilk kilometre) yanı sıra geliştirme, test, platform mühendisliği ve dağıtım aşamalarının (son kilometre) kusursuz bir entegrasyonuyla karakterize edilir. Bu, üretim ortamlarında gerekli (otomasyon odaklı) doğrulamalarla kod değişikliklerinin hızla ve otomatik olarak dağıtılmasını hızlandırmaya yardımcı olur.

IBM'in hedef durum vizyonu, güvenlik kontrollerini ve uyumluluk doğrulamasını CI/CD/CT hattına entegre ederek güvenliğe ve uyumluluğa öncelik vererek güvenlik açıklarının erken tespitine ve çözülmesine olanak tanır. Bu vizyon, ortak bir sorumluluk modeli aracılığıyla geliştirme, operasyonlar, güvenilirlik ve güvenlik ekipleri arasındaki işbirliğini vurgular. Ayrıca daha fazla iyileştirme için içgörü toplamak amacıyla sürekli izleme ve geri bildirim döngüleri oluşturur. Sonuçta hedef durum, yazılım güncellemelerini ve yeni özellikleri son kullanıcılara hızlı bir şekilde, minimum manuel müdahaleyle ve tüm kurumsal paydaşlar için yüksek derecede güvenle sunmayı amaçlamaktadır.

Aşağıdaki diyagram, bulutta yerel SDLC modelinin benimsenmesine yardımcı olan dağıtım yolunun potansiyel hedef görünümünü göstermektedir.

Bulutta yerel SDLC modelinin temel unsurları şunları içerir:

• Kuruluş çapında kurumsallaştırılmış model odaklı mimari ve tasarım.
• Güvenlik, uyumluluk, dayanıklılık ve diğer kurumsal politikaların (kod olarak) temel gereksinimlerini içeren modeller.
• Desen olarak hızlandırılan ve çözümü tanımlamak için kullanılan güvenlik ve uyumluluk incelemeleri.
• Ortamların, işlem hatlarının ve hizmet yapılandırmasının (platform mühendisliği kurumsal kataloğu aracılığıyla yönlendirilen) oluşturulması dahil olmak üzere temel geliştirme.
• Yaşam döngüsünü dağıtma yolundaki tüm etkinliklere bağlantılar oluşturan CI/CD/CT hattı.
• Platform mühendisliği, platform politikaları olarak gömülü tüm kurumsal politikalarla (şifreleme gibi) platformları ve hizmetleri oluşturur, yapılandırır ve yönetir.
• Güvenlik ve uyumluluk araçları (örneğin, güvenlik açığı taramaları veya politika kontrolleri) ve işlem hatlarına entegre edilen veya self servis olarak sunulan otomasyon.
• Manuel müdahale olmadan çeşitli incelemeler için yüksek düzeyde veri (günlüklerden, araç çıktılarından ve kod tarama içgörülerinden) oluşturulması.
• İş yığınından dağıtım sürüm notlarına ve değişiklik etkisine kadar izlenebilirlik.
• Müdahaleler yalnızca istisnalar dışındadır.

Netlik, hesap verebilirlik ve izlenebilirlik yoluyla hızlanmayı artırmanın yolu

Kuruluşlar, dağıtım için yapılandırılmış bir yol tanımlayarak, tedarik zinciri yaşam döngüsündeki adımları standartlaştırarak her aşamanın izlenebilir ve denetlenebilir olmasını sağlayabilir. Bu, paydaşların ilk tasarımdan dağıtıma kadar farklı aşamalardaki ilerlemeyi izlemesine olanak tanıyarak programın durumuna ilişkin gerçek zamanlı görünürlük sağlar. Dağıtım yolunun her aşamasında sahiplik atamak, ekip üyelerinin çıktılarından sorumlu olmasını sağlar, katkıları ve değişiklikleri izlemeyi kolaylaştırır ve doğru düzeyde müdahaleyle sorunların çözümünü hızlandırır. Dağıtım yolundaki izlenebilirlik, veriye dayalı içgörüler sağlayarak süreçlerin iyileştirilmesine ve gelecekteki programlarda verimliliğin artırılmasına yardımcı olur. İyi belgelenmiş bir dağıtım yolu, endüstri düzenlemelerine uyumu destekler ve sürecin her bir parçası açıkça kaydedildiğinden ve geri alınabildiğinden raporlamayı basitleştirir.

Bölüm 2'yi Okuyun: Olgunluk modelini ve gerçekleştirme yaklaşımını keşfetme