Artık DevOps'un konusu heyecan verici. Sürekli Entegrasyon ve Teslimat Boru Hattı herkes bunu uyguluyor. Ancak çoğu, CI/CD Boru Hattının çeşitli aşamalarında bilgi sistemlerinin güvenilirliğinin sağlanmasına her zaman gerekli özeni göstermez. Bu makalede, yazılım kalite kontrollerini otomatikleştirme ve yazılımın "kendi kendini iyileştirmesi" için olası senaryoları uygulama konusundaki deneyimimden bahsetmek istiyorum.
Bir şirketin BT hizmet yönetimi bölümünde mühendis olarak çalışıyorum . Temel uzmanlık alanım çeşitli uygulama performansı ve kullanılabilirlik izleme sistemlerinin uygulanmasıdır. BT hizmetlerinin kalitesinin izlenmesine ilişkin güncel konular hakkında farklı pazar segmentlerinden BT müşterileriyle sık sık iletişim kuruyorum. Ana amaç, salınım döngü süresini en aza indirmek ve salınım sıklığını arttırmaktır. Elbette ki bu iyi bir şey: daha fazla sürüm - daha fazla yeni özellik - daha memnun kullanıcılar - daha fazla kâr. Ancak gerçekte işler her zaman iyi gitmez. Çok yüksek dağıtım oranları nedeniyle, sürümlerimizin kalitesiyle ilgili soru hemen ortaya çıkıyor. Tam otomatik bir işlem hattında bile en büyük zorluklardan biri, uygulamanın çalışma süresini ve kullanıcı deneyimini etkilemeden hizmetleri testten üretime taşımaktır.
Müşterilerle yapılan çok sayıda görüşmenin sonuçlarına dayanarak, CI'nin çeşitli aşamalarında kalite kontrolü, uygulama güvenilirliği sorunu ve "kendi kendini iyileştirme" (örneğin, kararlı bir sürüme geri dönme) olasılığının olduğunu söyleyebilirim. /CD boru hattı en heyecan verici ve alakalı konular arasındadır.
Son zamanlarda ben de müşteri tarafında, çevrimiçi bankacılık uygulama yazılımı destek hizmetinde çalıştım. Uygulamamızın mimarisinde çok sayıda kendi yazdığımız mikro hizmet kullanıldı. En üzücü olan şey, tüm geliştiricilerin yüksek gelişme hızıyla baş edememesi, bazı mikro hizmetlerin kalitesinin düşmesi, hem kendileri hem de yaratıcıları için komik takma adların ortaya çıkmasına neden oldu. Bu ürünlerin hangi malzemelerden yapıldığına dair hikayeler vardı.
"Sorunun formülasyonu"
Sürümlerin yüksek sıklığı ve çok sayıda mikro hizmet, hem test aşamasında hem de operasyonel aşamada uygulamanın işleyişinin bir bütün olarak anlaşılmasını zorlaştırmaktadır. Değişiklikler sürekli meydana gelir ve iyi izleme araçları olmadan bunları kontrol etmek çok zordur. Çoğu zaman, sabahları yapılan bir gece sürümünden sonra geliştiriciler, test aşamasında tüm kontroller başarılı olmasına rağmen, barut fıçısının üzerinde oturur ve hiçbir şeyin kırılmamasını beklerler.
Bir nokta daha var. Test aşamasında yazılımın işlevselliği kontrol edilir: uygulamanın ana işlevlerinin uygulanması ve hataların olmaması. Niteliksel performans değerlendirmeleri ya eksiktir ya da uygulamanın ve entegrasyon katmanının tüm yönlerini dikkate almamaktadır. Bazı metrikler hiç kontrol edilmeyebilir. Sonuç olarak, bir üretim ortamında bir arıza meydana geldiğinde, teknik destek departmanı bunu ancak gerçek kullanıcılar şikayet etmeye başladığında öğrenir. Düşük kaliteli yazılımların son kullanıcılar üzerindeki etkisini en aza indirmek istiyorum.
Çözümlerden biri, CI/CD Pipeline'ın çeşitli aşamalarında yazılım kalitesini kontrol etmeye yönelik süreçleri uygulamak ve acil bir durumda sistemi geri yüklemek için çeşitli senaryolar eklemektir. Ayrıca DevOps'umuz olduğunu da hatırlıyoruz. İşletmeler yeni bir ürünü mümkün olan en kısa sürede almayı bekliyor. Bu nedenle tüm kontrollerimizin ve komut dosyalarımızın otomatikleştirilmesi gerekir.
Görev iki bileşene ayrılmıştır:
- test aşamasında montajların kalite kontrolü (düşük kaliteli montajları yakalama sürecini otomatikleştirmek için);
- üretim ortamında yazılım kalite kontrolü (sorunların otomatik olarak algılanması için mekanizmalar ve kendi kendini iyileştirmeye yönelik olası senaryolar).
Metrikleri izlemeye ve toplamaya yönelik araç
Belirlenen hedeflere ulaşmak için sorunları tespit edebilecek ve bunları CI/CD hattının çeşitli aşamalarında otomasyon sistemlerine aktarabilecek bir izleme sistemi gereklidir. Bu sistemin çeşitli ekipler için yararlı ölçümler sağlaması da olumlu olacaktır: geliştirme, test etme, operasyon. Ve aynı zamanda iş içinse kesinlikle harika.
Metrikleri toplamak için bir dizi farklı sistem kullanabilirsiniz (Prometheus, ELK Stack, Zabbix, vb.), ancak bence APM sınıfı çözümler bu görevler için en uygunudur (), hayatınızı büyük ölçüde kolaylaştırabilir.
Destek hizmetindeki çalışmamın bir parçası olarak Dynatrace'in APM sınıfı çözümünü kullanarak benzer bir proje yapmaya başladım. Artık bir entegratör için çalıştığım için izleme sistemleri pazarını oldukça iyi biliyorum. Kişisel görüşüm: Dynatrace bu tür sorunları çözmek için en uygunudur.
Dynatrace, kod yürütme düzeyine kadar her kullanıcı işleminin ayrıntılı bir düzeyde yatay bir görünümünü sağlar. Çeşitli bilgi hizmetleri arasındaki tüm etkileşim zincirini takip edebilirsiniz: web ve mobil uygulamaların ön uç seviyelerinden, arka uç uygulama sunucularına, entegrasyon veriyolundan veritabanına yapılan belirli bir çağrıya kadar.
. Sistem bileşenleri arasındaki tüm bağımlılıkların otomatik oluşturulması
. Hizmet operasyon yolunun otomatik tespiti ve oluşturulması
Ayrıca çeşitli otomasyon araçlarıyla entegrasyon yapmamız gerektiğini de hatırlıyoruz. Burada çözüm, çeşitli ölçümleri ve olayları gönderip almanıza olanak tanıyan kullanışlı bir API'ye sahiptir.
Daha sonra Dynatrace sistemini kullanarak bu sorunların nasıl çözüleceğine daha detaylı bir göz atalım.
Görev 1. Test aşamasında montajların kalite kontrolünün otomasyonu
İlk zorluk, uygulama dağıtım hattındaki sorunları mümkün olduğu kadar erken bulmaktır. Yalnızca "iyi" kod yapıları üretime ulaşmalıdır. Bunu yapmak için, test aşamasındaki işlem hattınızda hizmetlerinizin kalitesini kontrol edecek ek monitörler bulunmalıdır.
Bunu nasıl uygulayacağınıza ve bu süreci otomatikleştireceğinize adım adım bakalım:
Şekilde otomatik yazılım kalitesi test adımlarının akışı gösterilmektedir:
- bir izleme sisteminin konuşlandırılması (ajanların kurulumu);
- yazılımınızın kalitesinin değerlendirilmesine yönelik olayların (metrikler ve eşik değerler) belirlenmesi ve bunların izleme sistemine aktarılması;
- yük ve performans testlerinin oluşturulması;
- izleme sisteminde performans ve kullanılabilirlik verilerinin toplanması;
- yazılım kalitesi değerlendirme olaylarına dayalı test verilerinin izleme sisteminden CI/CD sistemine aktarılması. Montajların otomatik analizi.
Adım 1. İzleme sisteminin konuşlandırılması
Öncelikle aracıları test ortamınıza yüklemeniz gerekir. Aynı zamanda, Dynatrace çözümünün güzel bir özelliği var - bir işletim sistemi örneğine (Windows, Linux, AIX) yüklenen evrensel aracı OneAgent'ı kullanıyor, hizmetlerinizi otomatik olarak algılıyor ve bunlar üzerinde izleme verileri toplamaya başlıyor. Her işlem için ayrı bir aracı yapılandırmanıza gerek yoktur. Bulut ve konteyner platformları için de durum benzer olacak. Aynı zamanda aracı kurulum işlemini de otomatikleştirebilirsiniz. Dynatrace "kod olarak altyapı" konseptine mükemmel bir şekilde uyar (): Tüm popüler platformlar için hazır scriptler ve talimatlar bulunmaktadır. Aracıyı hizmetinizin yapılandırmasına yerleştirirsiniz ve dağıttığınızda, halihazırda çalışan bir aracıyla hemen yeni bir hizmet alırsınız.
2. Adım: Yazılım kalitesi olaylarınızı tanımlayın
Artık hizmetlerin ve ticari operasyonların listesine karar vermeniz gerekiyor. Hizmetiniz için iş açısından kritik olan kullanıcı işlemlerini tam olarak hesaba katmak önemlidir. Burada iş ve sistem analistlerine danışmanızı öneririm.
Daha sonra, her düzey için incelemeye hangi metrikleri dahil etmek istediğinizi belirlemeniz gerekir. Örneğin, bu yürütme süresi (ortalama, medyan, yüzdelik dilimlere vb. bölünmüş), hatalar (mantıksal, hizmet, altyapı vb.) ve çeşitli altyapı ölçümleri (bellek yığını, çöp toplayıcı, iş parçacığı sayısı vb.) olabilir.
DevOps ekibinin otomasyonu ve kullanım kolaylığı için “Kod Olarak İzleme” kavramı ortaya çıkıyor. Bununla kastettiğim, bir geliştiricinin/testçinin yazılım kalite güvence ölçümlerini tanımlayan basit bir JSON dosyası yazabilmesidir.
Böyle bir JSON dosyası örneğine bakalım. Dynatrace API'sindeki nesneler anahtar/değer çiftleri olarak kullanılır (API açıklaması burada bulunabilir) ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}Dosya, zaman serisi tanımlarının bir dizisidir:
- timeseriesId – kontrol edilen ölçüm; örneğin, Yanıt Süresi, Hata sayısı, Kullanılan bellek vb.;
- toplama - metrik toplama düzeyi, bizim durumumuzda ortalama, ancak ihtiyacınız olan herhangi birini kullanabilirsiniz (ortalama, minimum, maksimum, toplam, sayım, yüzdelik dilim);
- etiketler – izleme sistemindeki nesne etiketi veya belirli bir nesne tanımlayıcısını belirleyebilirsiniz;
- şiddetli ve uyarı – bu göstergeler metriklerimizin eşik değerlerini düzenler; test değeri şiddetli eşiği aşarsa yapımız başarılı değil olarak işaretlenir.
Aşağıdaki şekil bu tür eşiklerin kullanımına ilişkin bir örneği göstermektedir.
Adım 3: Yük Oluşturma
Hizmetimizin kalite seviyelerini belirledikten sonra bir test yükü oluşturmamız gerekiyor. Jmeter, Selenium, Neotys, Gatling vb. gibi rahat ettiğiniz test araçlarından herhangi birini kullanabilirsiniz.
Dynatrace'in izleme sistemi, testlerinizden çeşitli meta veriler yakalamanıza ve hangi testlerin hangi sürüm döngüsüne ve hangi hizmete ait olduğunu anlamanıza olanak tanır. HTTP test isteklerine ek başlıklar eklenmesi önerilir.
Aşağıdaki şekil, ek X-Dynatrace-Test başlığını kullanarak bu testin sepete bir öğe ekleme işleminin test edilmesiyle ilgili olduğunu belirttiğimiz bir örneği göstermektedir.
Her yük testini çalıştırdığınızda, CI/CD sunucusundan Event API'yi kullanarak Dynatrace'e ek bağlamsal bilgiler gönderirsiniz. Bu şekilde sistem farklı testler arasında ayrım yapabilir.
. İzleme sisteminde yük testinin başlamasıyla ilgili olay
Adım 4-5. Performans verilerini toplayın ve verileri CI/CD sistemine aktarın
Oluşturulan testle birlikte, izleme sistemine hizmet kalitesi göstergelerinin kontrolüne ilişkin veri toplama ihtiyacına ilişkin bir olay iletilir. Ayrıca temel ölçümleri tanımlayan JSON dosyamızı da belirtir.
İzleme sistemine gönderilmek üzere CI/CD sunucusunda oluşturulan yazılımın kalitesinin kontrol edilmesi ihtiyacına ilişkin olay
Örneğimizde kalite kontrol olayının adı perfSigDynatrace Raporu (Performans_İmza) - bu hazır T-Systems Multimedya Çözümleri'ndeki adamlar tarafından geliştirilen Jenkins ile entegrasyon için. Her test başlatma etkinliği, hizmet, yapı numarası ve test süresi hakkında bilgiler içerir. Eklenti, derleme sırasında performans değerlerini toplar, bunları değerlendirir ve sonucu önceki derlemelerle ve işlevsel olmayan gereksinimlerle karşılaştırır.
İzleme sisteminde yapı kalitesi kontrolünün başlatılmasıyla ilgili olay.
Test tamamlandıktan sonra, yazılım kalitesini değerlendirmeye yönelik tüm ölçümler, sonuçlar hakkında bir rapor oluşturan Jenkins gibi sürekli bir entegrasyon sistemine geri aktarılır.
CI/CD sunucusundaki derlemelere ilişkin istatistiklerin sonucu.
Her bir yapı için, testin tamamı boyunca belirlediğimiz her metriğin istatistiklerini görüyoruz. Ayrıca belirli eşik değerlerinde (uyarı ve ciddi eşik değerleri) ihlal olup olmadığına da bakıyoruz. Toplu metriklere göre yapının tamamı kararlı, kararsız veya başarısız olarak işaretlenir. Ayrıca kolaylık olması açısından rapora mevcut yapıyı önceki yapıyla karşılaştıran göstergeler ekleyebilirsiniz.
CI/CD sunucusundaki derlemelere ilişkin ayrıntılı istatistikleri görüntüleyin.
İki montajın ayrıntılı karşılaştırması
Gerekirse Dynatrace arayüzüne gidebilir ve burada her yapınızın istatistiklerini daha ayrıntılı olarak görüntüleyebilir ve bunları birbirleriyle karşılaştırabilirsiniz.
Dynatrace'teki derleme istatistiklerinin karşılaştırılması.
Bulgular
Sonuç olarak, sürekli entegrasyon hattında otomatikleştirilmiş bir "hizmet olarak izleme" hizmeti alıyoruz. Geliştiricinin veya testçinin yalnızca bir JSON dosyasında bir metrik listesi tanımlaması gerekir ve geri kalan her şey otomatik olarak gerçekleşir. Sürümlerin şeffaf kalite kontrolünü alıyoruz: performans, kaynak tüketimi veya mimari gerilemelerle ilgili tüm bildirimler.
Görev 2. Üretim ortamında yazılım kalite kontrolünün otomasyonu
Böylece Pipeline'da test aşamasında izleme sürecinin nasıl otomatikleştirileceği sorununu çözmüş olduk. Bu şekilde üretim ortamına ulaşan düşük kaliteli montajların yüzdesini en aza indiriyoruz.
Ancak kötü yazılım satılırsa veya bir şey bozulursa ne yapmalısınız? Bir ütopya için, mekanizmaların sorunları otomatik olarak tespit etmesini ve mümkünse sistemin kendisinin en azından geceleri işlevselliğini geri kazanmasını istedik.
Bunu yapmak için, önceki bölüme benzer şekilde, üretim ortamında otomatik yazılım kalite kontrolleri sağlamamız ve bunları sistemin kendi kendini iyileştirmesine yönelik senaryolara dayandırmamız gerekiyor.
Kod olarak otomatik düzeltme
Çoğu şirket halihazırda çeşitli türde yaygın sorunlara ilişkin birikmiş bir bilgi tabanına ve bunları düzeltmeye yönelik bir eylem listesine sahiptir; örneğin; süreçleri yeniden başlatmak, kaynakları temizlemek, sürümleri geri almak, geçersiz yapılandırma değişikliklerini geri yüklemek, sistemdeki bileşenlerin sayısını artırmak veya azaltmak. küme, mavi veya yeşil ana hatların değiştirilmesi vb.
Bu kullanım senaryoları konuştuğum ekiplerin çoğu tarafından yıllardır biliniyor olsa da çok azı bunları otomatikleştirmeyi düşündü veya buna yatırım yaptı.
Düşünürseniz, kendi kendini iyileştiren uygulama performansına yönelik süreçlerin uygulanmasında aşırı karmaşık bir şey yoktur; yöneticilerinizin zaten bilinen çalışma senaryolarını kod komut dosyaları ("kod olarak otomatik düzeltme" kavramı) biçiminde sunmanız gerekir. , her özel durum için önceden yazdığınız. Otomatik onarım komut dosyaları, sorunun temel nedenini ortadan kaldırmayı amaçlamalıdır. Bir olaya müdahale etmek için doğru eylemleri kendiniz belirlersiniz.
İzleme sisteminizden gelen herhangi bir ölçüm, betiği başlatmak için tetikleyici görevi görebilir; asıl önemli olan, üretken bir ortamda yanlış pozitifler almak istemeyeceğiniz için bu ölçümlerin her şeyin kötü olduğunu doğru bir şekilde belirlemesidir.
Herhangi bir sistemi veya sistem setini kullanabilirsiniz: Prometheus, ELK Stack, Zabbix, vb. Ancak APM çözümüne dayanan bazı örnekler vereceğim (Dynatrace yine bir örnek olacak), aynı zamanda hayatınızı kolaylaştırmaya da yardımcı olacak.
Öncelikle uygulamanın işleyişi açısından performansla ilgili her şey var. Çözüm, tetikleyici olarak kullanabileceğiniz çeşitli düzeylerde yüzlerce ölçüm sağlar:
- kullanıcı düzeyi (tarayıcılar, mobil uygulamalar, IoT cihazları, kullanıcı davranışı, dönüşüm vb.);
- hizmet ve operasyon düzeyi (performans, kullanılabilirlik, hatalar vb.);
- uygulama altyapısı düzeyi (ana işletim sistemi ölçümleri, JMX, MQ, web sunucusu vb.);
- platform düzeyinde (sanallaştırma, bulut, konteyner vb.).
Dynatrace'te seviyelerin izlenmesi.
İkincisi, daha önce de söylediğim gibi Dynatrace'in açık bir API'si var, bu da çeşitli üçüncü taraf sistemlerle entegrasyonu çok kolaylaştırıyor. Örneğin kontrol parametreleri aşıldığında otomasyon sistemine bildirim gönderilmesi.
Aşağıda Ansible ile etkileşim kurmaya yönelik bir örnek bulunmaktadır.
Aşağıda ne tür otomasyon yapılabileceğine dair birkaç örnek vereceğim. Bu vakaların sadece bir kısmı; ortamınızdaki bunların listesi yalnızca sizin hayal gücünüz ve izleme araçlarınızın yetenekleriyle sınırlanabilir.
1. Kötü dağıtım – sürümün geri alınması
Her şeyi bir test ortamında çok iyi bir şekilde test etsek bile, yeni bir sürümün uygulamanızı üretim ortamında sonlandırması ihtimali hala mevcuttur. Aynı insan faktörü iptal edilmedi.
Aşağıdaki şekilde servisteki işlemlerin yürütme süresinde keskin bir sıçrama olduğunu görüyoruz. Bu sıçramanın başlangıcı uygulamaya dağıtım zamanına denk geliyor. Tüm bu bilgileri olay olarak otomasyon sistemine aktarıyoruz. Belirlediğimiz süre sonunda hizmetin performansı normale dönmezse, otomatik olarak sürümü eski sürüme döndüren bir komut dosyası çağrılır.
Dağıtımdan sonra operasyon performansının düşmesi.
2. %100'de kaynak yükleme - yönlendirmeye bir düğüm ekleyin
Aşağıdaki örnekte izleme sistemi, bileşenlerden birinin %100 CPU yükü yaşadığını belirliyor.
CPU yükü %100
Bu olay için birkaç farklı senaryo mümkün. Örneğin, izleme sistemi ayrıca kaynak eksikliğinin hizmet üzerindeki yükteki artışla ilişkili olup olmadığını da kontrol eder. Eğer öyleyse, yönlendirmeye otomatik olarak bir düğüm ekleyen ve böylece sistemin işlevselliğini bir bütün olarak geri yükleyen bir komut dosyası yürütülür.
Bir olaydan sonra ölçeklendirme
3. Sabit sürücüde yer eksikliği - disk temizliği
Pek çok kişinin bu süreçleri zaten otomatikleştirdiğini düşünüyorum. APM'yi kullanarak disk alt sistemindeki boş alanı da izleyebilirsiniz. Boş alan yoksa veya disk yavaş çalışıyorsa, onu temizlemek veya alan eklemek için bir komut dosyası çağırırız.
Disk yükü %100
4. Düşük kullanıcı etkinliği veya düşük dönüşüm - mavi ve yeşil dallar arasında geçiş
Müşterilerin üretim ortamındaki uygulamalar için sıklıkla iki döngü (mavi-yeşil dağıtım) kullandığını görüyorum. Bu, yeni sürümleri yayınlarken şubeler arasında hızla geçiş yapmanıza olanak tanır. Çoğu zaman, dağıtımdan sonra hemen fark edilmeyen dramatik değişiklikler meydana gelebilir. Bu durumda performansta ve kullanılabilirlikte bozulma görülmeyebilir. Bu tür değişikliklere hızlı bir şekilde yanıt verebilmek için kullanıcı davranışını yansıtan çeşitli metrikleri (oturum sayısı ve kullanıcı işlemleri, dönüşüm, hemen çıkma oranı) kullanmak daha iyidir. Aşağıdaki şekil, dönüşüm oranları düştüğünde yazılım dalları arasında geçişin gerçekleştiği bir örneği göstermektedir.
Yazılım dalları arasında geçiş yapıldıktan sonra dönüşüm oranı düşüyor.
Otomatik sorun tespiti mekanizmaları
Son olarak Dynatrace'i neden en çok sevdiğime dair bir örnek daha vereceğim.
Hikayemin test ortamında montajların kalite kontrollerinin otomatikleştirilmesiyle ilgili kısmında tüm eşik değerlerini manuel olarak belirledik. Bu durum bir test ortamı için normaldir; her testten önce yüke bağlı olarak göstergeleri test eden kişi kendisi belirler. Bir üretim ortamında, çeşitli temel mekanizmalar dikkate alınarak sorunların otomatik olarak tespit edilmesi arzu edilir.
Dynatrace, anormal metrikleri belirleme (temel belirleme) ve tüm bileşenler arasında bir etkileşim haritası oluşturmaya, olayları birbirleriyle karşılaştırmaya ve ilişkilendirmeye yönelik mekanizmalara dayalı, hizmetinizin işleyişindeki anormallikleri belirleyen ve ayrıntılı bilgi sağlayan ilginç yerleşik yapay zeka araçlarına sahiptir. Her sorun ve temel nedeni hakkında bilgi.
Dynatrace, bileşenler arasındaki bağımlılıkları otomatik olarak analiz ederek yalnızca sorunlu hizmetin temel neden olup olmadığını değil, aynı zamanda diğer hizmetlere bağımlılığını da belirler. Aşağıdaki örnekte Dynatrace, işlemin yürütülmesi sırasında her hizmetin durumunu otomatik olarak izler ve değerlendirir, temel neden olarak Golang hizmetini belirler.
Bir arızanın temel nedenini belirlemeye bir örnek.
Aşağıdaki şekil, bir olayın başlangıcından itibaren uygulamanızdaki sorunların izlenmesi sürecini göstermektedir.
Ortaya çıkan bir sorunun, üzerlerindeki tüm bileşenlerin ve olayların görüntülenmesiyle görselleştirilmesi
İzleme sistemi, ortaya çıkan sorunla ilgili olayların tam bir kronolojisini topladı. Zaman çizelgesinin altındaki pencerede her bir bileşendeki tüm önemli olayları görüyoruz. Bu olaylara dayanarak, otomatik düzeltme prosedürlerini kod komut dosyaları biçiminde ayarlayabilirsiniz.
Ek olarak, bir izleme sistemini Service Desk veya bir hata izleyiciyle entegre etmenizi tavsiye ederim. Bir sorun oluştuğunda geliştiriciler, sorunu üretim ortamında kod düzeyinde analiz etmek için hızlı bir şekilde eksiksiz bilgi alırlar.
Sonuç
Sonuç olarak Pipeline'da yerleşik otomatik yazılım kalite kontrollerine sahip bir CI/CD hattına sahip olduk. Düşük kaliteli montajların sayısını en aza indiriyoruz, bir bütün olarak sistemin güvenilirliğini artırıyoruz ve sistemimiz hala arızalanırsa onu geri yüklemek için mekanizmalar başlatıyoruz.
Yazılım kalitesi izlemeyi otomatikleştirmek için çaba harcamaya kesinlikle değer; bu her zaman hızlı bir süreç değildir, ancak zamanla meyvesini verecektir. Üretim ortamında yeni bir olayı çözdükten sonra, kötü bir yapının üretime girmesini önlemek için test ortamındaki kontroller için hangi monitörleri ekleyeceğinizi hemen düşünmenizi ve ayrıca bu sorunları otomatik olarak düzeltmek için bir komut dosyası oluşturmanızı öneririm.
Örneklerimin çalışmalarınızda size yardımcı olacağını umuyorum. Kendi kendini onaran sistemleri uygulamak için kullanılan ölçüm örneklerinizi de görmek isterim.
Kaynak: habr.com