DevOps

İpucu

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

PDF'i indirin

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ı.

Bulutta yerel uygulamalar aynı dikotomiye karşı bağışıklığı yoktur. 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'un yeşil günlerinden önce kabul edilebilir olan sürümlerin temposu hakkında fikir edinmek için Microsoft Windows'tan başka bir yere bakılmaması gerekir. Windows XP ve Vista arasında beş yıl, Vista ile Windows 7 arasında üç yıl daha geçti.

Yazılımlarını hızlı bir şekilde yayınlayabilmek, hızlı hareket eden şirketlere daha sloth benzeri rakiplerine kıyasla büyük bir pazar avantajı sağlıyor. 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 (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 sıkı tümleştirmeyi destekleyen bir derleme 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, iç, NuGet, npm ve diğer sürümlerini oluşturmasına olanak tanıyan bir yapıt akışı. 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 Actions

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. Daha sonra hata izleme, özellik ve çekme istekleri, görev yönetimi ve her kod tabanı için wiki'ler gibi kendi özellik kümesini ekler.

GitHub geliştikçe DevOps özellikleri de ekleniyor. Örneğin GitHub'ın adlı GitHub Actionskendi 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 hattı desteği vardı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 - Bir ve birçok depo.

Mikro hizmet 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. Depoları çevirirken bu yönergeleri bulmak kolaydır ve geliştiriciler için dönüş süresini kısaltabilirsiniz.
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. Gibi create-react-app bir şeyin yeni bir yüklemesinin yanında binlerce paket getirmesi olasıdır. 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ışmalarını alır, böylece dizin her biri biraz farklı bir tempoda node_modules 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 üretime geldiğinde üretimde olma olasılığı yüksek olan 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. Kitaplıklar için derlemeler, iç tüketim için en son sürümlerini Azure Artifacts'e gönderecektir. Aşağı akış projesi, yeni güncelleştirilen paketlere bağımlılık sağlamak için el ile güncelleştirilmelidir.

Kod hizmetler arasında taşınırken başka bir dezavantaj ortaya koyan bir diğer dezavantajdır. Bir uygulamanın mikro hizmetlere ilk bölümünün %100 doğru olduğuna inanmak güzel olsa da, gerçek şu ki nadiren hizmet bölümü hatası yapmamaya çok önceden karar verdik. 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, aynı anda birden çok depoyu geçen bir değişiklik yapmak istendiğinde. 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.

Depolar arası bir değişiklik yapmak için her depoya ardı ardına bir işleme 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ış yapıt akışlarına güvenmek yerine doğrudan birbiriyle içeri 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, içindeki sorunları bulmak için her deponun yinelenmelidir. 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. Bir deponun içeriği hizmet modeli başına depoya sızdırılırsa, kaybedilen kod miktarı çok azdır. 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 depo kullanma bağımsız değişkeni, Facebook veya Google'ın kaynak kodu düzenlemesi için bu yöntemi kullandığı bir bağımsız değişkene kadar iner. 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ışma yönetimi ve mühendislik ek yükü, daha az avantaj elde etmeye değmez. Kodun birden çok depoya bölünmesi, endişelerin daha iyi ayrılmalarını teşvik eder ve geliştirme ekipleri arasında özerkliği 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 BENİOKU dosyası ve gibi yararlı öğeleri de azure-pipelines.ymliç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, çeşitli bileşenlerde sorunların bozulmasına 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 gereken tek şey kapsam içinde neler olduğu, insanların ne üzerinde çalıştığı ve yapılanlardır. İş ö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 , doingve donegibi to dobasit bir işleme yapışır. kişilerin sürece veya Detailed Specification gibi QA adımlar eklemeye başlaması uzun sürmez.

Çevik metodolojilerinin en önemli parçalarından biri, düzenli aralıklarla kendi kendine giriştir. 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. İlk çalıştırmada bir görev başlık, açıklama, öncelik, kalan çalışma miktarı tahmini ve diğer iş öğelerine veya geliştirme öğelerine (dallar, işlemeler, çekme istekleri, derlemeler vb.) bağlanma olanağı için 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ı beklediğiniz normal stilleri (kalın, italik alt çizgi ve üstü çizili) ve görüntü 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 de epic'lere toplanabilir. 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 sorunlarla ilgili farklı görünüm türleri vardır. Henüz zamanlanmamış öğeler kapsam içinde görünür. Buradan bir sprint'e atanabilir. Sprint, bir miktar çalışmanın tamamlanması beklenen bir zaman kutusudur. Bu çalışma görevlerin yanında biletlerin çözünürlüğünü 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 olmadığını sürekli güncelleştiren bir tahmin sağlamak için bir yazma 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 işlem 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 iade edilir edilmez projenin kaynak koduna göre otomatikleştirilmiş testler oluşturmak ve çalıştırmak hataları erken yakalar. Sürekli tümleştirme derlemelerinin ortaya çıkmasından önce, depodan kod çekmek ve testlerden geçmediğini, hatta oluşturulamazdı. 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 tümleştirmenin kız kardeşi, yeni oluşturulan paketlerin bir ortama dağıtıldığı sürekli teslimdir. 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 sürekli teslimle yakalaması gibi dağıtım sürecindeki sorunları da 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şir, bu nedenle kenarlıkları el ile dağıtmak imkansızdır.

Azure Derlemeleri

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 i Telefon geliştirmeye 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ı, derleme oluşturmayı lego kümesi oluşturmak kadar basit hale getiren (dev Millennium Falcon'dan daha basit) bir dizi yerleşik görev kullanır. Ö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, iadeyle, zamanlamaya göre veya başka bir derlemenin tamamlanmasıyla tetiklenebilir. Çoğu durumda, her iadeyi derlemek tercih edilir. Derlemeler filtrelenebilir, böylece farklı derlemeler deponun farklı bölümlerine veya farklı dallara göre çalışır. Bu, çekme isteklerinde daha az testle hızlı derlemeler çalıştırma ve her gece gövdeye karşı tam regresyon paketi çalıştırma gibi senaryolara olanak tanır.

Derlemenin sonucu, derleme yapıtları 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 kullanılabilen ancak "aşamalar" kavramını tanıtırken aynı görevlerin kitaplığını kullanı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 yayından geçtikten sonra el ile test için Soru-Cevap 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 üretime geçmeden önce yayında oturumunu kapatması gereken şekilde ayarlanabilir. Bu kapılar, el ile kalite kontrolleri ve üretime girenleri kontrol etmeyle ilgili tüm mevzuat gereksinimleriyle uyumluluk sağlar.

Herkes bir derleme işlem hattı alır

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ı, iade edilmiş azure-pipelines.yml bir dosyada tanımlanamaz olması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!

Geriİleri