DevOps

Tavsiye

Bu içerik, .NET Docs veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Azure için Bulut Yerel .NET Uygulamaları Tasarlama adlı e-Kitap'tan bir alıntıdır.

PDF'i indirin

Azure eKitap kapak küçük resmi için Buluta Özel .NET uygulamaları.

Yazılım danışmanlarının favori mantrası, sorulan herhangi bir soruya "Bağlıdır" yanıtını vermektir. Bunun nedeni yazılım danışmanlarının pozisyon almamaya düşkün olması değildir. Bunun nedeni yazılımdaki soruların gerçek bir yanıtı olmamasıdır. Mutlak doğru ve yanlış yoktur, karşıtlar arasında denge vardır.

Örneğin, web uygulaması geliştirmenin iki büyük okulunu ele alalım: Tek Sayfalı Uygulamalar (SPA'lar) ve sunucu tarafı uygulamalar. Bir yandan, kullanıcı deneyimi SPA'larla daha iyi olma eğilimindedir ve web sunucusuna gelen trafik miktarı en aza indirgenerek onları statik barındırma kadar basit bir şeyde barındırmayı mümkün hale getirebilirsiniz. Öte yandan, SPA'ların gelişmesi daha yavaş ve test edilmesi daha zor olma eğilimindedir. Hangisi doğru seçimdir? Senin durumuna bağlı.

Bulut tabanlı uygulamalar aynı dikotomiye karşı bağışık değildir. Geliştirme hızı, kararlılık ve ölçeklenebilirlik açısından net avantajları vardır, ancak bunları yönetmek biraz daha zor olabilir.

Yıllar önce, bir uygulamayı geliştirme aşamasından üretim aşamasına taşıma işleminin bir ay veya daha uzun sürmesi yaygın bir durum değildi. Şirketler yazılımlarını 6 aylık hatta her yıl yayınlar. Windows 10 öncesinde kabul edilen sürüm temposunun nasıl olduğuna dair bir fikir edinmek için Microsoft Windows'un geçmiş sürümlerine bakmak yeterlidir. Windows XP ve Vista arasında beş yıl, Vista ile Windows 7 arasında üç yıl daha geçti.

Yazılımı hızlı bir şekilde piyasaya sürme yeteneğine sahip olmak, hızlı hareket eden şirketlere, yavaş hareket eden rakiplerine kıyasla büyük bir pazar avantajı sağlar. Bu nedenle Windows 10'da yapılan büyük güncelleştirmeler artık yaklaşık altı ayda bir güncelleştirilir.

İşletmeye değer sunmak için daha hızlı ve daha güvenilir sürümler sağlayan desenler ve uygulamalar topluca DevOps olarak bilinir. Bir uygulamayı belirtmeden uygulamayı teslim etmeye ve çalıştırmaya kadar tüm yazılım geliştirme yaşam döngüsünü kapsayan çok çeşitli fikirlerden oluşur.

DevOps mikro hizmetlerden önce ortaya çıktı ve büyük olasılıkla daha küçük, amaca daha uygun hizmetlere doğru hareket etmek DevOps olmadan üretimde yalnızca bir uygulamayı değil, çok sayıda uygulamayı yayınlamayı ve çalıştırmayı kolaylaştırmak mümkün olmazdı.

Şekil 10-1 - DevOps ve mikro hizmetler.

İyi DevOps uygulamaları sayesinde, uygulamaları gerçekten işleten bir iş dağının altında boğulmadan buluta özel uygulamaların avantajlarını hayata geçirmek mümkündür.

DevOps söz konusu olduğunda altın çekiç yoktur. Kimse yüksek kaliteli uygulamaları yayınlamak ve çalıştırmak için eksiksiz ve her şeyi kapsayan bir çözüm satamıyor. Bunun nedeni, her uygulamanın diğerlerinden tamamen farklı olmasıdır. Ancak DevOps'un daha az göz korkutucu bir teklif olmasına neden olabilecek araçlar vardır. Bu araçlardan biri Azure DevOps olarak bilinir.

Azure DevOps

Azure DevOps uzun bir soyağacına sahiptir. Köklerini, Team Foundation Server'ın ilk çevrimiçi taşındığı zamanlara ve çeşitli ad değişiklikleriyle izleyebilir: Visual Studio Online ve Visual Studio Team Services. Ancak yıllar boyunca, öncüllerinden çok daha fazlası haline geldi.

Azure DevOps beş ana bileşene ayrılmıştır:

Şekil 10-2 - Azure DevOps.

Azure Repos - Saygın Team Foundation Sürüm Denetimi'ni (TFVC) ve sektörde sık kullanılan Git'i destekleyen kaynak kodu yönetimi. Çekme istekleri, yapılan değişikliklerin tartışmasını teşvik ederek sosyal kodlamayı etkinleştirmenin bir yolunu sağlar.

Azure Boards - Kullanıcıların kendileri için en uygun iş akışlarını seçmesine olanak sağlayan bir sorun ve iş öğesi izleme aracı sağlar. SCRUM ve Kanban geliştirme stillerini destekleyen şablonlar da dahil olmak üzere önceden yapılandırılmış bir dizi şablonla birlikte gelir.

Azure Pipelines - Azure ile sorunsuz entegrasyonu destekleyen bir inşa ve yayın yönetim sistemi. Derlemeler Windows'tan Linux'a ve macOS'a kadar çeşitli platformlarda çalıştırılabilir. Derleme aracıları bulutta veya şirket içinde sağlanabilir.

Azure Test Planları - Test Planları özelliği tarafından sunulan test yönetimi ve keşif testi desteğiyle hiçbir Soru-Cevap kullanıcısı geride bırakılmaz.

Azure Artifacts - Şirketlerin kendi özel versiyonlarındaki NuGet, npm ve diğerlerini oluşturmasına olanak tanıyan dahili bileşen deposu. Merkezi bir depoda hata olması durumunda yukarı akış paketlerinin önbelleği olarak davranmanın çift amacına hizmet eder.

Azure DevOps'taki en üst düzey kuruluş birimi Proje olarak bilinir. Her projede Azure Artifacts gibi çeşitli bileşenler açılıp kapatılabilir. Bu bileşenlerin her biri buluta özel uygulamalar için farklı avantajlar sağlar. En kullanışlı üç seçenek depolar, panolar ve işlem hatlarıdır. Kullanıcılar kaynak kodlarını GitHub gibi başka bir depo yığınında yönetmek istiyor ancak yine de Azure Pipelines'dan ve diğer bileşenlerden yararlanıyorsa, bu mükemmel bir şekilde mümkündür.

Neyse ki geliştirme ekiplerinin depo seçerken birçok seçeneği vardır. Bunlardan biri GitHub'dır.

GitHub İşlemleri

2009 yılında kurulan GitHub, projeleri, belgeleri ve kodları barındırmak için popüler bir web tabanlı depodur. Apple, Amazon, Google ve temel şirketler gibi birçok büyük teknoloji şirketi GitHub'ı kullanır. GitHub, temeli olarak Git adlı açık kaynak, dağıtılmış sürüm denetim sistemini kullanır. Üstüne, hata izleme, özellik ve çekme istekleri, görev yönetimi ve her kod tabanı için wiki'ler dahil olmak üzere kendi özellik kümesini ekler.

GitHub geliştikçe DevOps özellikleri de ekleniyor. Örneğin, GitHub'ın adı GitHub Actions olan kendi sürekli tümleştirme/sürekli teslim (CI/CD) işlem hattı vardır. GitHub Actions, topluluk destekli bir iş akışı otomasyon aracıdır. DevOps ekiplerinin mevcut araçlarıyla tümleştirilmesine, yeni ürünleri karıştırıp eşleştirmesine ve mevcut CI/CD iş ortakları dahil olmak üzere yazılım yaşam döngülerine bağlanmalarına olanak tanır."

GitHub'ın 40 milyondan fazla kullanıcısı vardır ve bu da onu dünyanın en büyük kaynak kodu konağı haline getirir. Ekim 2018'de Microsoft GitHub'ı satın almış. Microsoft, GitHub'ın herhangi bir geliştiricinin takabileceği ve genişletebileceği açık bir platform olarak kalacağına söz verdi. Bağımsız bir şirket olarak çalışmaya devam eder. GitHub kurumsal, ekip, profesyonel ve ücretsiz hesaplar için planlar sunar.

Kaynak denetimi

Bulutta yerel bir uygulamanın kodunu düzenlemek zor olabilir. Buluta özel uygulamalar tek bir dev uygulama yerine birbiriyle konuşan daha küçük uygulamalardan oluşan bir web'den oluşur. Bilgi işlemdeki her şeyde olduğu gibi en iyi kod düzenlemesi de açık bir soru olarak kalır. Farklı düzen türleri kullanan başarılı uygulamalar örnekleri vardır, ancak en popüler olan iki değişken gibi görünüyor.

Gerçek kaynak denetimine geçmeden önce, kaç projenin uygun olduğunu belirlemeye değer. Tek bir projede birden çok depo ve derleme işlem hatları için destek sağlanmaktadır. Panolar biraz daha karmaşıktır, ancak orada da görevler tek bir proje içinde birden çok takıma kolayca atanabilir. Tek bir Azure DevOps projesinde yüzlerce, hatta binlerce geliştiriciyi desteklemek mümkündür. Bunu yapmak, tüm geliştiricilerin çalışması için tek bir yer sağladığından ve geliştiricilerin hangi projede bulunduğundan emin olmadığında bu uygulamayı bulma karışıklığını azalttığı için büyük olasılıkla en iyi yaklaşımdır.

Azure DevOps projesindeki mikro hizmetler için kodu bölmek biraz daha zor olabilir.

Şekil 10-3 - Tek depo vs. birçok depo.

Mikroservis başına depo

İlk bakışta, bu yaklaşım mikro hizmetler için kaynak kodu bölmek için en mantıklı yaklaşım gibi görünüyor. Her depo, bir mikro hizmeti oluşturmak için gereken kodu içerebilir. Bu yaklaşımın avantajları kolayca görülebilir:

1. Uygulamayı oluşturma ve sürdürme yönergeleri, her deponun kökündeki BIROKU dosyasına eklenebilir. Depolara göz atarken bu yönergeleri bulmak kolaydır ve geliştiriciler için başlangıç süresini azaltır.
2. Her hizmet, hizmetin adını bilerek kolayca bulunan mantıksal bir yerde bulunur.
3. Derlemeler, yalnızca sahibi olan depoda bir değişiklik yapıldığında tetiklenecek şekilde kolayca ayarlanabilir.
4. Bir depoya gelen değişikliklerin sayısı, proje üzerinde çalışan az sayıda geliştiriciyle sınırlıdır.
5. Geliştiricilerin okuma ve yazma izinlerine sahip olduğu depoları kısıtlayarak güvenlik kolayca ayarlanabilir.
6. Depo düzeyi ayarları, sahibi olan ekip tarafından başkalarıyla en az tartışmayla değiştirilebilir.

Mikro hizmetlerin ardındaki önemli fikirlerden biri, hizmetlerin silolanması ve birbirinden ayrılması gerektiğidir. Hizmetlerin sınırlarına karar vermek için Etki Alanı Odaklı Tasarım kullanılırken, hizmetler işlem sınırları olarak davranır. Veritabanı güncelleştirmeleri birden çok hizmete yayılmamalıdır. bu ilgili veri koleksiyonu sınırlanmış bağlam olarak adlandırılır. Bu fikir, mikro hizmet verilerinin diğer hizmetlerden ayrı ve otonom bir veritabanına yalıtılmış olmasıyla yansıtılır. Bu fikri kaynak koduna kadar taşımak çok mantıklıdır.

Ancak, bu yaklaşım sorunları olmadan değildir. Zamanımızın en önemli geliştirme sorunlarından biri bağımlılıkları yönetmektir. Ortalama node_modules dizini oluşturan dosya sayısını göz önünde bulundurun. Bir şeyin create-react-app gibi yeni bir yüklemesi muhtemelen yanında binlerce paket getirecektir. Bu bağımlılıkların nasıl yönetileceğinin sorusu zor bir sorudur.

Bir bağımlılık güncelleştirilirse aşağı akış paketlerinin de bu bağımlılığı güncelleştirmesi gerekir. Ne yazık ki, bu geliştirme çalışması gerektirir, dolayısıyla kaçınılmaz olarak node_modules dizini, her biri biraz farklı bir tempoda sürümlenen başka bir paketin bağımlılığı olan tek bir paketin birden çok sürümüyle sonuçlanır. Bir uygulamayı dağıtırken, bağımlılığın hangi sürümü kullanılmalıdır? Şu anda üretimde olan sürüm mü? Şu anda Beta sürümünde olan ancak tüketici ürünü kullanmaya başladığında üretimde olması muhtemel sürüm. Yalnızca mikro hizmetler kullanılarak giderilmeyen zor sorunlar.

Çok çeşitli projelere bağlı kitaplıklar vardır. Mikro hizmetleri her depoda bir taneye bölerek iç bağımlılıklar en iyi şekilde iç depo olan Azure Artifacts kullanılarak çözümlenebilir. Kütüphaneler için yapılar, en son sürümlerini iç tüketim amacıyla Azure Artifacts'e aktaracak. Alt akış projesi, yeni güncellenen paketlere bağımlılık kurmak üzere manüel olarak güncellenmelidir.

Hizmetler arasında kod taşınırken başka bir dezavantaj ortaya çıkar. Bir uygulamanın mikro hizmetlere ilk bölünmesinin %100% doğru olduğuna inanmak güzel olsa da, gerçekte hizmet bölümü hataları yapmamak için nadiren bu kadar öngörülü oluruz. Bu nedenle, işlevselliğin ve onu yönlendiren kodun hizmetten hizmete( depodan depoya) taşınması gerekir. Bir depodan diğerine atlarken kod geçmişini kaybeder. Özellikle bir kod parçası üzerinde tam geçmişe sahip olmanın değerli olduğu bir denetim durumunda birçok durum vardır.

Son ve en önemli dezavantaj, değişiklikleri koordine etmektir. Gerçek bir mikro hizmet uygulamasında, hizmetler arasında dağıtım bağımlılıkları olmamalıdır. A, B ve C hizmetlerini gevşek bağlantılara sahip oldukları için herhangi bir sırayla dağıtmak mümkün olmalıdır. Ancak gerçekte, bazen aynı anda birden çok depoyu kapsayan bir değişiklik yapmak istenir. Bazı örnekler arasında bir güvenlik deliğini kapatmak için kitaplığı güncelleştirme veya tüm hizmetler tarafından kullanılan iletişim protokolünü değiştirme sayılabilir.

Birden fazla depo üzerinde değişiklik yapmak için her depoya ardı ardına bir commit yapılması gerekir. Her depodaki her değişikliğin çekme isteğinde bulunulup ayrı olarak gözden geçirilmesi gerekir. Bu etkinliği koordine etmek zor olabilir.

Birçok depo kullanmanın bir alternatifi, tüm kaynak kodun tümünü bilen, tek bir depoda bir araya getirmektir.

Tek depo

Bazen monorepository olarak da adlandırılan bu yaklaşımda, her hizmetin tüm kaynak kodu aynı depoya konur. İlk başta, bu yaklaşım kaynak koduyla uğraşmayı zorlaştıracak korkunç bir fikir gibi görünüyor. Ancak, bu şekilde çalışmanın bazı belirgin avantajları vardır.

İlk avantajı, projeler arasındaki bağımlılıkları yönetmenin daha kolay olmasıdır. Projeler, bazı dış paket akışlarına güvenmek yerine doğrudan birbirlerini içe aktarabilir. Bu, güncelleştirmelerin anlık olduğu ve çakışan sürümlerin geliştiricinin iş istasyonunda derleme zamanında bulunacağı anlamına gelir. Aslında, tümleştirme testlerinin bir kısmını sola kaydırarak.

Projeler arasında kod taşırken, dosyalar yeniden yazılmak yerine taşınmış olarak algılanacağı için geçmişi korumak artık daha kolay.

Bir diğer avantajı da, hizmet sınırları arası geniş kapsamlı değişikliklerin tek bir işlemede yapılabilmesidir. Bu etkinlik, ayrı ayrı gözden geçirebilmek için onlarca değişiklik yapma yükünü azaltır.

Güvenli olmayan programlama uygulamalarını veya API'lerin sorunlu kullanımını algılamak için kodun statik analizini gerçekleştirebilen birçok araç vardır. Çok depolu bir dünyada, her depodaki sorunları bulmak için depolar üzerinden tek tek geçilmelidir. Tek depo, analizin tümünü tek bir yerde çalıştırmaya olanak tanır.

Tek depo yaklaşımının birçok dezavantajı da vardır. En endişe verici olanlardan biri, tek bir depoya sahip olmanın güvenlik endişelerini doğurmadır. Hizmet bazlı depo modelinde, bir deponun içeriği sızdırılırsa, kaybedilen kod miktarı minimaldir. Tek bir depo ile şirketin sahip olduğu her şey kaybolabilir. Bunun gerçekleştiği ve tüm oyun geliştirme çalışmalarının raydan çıkarıldığı geçmişte birçok örnek verilmiştir. Birden çok depoya sahip olmak, çoğu güvenlik uygulamasında istenen bir özellik olan daha az yüzey alanını ortaya çıkarır.

Tek deponun boyutu hızla yönetilemez hale gelebilir. Bu, bazı ilginç performans etkileri sunar. Başlangıçta Windows ekibindeki geliştiricilerin deneyimini geliştirmek için tasarlanmış olan Git için Sanal Dosya Sistemi gibi özel araçlar kullanmak gerekebilir.

Genellikle tek bir kaynak havuzu kullanma gerekçesi, Facebook veya Google'ın kod düzenlemesi amacıyla bu yöntemi kullandığı gerçeğine indirgenir. Yaklaşım bu şirketler için yeterince iyiyse, elbette tüm şirketler için doğru yaklaşımdır. İşin aslı, birkaç şirketin Facebook veya Google ölçeği gibi herhangi bir şey üzerinde faaliyet gösterdiğidir. Bu ölçeklerde oluşan sorunlar, geliştiricilerin karşılaşacağı sorunlardan farklıdır. Kaz için iyi olan şey, gander için iyi olmayabilir.

Sonunda, mikro hizmetlerin kaynak kodunu barındırmak için herhangi bir çözüm kullanılabilir. Ancak çoğu durumda, tek bir depoda çalışmanın yönetim ve mühendislik yükü, az sayıda avantaj elde etmeye değmez. Kodun birden çok depoya bölünmesi, endişelerin daha iyi ayrılmasını teşvik eder ve geliştirme ekiplerinin özerkliğini teşvik eder.

Standart dizin yapısı

Tek ve birden çok depo arasındaki tartışmadan bağımsız olarak her hizmetin kendi dizini olacaktır. Geliştiricilerin projeler arasında hızla geçiş yapmaya olanak sağlayan en iyi iyileştirmelerden biri, standart dizin yapısını korumaktır.

Şekil 10-4 - Standart dizin yapısı.

Yeni bir proje oluşturulduğunda, doğru yapıyı yerleştiren bir şablon kullanılmalıdır. Bu şablon, iskelet README dosyası ve azure-pipelines.yml gibi yararlı öğeleri de içerebilir. Herhangi bir mikro hizmet mimarisinde, projeler arasındaki yüksek oranda varyans, hizmetlere karşı toplu işlemleri daha zor hale getirir.

Çeşitli kaynak kodu dizinleri içeren bir dizinin tamamı için şablon oluşturma sağlayabilen birçok araç vardır. Yeoman , JavaScript dünyasında popülerdir ve GitHub yakın zamanda aynı işlevlerin çoğunu sağlayan Depo Şablonları'nı yayınladı.

Görev yönetimi

Herhangi bir projedeki görevleri yönetmek zor olabilir. En iyi geliştirici üretkenliğini sağlamak için ayarlanacak iş akışı türleri hakkında yanıtlanması gereken sayısız soru vardır.

Bulutta yerel uygulamalar geleneksel yazılım ürünlerinden daha küçük olma eğilimindedir veya en azından daha küçük hizmetlere ayrılmıştır. Bu hizmetlerle ilgili sorunların veya görevlerin izlenmesi, diğer yazılım projelerinde olduğu gibi önemli olmaya devam eder. Hiç kimse bir iş öğesinin izini kaybetmek veya müşteriye sorununun düzgün şekilde günlüğe kaydedilmediğini açıklamak istemez. Panolar proje düzeyinde yapılandırılır, ancak her proje içinde alanlar tanımlanabilir. Bunlar, sorunları çeşitli bileşenlere ayırmaya olanak sağlar. Tüm uygulamanın tüm çalışmalarını tek bir yerde tutmanın avantajı, daha iyi anlaşıldığı için iş öğelerini bir ekipten diğerine taşımanın kolay olmasıdır.

Azure DevOps, önceden yapılandırılmış bir dizi popüler şablonla birlikte gelir. En temel yapılandırmada bilmeniz gerekenler, bekleyen iş listesinde neler olduğu, insanların ne üzerinde çalıştığı ve tamamlanan işlerdir. İş önceliklerinin belirlenebilmesi ve tamamlanan görevlerin müşteriye bildirilmesi için yazılım oluşturma işlemine bu görünürlüğün sahip olması önemlidir. Tabii ki, az sayıda yazılım projesi to do, doing ve done kadar basit bir sürece bağlı kalır. İnsanların sürece QA veya Detailed Specification gibi adımlar eklemeye başlaması uzun sürmez.

Çevik metodolojilerin en önemli parçalarından biri, düzenli aralıklarla kendini değerlendirmektir. Bu incelemeler, ekibin karşılaştığı sorunlar ve bunların nasıl geliştirilebileceği hakkında içgörü sağlamak için geliştirilmiştir. Bu genellikle geliştirme süreci boyunca sorunların ve özelliklerin akışını değiştirmek anlamına gelir. Bu nedenle, panoların düzenlerini ek aşamalarla genişletmek son derece sağlıklıdır.

Panolardaki aşamalar tek kuruluş aracı değildir. Panonun yapılandırmasına bağlı olarak, iş öğelerinin hiyerarşisi vardır. Panoda gösterilebilen en ayrıntılı öğe bir görevdir. Kullanıma hazır olarak, bir görev başlık, açıklama, öncelik, kalan iş miktarı tahmini ve diğer iş öğelerine veya geliştirme öğelerine (dallar, işlemeler, çekme istekleri, derlemeler vb.) bağlanabilme özelliğine yönelik alanlar içerir. İş öğeleri, uygulamanın farklı alanlarına ve bunları bulmayı kolaylaştırmak için farklı yinelemelere (sprint) sınıflandırılabilir.

Şekil 10-5 - Azure DevOps'taki görev.

Açıklama alanı, beklenen normal stilleri (kalın, italik, altı çizili ve üstü çizili) ve resim ekleme özelliğini destekler. Bu, işi veya hataları belirtirken kullanmak için güçlü bir araç haline getirir.

Görevler, daha büyük bir çalışma birimi tanımlayan özelliklere toplanabilir. Özellikler epiklere dönüştürülebilir. Bu hiyerarşideki görevleri sınıflandırmak, büyük bir özelliğin kullanıma sunulmaya ne kadar yakın olduğunu anlamanın çok daha kolay olmasını sağlar.

Şekil 10-6 - Azure DevOps'ta iş öğesi.

Azure Boards'taki konulara dair farklı türde görünümler vardır. Henüz zamanlanmamış öğeler bekleme listesinde görünür. Buradan bir sprint'e atanabilir. Sprint, bir miktar çalışmanın tamamlanmasının beklendiği bir zaman dilimidir. Bu çalışma, görevlerin yanı sıra biletlerin çözülmesini de içerebilir. Oraya vardıktan sonra sprint'in tamamı Sprint panosu bölümünden yönetilebilir. Bu görünüm, çalışmanın nasıl ilerlediğini gösterir ve sprint'in başarılı olup olmayacağına dair sürekli güncellenen bir tahmin sağlamak için bir azaltma grafiği içerir.

Şekil 10-7 - Azure DevOps'ta pano.

Şu anda, Azure DevOps'taki Boards'ta çok fazla güç olduğu açıkça görülmelidir. Geliştiriciler için üzerinde çalışılan işlemlerin kolay görünümleri vardır. Proje yöneticilerinin yaklaşan çalışmalara yönelik görünümleri ve mevcut çalışmalara genel bakış için. Yöneticiler için kaynak ve kapasite hakkında birçok rapor vardır. Ne yazık ki buluta özel uygulamalarda çalışmayı izleme gereksinimini ortadan kaldıran sihirli bir şey yoktur. Ancak çalışmayı izlemeniz gerekiyorsa, deneyimin Azure DevOps'tan daha iyi olduğu birkaç yer vardır.

CI/CD boru hatları

Yazılım geliştirme yaşam döngüsünde neredeyse hiçbir değişiklik sürekli tümleştirme (CI) ve sürekli teslim (CD) ortaya çıkması kadar devrimsel olmamıştır. Bir değişiklik işlendiğinde, projenin kaynak kodu üzerinde otomatikleştirilmiş testler oluşturmak ve çalıştırmak hataları erkenden yakalar. Sürekli tümleştirme yapıların ortaya çıkmasından önce, bir depodan kod çekmek yaygın bir durumdu ve bu kodun testlerden geçmediği veya hatta derlenemediği görülürdü. Bu, kırılmanın kaynağının izlenmesine neden oldu.

Geleneksel olarak yazılımı üretim ortamına göndermek için kapsamlı belgeler ve bir adım listesi gerekir. Bu adımlardan her birinin çok hataya açık bir işlemde el ile tamamlanması gerekiyordu.

Şekil 10-8 - Denetim Listesi.

Sürekli entegrasyonun kardeşi, yeni oluşturulan paketlerin bir ortama dağıtıldığı sürekli teslimat sürecidir. El ile gerçekleştirilen işlem geliştirme hızıyla eşleşecek şekilde ölçeklendirilemez, bu nedenle otomasyon daha önemli hale gelir. Denetim listeleri, aynı görevleri herhangi bir insandan daha hızlı ve daha doğru yürütebilen betiklerle değiştirilir.

Sürekli teslimin yapıldığı ortam bir test ortamı olabilir veya birçok büyük teknoloji şirketi tarafından yapıldığı gibi üretim ortamı olabilir. İkincisi, bir değişikliğin kullanıcılar için üretimi bozmayabileceğine güven verebilecek yüksek kaliteli testlere yatırım yapılmasını gerektirir. Sürekli tümleştirmenin koddaki sorunları erken yakaladığı gibi, sürekli teslim de dağıtım sürecindeki sorunları erken yakalar.

Derleme ve teslim sürecini otomatikleştirmenin önemi, buluta özel uygulamalar tarafından vurgulanır. Dağıtımlar daha sık ve daha fazla ortamda gerçekleştiği için el ile dağıtım yapmak neredeyse imkansız hale geliyor.

Azure Yapıları

Azure DevOps, sürekli tümleştirme ve dağıtımı her zamankinden daha kolay hale getirmek için bir dizi araç sağlar. Bu araçlar Azure Pipelines altında bulunur. Bunlardan ilki, YAML tabanlı derleme tanımlarını büyük ölçekte çalıştırmaya yönelik bir araç olan Azure Derlemeleri'dir. Kullanıcılar kendi derleme makinelerini getirebilir (derlemenin titizlikle ayarlanmış bir ortam gerektirmesi durumunda harikadır) veya azure tarafından barındırılan sanal makinelerin sürekli yenilenen havuzundan bir makine kullanabilir. Bu barındırılan derleme aracıları, yalnızca .NET geliştirme için değil Java'dan Python'a ve iPhone geliştirmesine kadar her şey için çok çeşitli geliştirme araçlarıyla önceden yüklenmiş olarak gelir.

DevOps, herhangi bir derleme için özelleştirilebilen çok çeşitli kullanıma hazır derleme tanımları içerir. Derleme tanımları adlı azure-pipelines.yml bir dosyada tanımlanır ve kaynak kodla birlikte sürümlenebilmeleri için depoya iade edilir. Bu, bir daldaki derleme işlem hattında değişiklik yapmayı çok daha kolay hale getirir. Değişiklikler yalnızca bu dalda denetlenebilir. Şekil 10-9'da, tam çerçeve üzerinde ASP.NET web uygulaması oluşturma örneği azure-pipelines.yml gösterilmektedir.

name: $(rev:r)

variables:
  version: 9.2.0.$(Build.BuildNumber)
  solution: Portals.sln
  artifactName: drop
  buildPlatform: any cpu
  buildConfiguration: release

pool:
  name: Hosted VisualStudio
  demands:
  - msbuild
  - visualstudio
  - vstest

steps:
- task: NuGetToolInstaller@0
  displayName: 'Use NuGet 4.4.1'
  inputs:
    versionSpec: 4.4.1

- task: NuGetCommand@2
  displayName: 'NuGet restore'
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  displayName: 'Build solution'
  inputs:
    solution: '$(solution)'
    msbuildArgs: '-p:DeployOnBuild=true -p:WebPublishMethod=Package -p:PackageAsSingleFile=true -p:SkipInvalidConfigurations=true -p:PackageLocation="$(build.artifactstagingdirectory)\\"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  displayName: 'Test Assemblies'
  inputs:
    testAssemblyVer2: |
     **\$(buildConfiguration)\**\*test*.dll
     !**\obj\**
     !**\*testadapter.dll
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: CopyFiles@2
  displayName: 'Copy UI Test Files to: $(build.artifactstagingdirectory)'
  inputs:
    SourceFolder: UITests
    TargetFolder: '$(build.artifactstagingdirectory)/uitests'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
    ArtifactName: '$(artifactName)'
  condition: succeededOrFailed()

Şekil 10-9 - Örnek azure-pipelines.yml

Bu derleme tanımı, yerleşik görevler kullanır ve derleme oluşturmayı, dev Millennium Falcon'dan daha basit olacak şekilde, bir Lego setini oluşturmak kadar basit hale getirir. Örneğin, NuGet görevi NuGet paketlerini geri yüklerken, VSBuild görevi gerçek derlemeyi gerçekleştirmek için Visual Studio derleme araçlarını çağırır. Azure DevOps'ta yüzlerce farklı görev vardır ve topluluk tarafından sürdürülen binlerce görev daha vardır. Büyük olasılıkla hangi derleme görevlerini çalıştırmayı seçerseniz çalıştırın, birisi zaten bir tane oluşturmuş olabilir.

Derlemeler el ile, check-in ile, zamanlanmış şekilde veya başka bir derlemenin tamamlanmasıyla tetiklenebilir. Çoğu durumda, her kod teslimini derlemek tercih edilir. Derlemeler filtrelenebilir, böylece farklı derlemeler deponun farklı bölümlerine veya farklı dallara göre çalışır. Bu, pull request'lerde azaltılmış testlerle hızlı derlemeler çalıştırma ve her gece ana dala karşı tam regresyon paketi çalıştırma gibi senaryolara olanak tanır.

Derlemenin nihai sonucu, derleme artifaktları olarak bilinen bir dosya koleksiyonudur. Bu yapıtlar derleme işleminin sonraki adımına geçirilebilir veya bir Azure Artifacts akışına eklenebilir, böylece diğer derlemeler tarafından kullanılabilir.

Azure DevOps sürümleri

Derlemeler, yazılımı gönderilebilir bir pakete derlemeyi üstlenir, ancak sürekli teslimi tamamlamak için yapıtların yine de bir test ortamına gönderilmesi gerekir. Bunun için Azure DevOps, Yayınlar adlı ayrı bir araç kullanır. Yayınlar aracı, Derleme için mevcut olan aynı görev kitaplığını kullanırken "aşamalar" kavramını tanıtır. Aşama, paketin yüklendiği yalıtılmış bir ortamdır. Örneğin, bir ürün geliştirme, soru-cevap ve üretim ortamından yararlanabilir. Kod, otomatikleştirilmiş testlerin çalıştırılabildiği geliştirme ortamına sürekli olarak teslim edilir. Bu testler geçtikten sonra sürüm, el ile test için Kalite Güvence (KG) ortamına taşınır. Son olarak, kod herkes tarafından görülebilen üretim ortamına gönderiliyor.

Şekil 10-10 - Yayın işlem hattı

Derlemedeki her aşama, önceki aşamanın tamamlanmasıyla otomatik olarak tetiklenebilir. Ancak çoğu durumda bu tercih edilmez. Kodu üretime taşımak için birinden onay gerekebilir. Yayınlar aracı, yayın işlem hattının her adımında onaylayanlara izin vererek bunu destekler. Kurallar, belirli bir kişinin veya kişi grubunun bir sürümü üretime girmeden önce onaylaması gereken şekilde ayarlanabilir. Bu kapılar, el ile kalite kontrolleri ve üretime girenleri kontrol etmeyle ilgili tüm mevzuat gereksinimleriyle uyumluluk sağlar.

Herkese bir derleme işlem hattı sunuluyor

Birçok derleme işlem hattını yapılandırmanın bir maliyeti yoktur, bu nedenle mikro hizmet başına en az bir derleme işlem hattına sahip olmak avantajlıdır. İdeal olarak, mikro hizmetler herhangi bir ortama bağımsız olarak dağıtılabilir, bu nedenle her birinin bir yığın ilgisiz kod yayınlamadan kendi işlem hattı üzerinden yayınlanması mükemmeldir. Her işlem hattının, her hizmet için derleme sürecinde varyasyonlara olanak sağlayan kendi onay kümesi olabilir.

Sürüm oluşturma sürümleri

Yayınlar işlevini kullanmanın bir dezavantajı, teslim edilmiş azure-pipelines.yml bir dosyada tanımlanamamasıdır. Dal başına yayın tanımlarına sahip olmaktan proje şablonunuzda bir yayın iskeleti eklemeye kadar bunu yapmak istemenizin birçok nedeni vardır. Neyse ki bazı aşama desteğini Derleme bileşenine kaydırmak için çalışmalar devam etmektedir. Bu çok aşamalı derleme olarak bilinir ve ilk sürüm artık kullanılabilir!

ÖncekiSonraki