GitLab ile kendi yolunuzu çizin
Sosyal medyada paylaşın
GitLab ile kendi yolunuzu çizin
Val Naipaul
23rd Ocak, 2024
10 dakikalık okuma
Val Naipaul
23rd Ocak, 2024
10 dakikalık okuma
Şu bölüme atla:
Şu bölüme atla:
Yaygın yaklaşımlar
Önerilen yaklaşım
Peki ya Otomatik DevOps?
Platform tarafında ve/veya DevOps'ta çalışıyorsanız ve kendinizi bir GitLab (SaaS veya kendi kendini yöneten) geçişi veya uygulaması ile karşı karşıya bulursanız GitLab'in çok fazla özelliği olduğunu fark edebilirsiniz.
Gerçekten de temel VCS, CI/CD pipeline, paket yönetimi, yazılım oluşturma analizi, planlama özellikleri vb. ile ihtiyaçlarınızı geniş ve ayrıntılı bir şekilde karşılayabilen kapsamlı bir platformdur.
Ancak başarılı olmak için tüm özelliklerini uygulamanız gerekiyor mu? Özellikle cloud'da dağıtılan GitLab Runner'lar kârlılığınızı etkilediğinde.
Bu blog yazısında, paydaşlara daha erken değer sunan ve ekiplerin GitLab ile tam gaz gitmek zorunda kalmadan kendi koşullarına göre etkileşim kurmalarına yardımcı olan bir GitLab geçişi veya uygulaması planlamaya yönelik bir yaklaşım öneriyoruz.
Yaygın yaklaşımlar
GitLab geçişi veya uygulaması için önerdiğimiz yaklaşıma geçmeden önce, bağlama uygun bazı yaygın yaklaşımları ele alalım. Bunlardan biri sizin durumunuza daha uygun olabilir.
Büyük patlama (migration)
Büyük patlama yaklaşımı analiz, yapılandırma, ETL (Extract, Transform, Load) ve doğrulama döngülerini içerir. Temsilî kaynak içeriği kullanarak başlayıp kademeli olarak tüm kaynak içeriği kullanımına geçerek finalde "büyük patlama" geçişiyle sonuçlanabilir.
Başlıca avantajı, dâhil olan herkes için net bir geçiş noktasıdır ancak değer bu geçiş noktasına ulaşılana kadar ertelenir. Bu yaklaşımın yinelemeli doğası, geçiş yinelemelerinde ek yükler olarak ortaya çıkararak yapısal verimsizlikler de yaratabilir.
Artımlı, aşamalı (migration)
Artımlı bir yaklaşımda, kaynak içerik bölümlere ayrılır ve aşamalı olarak geçirilir. Bu süreç, yine de büyük patlama yaklaşımında olduğu gibi yinelemeli bir şekilde ancak daha yönetilebilir yinelemelerle yürütülebilir.
Aşamalı bir yaklaşımda, hedef ortamın özellikleri aşamalar hâlinde etkinleştirilir ve her aşama öncekilerin üzerine inşa edilir.
Bu yaklaşımların ikisinde de değer, büyük patlama yönteminden daha erken elde edilir ancak hem kaynak hem de hedef platformlar, ilk artımdan veya aşamadan sonuncusuna kadar uzun bir süre boyunca canlı kalır, bu da külfetli ve kafa karıştırıcı olabilir.
Self servis ile platform mühendisliği (migration/implementation)
Platform mühendisliği self-servis yaklaşımıyla uzmanlardan oluşan bir ekip, geliştirme ekiplerinin GitLab'ı bağımsız olarak kullanabilmeleri için gerekli altyapıyı (yapılandırma, otomasyon, korumalar) hazırlar. Bu, onaylanmış ve kabul edilmiş şablonları kullanarak içeriğin taşınmasını, yeni projelerin başlatılmasını veya önyükleme yapılmasını içerebilir.
Bu yaklaşım, paylaşılan bilgi ve ekip disiplinine dayanarak dâhilî bir geliştirici platformu (IDP) gibi standartlaştırılmış bir geliştirici deneyimi için bir çerçeve olmadan çalışabilirken, bir çerçeve mevcut olduğunda gerçekten mükemmeldir. IDP seçenekleri şunlardır: Backstage, Compass, Venue.sh ve GitLab'in kendisi.
Önerilen yaklaşım
GitLab geçişi veya uygulamasına yönelik değer öncelikli, shift left yaklaşım
Önerdiğimiz yaklaşım, paydaşlara değer sunmaya öncelik verirken, kullanıcılar ve GitLab arasında sağlam bir etkileşim sağlamak için uygulama sürecini hızlandırıyor.
Örneğin, ekipleriniz iş birliği için GitLab Review Appskullanmaya istekliyse (ve potansiyel olarak altyapı maliyetlerini düşürmek için), geçici bir çözüm olarak haricî depo entegrasyonlarını düşünebilirsiniz. Bu, Git depoları tamamentaşınmadan veya hatta taşıma işlemi başlamadan önce Review Appskullanmanıza olanak tanır!
Sunumu hızlandırmak bazı alanlarda mantıklı olsa da, mevcut bir planlama aracındaki sorunları GitLab'a otomatik olarak yansıtmak gibi diğer alanlarda daha yavaş bir yaklaşım benimsemek faydalı olabilir. Ekip Planlaması. Bu, geliştiricilerin minimum kesinti ile kendi hızlarında geçiş yapmalarını sağlayacaktır.
Bu arada, normalde platform uygulaması/geçişi bağlamında kullanılmasa da, "shift left" düşüncesi gerçekten bu yaklaşımın merkezinde yer almaktadır. Planı, olağan platform uygulaması ve geçiş hususlarına ek olarak çeşitli paydaşlara ve onların endişelerine (ör. maliyet, geliştirici deneyimi) hitap edecek şekilde genişleteceksiniz.
Genel ilkeler
Bu yaklaşım, önce GitLab ile başarı kriterlerinizi belirlemenizi, ardından her birini üç özellik açısından önceliklendirmenizi gerektirir:
- Önem/aciliyet veya "boyut"
- Uygulama maliyeti
- Katılım (gerekli insan sermayesi, uzmanlık ve bağlılık)
Belirlenen önceliklere göre geçişe veya uygulamaya devam etmek, ekiplerin GitLab ile etkileşimini teşvik ederken paydaşlara daha erken değer sunar.
Başarı kriterlerinizi belirleyin.
Başarı hangi kriterlere göre ölçülecek (yalnızca ekibiniz tarafından değil, tüm paydaşlar tarafından)? En az iki, en fazla beş kriter belirleyin.
İyi bilinen DORA metrikleri gibi kriterleriniz DevOps ile ilişkilendirilebilir. Ancak unutmayın, bu sizin ortamınızla ilgilidir: güvenlik ve uyumluluk endişeleri baskın mı? Testler konusunda titizlik ve şeffaflığa yönelik belirgin bir ilgi var mı?
Başarı kriterlerinize öncelik verin ve GitLab özellikleriyle eşleştirin
Her başarı kriteri için:
- En az için 1 kullanarak göreceli boyutu temsil edecek bir sayı atayın (daha önemli/acil kriterler daha yüksek önceliklidir). Daha iyi göreceli değerleri temsil edecek kriterler arasında boşluklar bırakın, ör. 1, 2, 3, 5, 10.
- En fazla için 1 kullanarak (düşük uygulama maliyetlerine sahip kriterler daha yüksek önceliklidir) mevcut durumdan hedef duruma (kritere göre) geçmek için göreceli uygulama maliyetini (araçlar ve süreçler dâhil) temsil edecek bir sayı atayın. Hedef durum için kısa ila orta vadeli düşünün ancak biraz iddialı olmayı unutmayın, bu hedefe ulaşmak önemli bir başarı gibi hissettirmelidir.
- En az için 1 kullanarak göreceli katılımı temsil edecek bir sayı atayın (en yüksek katılıma sahip kriterler daha yüksek önceliği hak eder). Hedeflerinize ulaşmak için gereken insan sermayesine, uzmanlığa ve bağlılığa sahip olup olmadığınızı kendinize sorun.
- Şimdi her bir kriteri, büyüklüğü, maliyeti ve katılım düzeyine göre hesaplayarak diğerlerine göre sıralayın. Daha yüksek önceliklere daha büyük sayılar atanmasıyla sonuçlanacaktır.
- Yardımcı olabilecek (veya engelleyebilecek) ilgili GitLab özelliklerini tanımlayın ve nasıl yapılacağını açıklayın. Kapsayıcı olmakla başlayın ve ilgili tüm kriterleri göz önünde bulundurun. Listeyi gerektiğinde, muhtemelen paydaşlarla istişare ederek iyileştirin.
Anlaşıldı!
Örneğin:
Başarı kriterleri (İş birliği)
- Boyut: 5
- Maliyet: 4
- Katılım: 4
- Değer: 80
İlgili GitLab özellikleri
- Minimumgrup hiyerarşisiyleInnerSourcing
- Hassas içerikleri depoların dışına taşıyın ve InnerSourcing'idesteklemek ve güvenliği MinimumSecret Detection'ı etkinleştirin
- Şablonlar, CI/CD bileşenleri ve CD/CI kataloğu aracılığıyla işlem hattı yeniden kullanımı ve CI/CD Kataloğu
Başarı kriterleri (İşletme maliyetleri)
- Boyut: 1
- Maliyet: 3
- Katılım: 3
- Değer: 9
İlgili GitLab özellikleri
- Review AppsReview Apps
Başarı kriterleri (İşletme maliyetleri)
- Boyut: 3
- Maliyet: 1
- Katılım: 1
- Değer: 3
İlgili GitLab özellikleri
Peki ya Otomatik DevOps?
Peki ya Otomatik DevOps?? Farklı dallanma modellerini, geliştirme metodolojilerini ve geçmişleri, esasen tek tip olmayan içeriği barındırmıyor mu? Bu öncelik belirleme işlemini atlayıp her şeyi Otomatik DevOps ile aynı anda (cloud işletme maliyetlerini bir kenara koyarak) sunamaz mıyız?
Kesinlikle hayır, bir dizi seçilmiş işlem hattı işi olan Otomatik DevOps, DevSecOps içiniyi bir model ve başlangıç noktası olarak hizmet eder.Özelleştirmeye elverişlidir ve kendi yeniden kullanılabilirCI/CD bileşenlerinize ve CI/CD bileşenleri ve CI/CD Kataloğudaha ziyade bir "model-for "dur.
Son sözler
Umarım bu blog yazısı, ister SaaS ister kendi kendini yöneten bir GitLab geçişine veya uygulamasına devam etmek için daha donanımlı hissetmenizi sağlar ve ortamınızda başarılı bir sonuç için planlama konusunda size daha geniş bir bakış açısı sunar.
Önerdiğimiz yaklaşımla başarı kriterlerinizi kendi boyutlarına, uygulama maliyetlerineve katılım düzeylerine önceliklendirebilirsiniz.Böylece paydaşlarınız GitLab'in değerini daha erken görecektir. Kullanıcılarınız, uygulama sırasında endişelerinin giderildiğini gördükçe GitLab ile anlamlı bir etkileşimin keyfini çıkaracaklar.
Yukarıda bahsettiğimiz gibi GitLab'de çok fazla özellik vardır. GitLab geçişi veya uygulaması için önerdiğimiz yaklaşımla en iyi sonuçları elde etmek için Premium veya Ultimate olsun, geçerli abonelik planına çok dikkat ederek mevcut tüm özellikleri iyice araştırın. Bu şekilde, hangi özelliklerin başarı kriterlerinizi en iyi şekilde destekleyeceğini öğrenebilirsiniz.
Daha fazla bilgi edinmek için iletişime geçin.
Yazan
Val Naipaul
DevOps Baş Danışmanı
Val, DevOps düşüncesini gerçek dünyadaki sorunlara uygular, bizim DevOps uygulamamızı geliştirir, müşteriler ve ortaklarla fikirlerini ve deneyimlerini paylaşır. Val, yenilikleri teşvik etmek için çeşitli hikâyeler ve bakış açıları sunarak çalışmaktan hoşlanır.