Microsoft DevOps ile nasıl gelişir?

Microsoft, Git dallanma ve yayın akışına dayalı sağlam bir DevOps işlemiyle tüm Microsoft ürünlerini derlemek ve dağıtmak için One Mühendislik Sistemi'ni kullanmaya çalışır. Bu makalede pratik uygulama, sistemin küçük hizmetlerden büyük platform geliştirme gereksinimlerine ölçeklendirilmesi ve sistemin çeşitli Microsoft ekiplerinde kullanılmasıyla elde edilecek dersler vurgulanmaktadır.

Standartlaştırılmış bir geliştirme sürecini benimsemek iddialı bir girişimdir. Farklı Microsoft kuruluşlarının gereksinimleri büyük ölçüde farklılık gösterir ve kuruluşlardaki farklı ekiplerin gereksinimleri boyut ve karmaşıklık açısından ölçeklendirilir. Microsoft, bu çeşitli ihtiyaçları karşılamak için hızlı bir şekilde ürün geliştirmeye, düzenli olarak dağıtmaya ve değişiklikleri üretime güvenli bir şekilde sunmaya yardımcı olmak için gövde tabanlı bir dallanma stratejisi kullanır.

Microsoft, One Engineering System kapsamında platform mühendisliği ilkelerini de kullanır.

Microsoft yayın akışı

Ekipler arasında tutarlılık sağlamak için her kuruluş standart bir kod yayın sürecine uyum sağlamalıdır. Microsoft yayın akışı geliştirmeden sürüme DevOps işlemlerini içerir. Yayın akışının temel adımları dal oluşturma, gönder, pull isteği ve birleştirmeden oluşur.

Şube

Bir hatayı düzeltmek veya bir özelliği uygulamak için, geliştirici ana tümleştirme dalı dışında yeni bir dal oluşturur. Git basit dallanma modeli, her kod katkısı için bu kısa süreli konu dallarını oluşturur. Geliştiriciler özellik bayraklarını kullanarak erken kod gönderiyorlar ve uzun süren özellik dallarından kaçınıyorlar.

İtmek

Geliştirici değişiklikleri entegre etmeye ve ekibin geri kalanına göndermeye hazır olduğunda, yerel dalını sunucudaki bir dala gönderir ve bir pull request açar. Birçok dalda çalışan yüzlerce geliştiriciye sahip depolar, karışıklığı ve dalların çoğalmasını azaltmak için sunucu dalları için bir adlandırma kuralı kullanır. Geliştiriciler genellikle, users/<username>/feature adını verdikleri ve <username>'in hesap adı olduğu dallar oluştururlar.

Çekme talebi

Çekme istekleri, konu dallarının ana dala birleştirilmesini kontrol eder ve dal politikalarının karşılandığını garanti eder. Çekme isteği süreci, önerilen değişiklikleri oluşturur ve hızlı bir test aşaması gerçekleştirir. Birinci ve ikinci düzey test paketleri beş dakikadan kısa sürede yaklaşık 60.000 test çalıştırır. Bu, tam Microsoft test matrisi değildir, ancak pull request'lere kısa sürede güven vermek için yeterlidir.

Ardından, ekibin diğer üyeleri kodu gözden geçirir ve değişiklikleri onaylar. Kod incelemesi, otomatikleştirilmiş testlerin nerede kaldığını belirler ve mimari sorunları tespit etmede özellikle yararlıdır. El ile yapılan kod incelemeleri, ekipte yer alan diğer mühendislerin değişiklikler üzerinde görünürlük sahibi olmasını ve kod kalitesinin yüksek kalmasını sağlar.

Birleştir

Çekme isteği tüm derleme ilkelerini karşıladıktan ve gözden geçirenler onay verdikten sonra, konu dalı ana dal ile birleştirilir ve çekme isteği tamamlanır.

