Microsoft'un Enterprise Live Migrations aracı Azure DevOps'tan GitHub'a geçişi kolaylaştırıyor ama asıl mesele pipeline'lar

Araç ve asıl meselesi

Microsoft'un Enterprise Live Migrations (ELM) hizmeti genel önizlemede ve dev.to'da yayınlanan bir uygulayıcı yazısına göre, repository'leri Azure DevOps'tan GitHub Enterprise'a taşımanın zahmetinin büyük kısmını ortadan kaldırıyor. Taşıma sonrasında mevcut pipeline'ları yeniden bağlayabiliyor bile — tabii bu pipeline'lar Azure DevOps'ta çalışmaya devam ediyorsa. Bu şart, bir ekibi tam geçiş yerine bölünmüş platform düzenine iten asıl neden oldu.

Yazar, CI'nın GitHub'ta, CD'nin Azure DevOps'ta kaldığı hibrit yaklaşımın kendilerine GitHub ekibi tarafından önerildiğini ve toplulukta iyi kurulmuş bir yöntem olduğunu, ancak her kuruluşun bu sınırı farklı çizdiğini belirtiyor.

CI neden GitHub'a taşındı

Ekibin CI'yı taşıma motivasyonu standardizasyon: build'leri kaynak kodun yanında tutmak, böylece geliştiriciler platformlar arasında gidip gelmeden sonuçları görebilmek. GitHub'ın yeniden kullanılabilir workflow'ları sayesinde her repository, gerçek build adımlarını merkezi olarak yönetilen ortak bir workflow'a devreden minimal bir CI dosyası taşıyor. Bu, platform ekiplerine zorunlu adımları dayatmak ve değişiklikleri tüm projelerde aynı anda uygulamak için tek bir nokta sağlıyor.

Yazıda bu ortak workflow'lar için bir etiketleme stratejisinden de bahsediliyor: hareketli bir v1 etiketi en son yinelemeyi takip ediyor, minor etiketler tek tek değişiklikleri kaydediyor ve gelecekteki bir v2 etiketi ise kırıcı güncellemeleri kontrol ederek repository'lerin kademeli geçiş yapabilmesini sağlayacak.

CD neden yerinde kaldı

Engeller veri yerleşikliği ve özel ağ bağlantısı. Yazarın belirttiğine göre ELM yalnızca GHE.com'u destekliyor ve BK bölgesi bulunmuyor — bu kısıtlama, regüle edilmiş BK ortamları için hesabı değiştiriyor. GitHub Enterprise örnekleri mevcut en yakın bölge olduğu için Avrupa'da çalışıyor, buna karşılık altyapıları BK Azure bölgelerinde. GitHub'ın runner'lar için VNet entegrasyonu UK South veya UK West'i kapsamıyor, bu da GitHub Actions'dan özel olarak dağıtım yapmayı engelliyor. Ağ içindeki self-hosted runner'lar iş görürdü, ama o zaman ekibin operasyonel yükü üstlenmesi ve managed runner'ların avantajlarını kaybetmesi gerekirdi.

Azure DevOps bunu Managed DevOps Pools (MDP) ile çözüyor: agent altyapısı kendi Azure aboneliğinize dağıtılıyor, agent'lar devredilen bir subnet üzerinden enjekte ediliyor ve herhangi bir Azure DevOps pipeline'ı tarafından kullanılabiliyor. Bu, self-hosted agent'ların yama ve ölçeklendirme işi olmadan özel ağ bağlantısı sağlıyor. Ekip ayrıca Azure Boards'u da elinde tutuyor — yazar, katı planlama süreçleri isteyen kuruluşlar için bunun daha olgun ürün olduğunu düşünüyor — ve GitHub-to-Azure Boards entegrasyonuyla bağlantılıyor.

Teslimat nasıl çalışıyor

GitHub'taki CI kodu build ediyor ve artifact'leri bir GitHub release'ine yayınlıyor; ardından bir Azure DevOps pipeline'ı o release'i alıp dağıtımı çalıştırıyor. Tetikleyici, Azure/pipelines action'ına dayanıyor; bu action bir GitHub Actions workflow'undan doğrudan Azure Pipelines çalıştırması başlatıyor ancak kimlik doğrulama için personal access token gerektiriyor.

Azure tarafında, GitHub release'lerini indirmek için yerleşik task GHE.com hizmet bağlantılarını desteklemediğinden, yazar GitHub API'sini doğrudan çağıran özel bir script'e geri dönmüş. Bu işe yarıyor ama artık sahipliklerini ve bakımını üstlendikleri, ayrıca yönetmesi gereken kimlik bilgileri olan bir kod — GHE.com desteği kazanırsa yerleşik task'a geri dönecekler.

Tasarımın merkezinde değiştirilemezlik (immutability) var. GitHub'daki release immutability varsayılan olarak kapalı; repository bazında ya da org genelinde etkinleştirilmeli ve yalnızca sonrasında oluşturulan release'lere uygulanıyor. Bu etkinleştirildiğinde Azure DevOps, GitHub'ın build edip test ettiği artifact'i aynen dağıtıyor; yeniden build edip farklı bir ikili dosya üretmiyor — ve geri alma işlemi aynı artifact'i tekrar dağıtıyor.

Yazar ayrıca çoğu çevrimiçi rehberin atladığı bir iş kararına dikkat çekiyor: hangi olayın bir build'i belirli bir ortama yükseltmesi gerektiği. Seçenekler arasında manuel bir workflow dispatch, bir commit üzerindeki etiket veya release dalına yapılan merge'ler var; her birinin farklı ödünleşimleri var ve doğru paydaşlar bunlar üzerinde anlaşıp belgelemeli.

Neden önemli

ELM, repository taşıma maliyetini düşürüyor; ancak bu yazı, asıl zor sorunun pipeline'larınıza ne olacağı olduğunu gösteriyor — ve veri yerleşikliği yükümlülükleri ya da özel dağıtım gereksinimleri olan ekipler için cevap, yıllarca sürebilecek bir hibrit olabilir. Yazı, aynı geçişi değerlendiren herkes için bir kontrol listesi işlevi de görüyor: GitHub Actions'ın özel dağıtım yapabileceğini varsaymadan önce bölgeleriniz için runner VNet kapsamını doğrulayın, her iki platformda managed pool'ları self-hosted runner'larla karşılaştırın, release immutability'yi açık hale getirin ve yükseltme tetikleyicilerini teknik bir sonradan düşünme yerine belgelenmiş bir karar olarak ele alın. Bu tek bir ekibin uygulaması, bir şablon değil; ama bir önizleme aracının belgelerinin sizin için yazmayacağı ödünleşimleri haritalıyor.