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, gönderme, çekme 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 erken işliyor ve özellik bayraklarını kullanarak uzun süre çalışan özellik dallarından kaçınıyor.

Gönder

Geliştirici değişiklikleri tümleştirmeye ve ekibin geri kalanına göndermeye hazır olduğunda, yerel dalını sunucudaki bir dala gönderir ve bir çekme isteği 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 adlı users/<username>/featuredallar oluşturur ve burada <username> hesap adlarıdır.

Çekme isteği

Çekme istekleri denetimi konu başlığı ana dalla birleştirilir ve dal ilkelerinin karşılandığından emin olun. Çekme isteği işlemi önerilen değişiklikleri oluşturur ve hızlı bir test geçişi çalıştırır. 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 çekme isteklerine hızla 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.

Adres Mektup Birleştirme

Çekme isteği tüm derleme ilkelerini karşıladıktan ve gözden geçirenler oturumunu kapattıktan sonra, konu dalı ana tümleştirme 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 iade sonrası testleri 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 çekme isteklerinin birleştirme için dağıtım kuyruğunda beklediğ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.

Adjunct depoları

Bazı ekipler, adjunct depolarını 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şiklikleri ayrı bir depoda iade edin. 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 mikro hizmetleri benimsemiş ekipler için çoklu depo doğru yaklaşım olabilir. Genellikle monolitler olarak başlayan eski ürünler, Git'e en kolay geçiş olarak mono-depo yaklaşımını bulur ve kod organizasyonları bunu yansıtır.

Yayın dalları

Microsoft yayın akışı ana dalı her zaman derlenebilir tutar. Geliştiriciler ile birleştirilen mainkısa süreli konu dallarında çalışır. Bir ekip, sprint'in sonunda veya önemli bir güncelleştirme için göndermeye hazır olduğunda, ana daldan yeni bir yayın dalı başlatır. Yayın dalları hiçbir zaman ana dala geri dönmez, bu nedenle önemli değişikliklere ihtiyaç duyabilirler.

Aşağıdaki diyagramda mavi ve yayın dalları siyah olarak kısa ömürlü dallar gösterilmektedir. Kiraz toplama gerektiren işlemeye sahip bir dal kırmızı 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, üzerindeki mainen son işlemeye 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ı kullanıma alır, kod değişiklikleri yapar, işler, sunucuya gönderir ve yeni bir çekme isteği 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ştiricilerin ekip arkadaşlarına yeni çekme isteğini duyuran 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ğıtma

Gözden geçirenler, kod sahipleri ve otomasyon karşılandıktan sonra geliştirici çekme isteğini tamamlayabilir. Birleştirme çakışması varsa, geliştirici çakışmayla eşitleme, düzeltme ve değişiklikleri yeniden gönderme yönergelerini 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 açığa çıkarılma durumunu birbirinden kaldırır.

Özelliğin kullanıma hazır hale gelmeden önce biraz daha çalışmaya ihtiyacı olsa bile, ürün derlenip dağıtılırsa adresine gitmek main güvenlidir. 'ye girdikten mainsonra kod, yeniden test edildiği, ilkeyi karşıladığı onaylanan ve dijital olarak imzalandığı resmi bir derlemenin parçası haline gelir.

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 borcunu neredeyse ortadan kaldırır. İkincisi, çekme isteği akışı işlem hattının başlarında test, kod gözden geçirme ve hata algılamayı zorlamak için ortak bir nokta 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 test düzeyi imkansız olacaktır.

Sprint kilometre taşları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, içinden mainbir dal oluşturur, kodu gözden geçirir ve birleştirmeye yönelik çekme isteğini tamamlar. İşlem her zaman ilk önce değişiklik main yapılarak 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şikliğin içine alınması mainda garanti edilir ve bu kritik öneme sahiptir. Değişiklik geri main getirilmeden yayın dalındaki bir hatayı düzeltmek, sprint 130 sürümünden maindallandığında hatanın sonraki dağıtım sırasında yinelenmesi anlamına gelir. Kesinti sırasında ortaya çıkabilecek karışıklık ve stres sırasında güncelleştirmeyi main unutmak kolaydır. Değişiklikleri ilk olarak getirmek main , 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 getirmek için, bir geliştirici çekme isteğini ile mainbirleştirdikten sonra, değişiklikleri yayın dalında tek tek seçmek için çekme isteği sayfasını kullanabilir. Bu işlem, yayın dalını hedefleyen yeni bir çekme isteği oluşturur ve içine yeni birleştirilen mainiçeriği geri aktarır.

Tek seçim işlevinin kullanılması, dal ilkelerinin izlenebilirliğini ve güvenilirliğini sağlayan bir çekme isteğini hızlı bir şekilde açar. Yayın dalını yerel bir bilgisayara indirmek zorunda kalmadan sunucuda kiraz toplama gerçekleşebilir. İ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. Teams, daha gelişmiş bir deneyim için değişiklikleri doğrudan tarayıcı tabanlı metin düzenleyicisinden veya Çekme İsteği Birleştirme Çakışma Uzantısı aracılığıyla düzenleyebilir.

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 dağıtım halkalarını kullanarak düzeltmeyi aşamalı olarak daha fazla hesap için 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 yayın dalını releases/M130 uygulamasından mainoluş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ını da bağlantı noktalarına alır ve dağıtır. 130 dal, düzeltmeyi zaten yükseltilmiş halkalara yeniden dağıtır. 129 dal, düzeltmeyle birlikte sonraki sprint'in sürümüne henüz yükseltilmemiş dış halkalara yeniden dağıtır.

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. Bu nedenle, bu değişiklikler dalda releases/M130 da yer alır.

Özet

Sürüm akışı modeli, Microsoft'un çevrimiçi hizmetler sunmak için DevOps ile geliştirmesinin 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.