Birleştirme işleminden sonra, tamamlanması daha fazla zaman alacak diğer kabul testleri çalıştırılır. Bu geleneksel check-in sonrası testler daha kapsamlı bir doğrulama yapar. Bu test işlemi, çekme isteği gözden geçirmesi sırasında hızlı testlere sahip olmak ve yayından önce tam test kapsamına sahip olmak arasında iyi bir denge sağlar.

GitHub Flow'dan farklar

GitHub Flow , kuruluşların Git'e ölçeklenebilir bir yaklaşım uygulaması için popüler bir gövde tabanlı geliştirme yayın akışıdır. Ancak bazı kuruluşlar, ihtiyaçları arttıkça GitHub Flow'un bazı bölümlerinden farklı olması gerektiğini fark eder.

Örneğin, GitHub Flow'un genellikle göz ardı edilen bir bölümü, çekme isteklerinin ana dala birleştirilmeden önce test için üretime dağıtılması gerektiğidir. Bu işlem, tüm pull requestlerin birleştirme amacıyla dağıtım kuyruğunda bekletildiği anlamına gelir.

Bazı ekiplerin tek bir depoda sürekli olarak çalışan ve günde 200'den fazla çekme isteğini ana dala tamamlayabilen yüzlerce geliştiricisi vardır. Her çekme isteği test için dünyanın dört bir yanındaki birden çok Azure veri merkezine dağıtım gerektiriyorsa, geliştiriciler yazılım yazmak yerine dalların birleştirilmesini beklemek için zaman harcar.

Bunun yerine, Microsoft ekipleri ana dalda geliştirmeye devam eder ve dağıtımları genellikle üç haftalık sprint temposuyla hizalanmış zamanlanmış sürümler halinde toplu hale getirir.

Uygulama ayrıntıları

Microsoft yayın akışının bazı önemli uygulama ayrıntıları şunlardır:

Git deposu stratejisi

Farklı ekiplerin Git depolarını yönetmek için farklı stratejileri vardır. Bazı ekipler, kodlarının çoğunluğunu tek bir Git deposunda tutar. Kod, her biri kendi kök düzeyindeki klasöründeki bileşenlere ayrılır. Büyük bileşenler, özellikle de eski bileşenler, üst bileşen içinde ayrı alt klasörleri olan birden çok alt bileşene sahip olabilir.

Yardımcı depolar

Bazı ekipler, ek depoları da yönetir. Örneğin, derleme ve yayın aracıları ve görevleri, VS Code uzantısı ve açık kaynak projeleri GitHub'da geliştirilir. Yapılandırma değişikliklerini ayrı bir depoya ekleyin. Ekibin bağımlı olduğu diğer paketler başka yerlerden gelir ve NuGet aracılığıyla tüketilir.

Mono depo veya çoklu depo

Bazı ekipler tek bir monolitik depoya, mono depoya sahip olmak isterken, diğer Microsoft ürünleri çoklu depo yaklaşımını kullanır. Örneğin Skype,birçok farklı istemci, hizmet ve araç oluşturmak için çeşitli kombinasyonlarda bir araya gelen yüzlerce küçük depoya sahiptir. Özellikle mikroservisleri benimsemiş ekipler için birden fazla depo doğru yaklaşım olabilir. Genellikle monolitik uygulamalar olarak başlayan eski ürünler, Git'e geçişte mono-depo yaklaşımını en kolay yöntem olarak bulur ve kod organizasyonları bunu yansıtır.

Sürüm dalları

Microsoft yayın süreci ana dalı her zaman derlenebilir durumda tutar. Geliştiriciler, main ile birleştirilen kısa ömürlü konu dallarında çalışır. Bir ekip, bir sprint'in sonunda veya önemli bir güncelleme için yayınlamaya hazır olduğunda, ana daldan yeni bir yayın dalı oluşturur. Yayın dalları hiçbir zaman ana dala geri dönmez, bu nedenle önemli değişikliklere ihtiyaç duyabilirler.

Aşağıdaki diyagramda kısa ömürlü dallar mavi, yayın dalları ise siyah olarak gösterilmektedir. Kiraz toplama yapılması gereken bir işleme sahip dal kırmızı renkte görünür.

Dal ilkeleri ve izinleri

Git dal ilkeleri, yayın dalı yapısının uygulanmasına ve ana dalı temiz tutmaya yardımcı olur. Örneğin, dal ilkeleri ana dala doğrudan gönderimi engelleyebilir.

Ekipler, dal hiyerarşisini düzenli tutmak için izinleri kullanarak hiyerarşinin kök düzeyinde dal oluşturmayı engeller. Aşağıdaki örnekte herkes kullanıcılar/, özellikler/ve ekipler/ gibi klasörlerde dallar oluşturabilir. Yalnızca sürüm yöneticilerinin yayınlar/ altında dal oluşturma izni vardır ve bazı otomasyon araçlarının tümleştirmeler/ klasör için izni vardır.

Git deposu iş akışı

Depo ve dal yapısı içinde geliştiriciler günlük işlerini yapar. Çalışma ortamları takıma ve bireysel olarak büyük ölçüde farklılık gösterir. Bazı geliştiriciler komut satırını tercih eder, bazıları Visual Studio gibi, bazıları farklı platformlarda çalışır. Microsoft depolarında yer alan yapılar ve ilkeler sağlam ve tutarlı bir temel sağlar.

Tipik bir iş akışı aşağıdaki yaygın görevleri içerir:

Yeni bir özellik oluşturma

Yeni bir özellik oluşturmak, bir yazılım geliştiricisinin işinin temelini oluşturur. İşlemin Git dışı bölümleri telemetri verilerine bakmayı, bir tasarım ve belirtim oluşturmayı ve gerçek kodu yazmayı içerir. Ardından geliştirici, main üzerindeki en son işleme eşitleyerek depoyla çalışmaya başlar. Ana dal her zaman derlenebilir olduğundan iyi bir başlangıç noktası olacağı garanti edilir. Geliştirici yeni bir özellik dalını çeker, kod değişiklikleri yapar, kaydeder, sunucuya gönderir ve yeni bir pull request başlatır.

Dal ilkelerini ve denetimlerini kullanma

Çekme isteği oluşturuldukten sonra otomatik sistemler yeni kodun oluşturulup oluşturulmadığını, hiçbir şeyi bozmadığını ve hiçbir güvenlik veya uyumluluk ilkesini ihlal etmediğini denetler. Bu işlem, diğer çalışmaların paralel olarak gerçekleşmesini engellemez.

Dal ilkeleri ve denetimleri, başarılı testler, dokunulan kodun sahipleri tarafından imzalanma ve çekme isteğinin tamamılabilmesi için şirket ilkelerini doğrulamak için birkaç dış denetim de dahil olmak üzere başarılı bir derleme gerektirebilir.

Microsoft Teams ile tümleştirme

Birçok ekip, geliştiricilere yeni pull request'i bildiren Microsoft Teams ile tümleştirmeyi yapılandırıyor. Dokunulan kodun sahipleri otomatik olarak gözden geçiren olarak eklenir. Microsoft ekipleri, rest istemci oluşturma ve paylaşılan denetimler gibi birçok kişinin dokunduğu kodlar için genellikle isteğe bağlı gözden geçirenleri kullanarak bu değişikliklere uzman gözüyle bakar.

Özellik bayraklarıyla dağıtım

Gözden geçirenler, kod sahipleri ve otomasyon tatmin olduktan sonra geliştirici, çekme isteğini tamamlayabilir. Birleştirme çakışması varsa, geliştirici çakışmayı uyumlamak, düzeltmek ve değişiklikleri yeniden göndermesi için talimatlar alır. Otomasyon sabit kod üzerinde yeniden çalışır, ancak insanların yeniden oturumunu kapatması gerekmez.

Dal ile birleştirilir mainve yeni kod bir sonraki sprint veya ana sürümde dağıtılır. Bu, yeni özelliğin hemen gösterileceği anlamına gelmez. Microsoft, özellik bayraklarını kullanarak yeni özelliklerin dağıtımını ve görünürlüğünü birbirinden ayırır.

Özellik kullanıma hazır hale gelmeden önce biraz daha çalışmaya ihtiyaç duyuyor olsa bile, ürün derlenip dağıtılabiliyorsa, main adresine gitmek güvenlidir. Kod main'ye girdikten sonra, yeniden test edilir, politikanın karşılandığı onaylanır ve dijital olarak imzalanarak resmi bir derlemenin parçası olur.

Sorunları erken algılamak için sola kaydırma

Bu Git iş akışı çeşitli avantajlar sağlar. İlk olarak, tek bir ana dalda çalışmak birleştirme yükünü neredeyse ortadan kaldırır. İkincisi, pull isteği süreci, işlem hattının erken aşamalarında test, kod incelemesi ve hata tespitini zorlamak için ortak bir odak noktası sağlar. Bu sola kaydırma stratejisi, saatler veya günler değil dakikalar içinde hataları algılayabildiğinden geliştiricilere geri bildirim döngüsünü kısaltmaya yardımcı olur. Tüm değişiklikler sürekli test edildiğinden, bu strateji yeniden düzenleme için de güvenilirlik sağlar.

Şu anda 200'den fazla çekme isteğine sahip olan bir ürün, her 24 saatte bir 500'den fazla test çalıştırması olmak üzere günde 300'den fazla sürekli tümleştirme derlemesi üretebilir. Gövde tabanlı dallanma ve sürüm iş akışı olmadan, bu düzeyde test yapmak imkansız olurdu.

Sprint dönüm noktalarında yayın

Ekip, her sprint'in sonunda ana daldan bir yayın dalı oluşturur. Örneğin, sprint 129'un sonunda ekip yeni bir yayın dalı releases/M129oluşturur. Ekip daha sonra sprint 129 dalını üretime geçirir.

Yayın dalının dalından sonra, geliştiricilerin değişiklikleri birleştirmesi için ana dal açık kalır. Bu değişiklikler sonraki sprint dağıtımında üç hafta sonra dağıtılacaktır.

Sürüm düzeltmeleri

Bazen değişikliklerin hızla üretime gitmesi gerekir. Microsoft genellikle sprint'in ortasına yeni özellikler eklemez, ancak bazen kullanıcıların engelini kaldırmak için bir hata düzeltmesini hızla getirmek ister. Yazım hataları gibi küçük veya kullanılabilirlik sorununa veya canlı site olayına neden olacak kadar büyük sorunlar olabilir.

Bu sorunları düzeltme normal iş akışıyla başlar. Geliştirici, main üzerinde bir dal oluşturur, onun kodunu gözden geçirir ve birleştirmeye yönelik çekme talebini tamamlar. İşlem her zaman önce main değişikliği yaparak başlar. Bu, düzeltmenin hızlı bir şekilde oluşturulmasına ve yayın dalı geçişine gerek kalmadan yerel olarak doğrulanmasına olanak tanır.

Bu işlemin ardından, değişiklik mainya aktarılır ve bu çok önemlidir. Değişiklik main geri getirilmeden, yayın dalındaki bir hata düzeltmesi yapmak, sprint 130'dan main dalının yayıldığı sonraki dağıtım sırasında hatanın tekrar ortaya çıkması anlamına gelir. Kesinti sırasında ortaya çıkabilecek karışıklık ve stres sırasında güncelleştirmeyi main unutmak kolaydır. Önce main değişikliklerini getirmek, değişikliklerin her zaman hem ana dalda hem de yayın dalında olması anlamına gelir.

Git işlevi bu iş akışını etkinleştirir. Değişiklikleri hemen üretime sunmak için, bir geliştirici bir çekme isteğini main ile birleştirdikten sonra değişiklikleri sürüm dalına tek tek almak için çekme isteği sayfasını kullanabilir. Bu işlem, yayın dalını hedefleyen yeni bir pull request oluşturur ve içine yeni birleştirilen içeriği main geri aktarır.

"Cherry-pick işlevinin kullanılması, dal ilkelerinin izlenebilirliğini ve güvenilirliğini sağlayarak çekme isteğini hızla açar." Yayın dalını yerel bir bilgisayara indirmeden seçme işlemi sunucuda gerçekleştirilebilir. İki dal arasındaki farklar nedeniyle değişiklik yapma, birleştirme çakışmalarını düzeltme veya küçük değişiklikler yapma gibi işlemler sunucuda gerçekleşebilir. Ekipler, değişiklikleri doğrudan tarayıcı tabanlı metin düzenleyicisinden veya daha gelişmiş bir deneyim için Pull Request Merge Conflict Extension aracılığıyla yapabilir.

Bir çekme isteği yayın dalını hedefledikten sonra, ekip kodu bunu yeniden gözden geçirir, dal ilkelerini değerlendirir, çekme isteğini test eder ve birleştirir. Birleştirme işleminden sonra düzeltme, sunucuların ilk halkasına dakikalar içinde dağıtılır. Ekip buradan aşamalı olarak daha fazla hesap için düzeltmeyi dağıtım halkalarını kullanarak dağıtır. Değişiklikler daha fazla kullanıcıya dağıtılırken, ekip başarıyı izler ve değişikliğin hatayı düzeltirken herhangi bir eksiklik veya yavaşlamayla sonuçlanmadığını doğrular. Düzeltme sonunda tüm Azure veri merkezlerine dağıtılır.

Sonraki sprint'e geçme

Sonraki üç hafta boyunca ekip, sprint 130'a özellik eklemeyi tamamlar ve bu değişiklikleri dağıtmaya hazır hale gelir. Yeni sürüm dalını releases/M130 ile main oluşturur ve bu dalı dağıtır.

Bu noktada üretimde aslında iki dal vardır. Değişiklikleri üretime güvenli bir şekilde getirmek için halka tabanlı dağıtım sayesinde hızlı kademe sprint 130 değişikliklerini alır ve yavaş kademe sunucuları, yeni değişiklikler üretimde doğrulanırken sprint 129'da kalır.

Dağıtımın ortasındaki bir değişikliği düzeltme, sprint 129 sürümü ve sprint 130 sürümü olmak üzere iki farklı sürümü düzeltmeyi gerektirebilir. Ekip, düzeltmeyi her iki yayın dalına aktarır ve dağıtır. 130 dal, halihazırda yükseltilmiş olan halkalara düzeltmeyi yeniden dağıtır. 129 şube, düzeltmeleri ile birlikte, sonraki sprint'in sürümüne henüz yükseltilmemiş dış halkalara yeniden dağıtıldı.

Tüm halkalar dağıtıldıktan sonra, sprint 129 dalında düzeltme olarak getirilen tüm değişiklikler içinde mainde yapıldığından eski sprint 129 dalı terk edilir. Değişiklikler releases/M130 dalında da olacak.

Özet

Sürüm akışı modeli, Microsoft'un çevrimiçi hizmetler sunmak için DevOps ile nasıl geliştirdiğinin merkezinde yer alır. Bu model basit, gövde tabanlı bir dallanma stratejisi kullanır. Ancak Microsoft yayın akışı, geliştiricileri bir dağıtım kuyruğunda tutarak değişikliklerini birleştirmeyi beklemek yerine geliştiricilerin çalışmaya devam etmelerini sağlar.

Bu sürüm modeli, Microsoft kod temellerinin boyutuna ve bu veri merkezlerinde çalışan geliştirici sayısına rağmen azure veri merkezlerine düzenli aralıklarla yeni özelliklerin dağıtılmasına da olanak tanır. Model ayrıca düzeltmelerin hızlı ve verimli bir şekilde üretime getirilmesini sağlar.