DevOps uygulamaları işe yarıyor. Sürüm kurulum süresini 10 kat kısalttığımızda buna biz de ikna olduk. VTB'de kullandığımız FIS Profil sisteminde kurulum artık 90 dakika yerine 10 dakika sürüyor. Sürüm oluşturma süresi iki haftadan iki güne düştü. Kalıcı uygulama hatalarının sayısı neredeyse minimuma düştü. "El emeği"nden uzaklaşmak ve satıcıya bağımlılığı ortadan kaldırmak için koltuk değnekleriyle çalışıp beklenmedik çözümler bulmamız gerekiyordu. Kesimin altında tam teşekküllü bir şirket içi geliştirmeyi nasıl inşa ettiğimize dair ayrıntılı bir hikaye var.
Giriş: DevOps bir felsefedir
Geçtiğimiz yıl boyunca VTB'de DevOps uygulamalarının dahili gelişimini ve uygulanmasını organize etmek için birçok çalışma yaptık:
- 12 sistem için iç geliştirme süreçleri oluşturduk;
- 15 boru hattını devreye aldık, bunlardan dördünü üretime aldık;
- Otomatik 1445 test senaryosu;
- Şirket içi ekipler tarafından hazırlanan bir dizi sürümü başarıyla uyguladık.
DevSecOps uygulamalarının kurum içi geliştirilmesi ve uygulanmasının organize edilmesi en zor olanlardan birinin, ilişkisel olmayan bir DBMS üzerindeki perakende ürün işlemcisi olan FIS Profil sistemi olduğu ortaya çıktı. Bununla birlikte, geliştirmeyi oluşturabildik, üretim hattını başlatabildik, ürüne ayrı ayrı yayınlanmayan paketleri yükleyebildik ve sürümlerin nasıl birleştirileceğini öğrendik. Görev kolay değildi, ancak ilginçti ve uygulamada bariz kısıtlamalar yoktu: işte sistem - şirket içi bir geliştirme oluşturmanız gerekiyor. Verimli bir ortamdan önce tek koşul CD'yi kullanmaktır.
İlk başta uygulama algoritması basit ve anlaşılır görünüyordu:
- İlk geliştirme uzmanlığını geliştiriyoruz ve büyük kusurlar olmaksızın kod ekibinden kabul edilebilir bir kalite düzeyi elde ediyoruz;
- Mümkün olduğunca mevcut süreçlere entegre oluyoruz;
- Kodu bariz aşamalar arasında aktarmak için bir boru hattını keseriz ve uçlarından birini devamına doğru iteriz.
Bu süre zarfında gerekli büyüklükteki geliştirme ekibinin becerilerini geliştirmesi ve sürümlere olan katkı payını kabul edilebilir bir düzeye çıkarması gerekir. İşte bu kadar, görevi tamamlanmış sayabiliriz.
Görünüşe göre bu, istenen sonuca giden tamamen enerji açısından verimli bir yol: işte DevOps, işte ekibin performans ölçümleri, işte birikmiş uzmanlık... Ancak pratikte, DevOps'un hâlâ felsefeyle ilgili olduğuna dair başka bir onay aldık. , ve "gitlab sürecine bağlı, ansible, nexus ve listenin daha aşağılarında" değil.
Eylem planını bir kez daha analiz ettiğimizde kendi içimizde bir nevi dış kaynak sağlayıcısı inşa ettiğimizi fark ettik. Bu nedenle, yukarıda açıklanan algoritmaya süreç yeniden yapılandırması ve bu süreçte lider bir rol elde etmek için tüm geliştirme rotası boyunca uzmanlığın geliştirilmesi eklendi. En kolay seçenek değil ama ideolojik olarak doğru gelişmenin yolu budur.
Kurum içi geliştirme nerede başlar?
Çalışması en kolay sistem değildi. Mimari olarak, gerektiğinde çağrılan birçok ayrı yürütülebilir nesneden (komut dosyaları, prosedürler, gruplar vb.) oluşan, ilişkisel olmayan büyük bir DBMS'ydi ve kara kutu prensibiyle çalışıyordu: bir istek alır ve yayınlar. cevap. Dikkate değer diğer zorluklar şunlardır:
- Egzotik dil (Kabakulak);
- Konsol arayüzü;
- Popüler otomasyon araçları ve çerçeveleriyle entegrasyon eksikliği;
- Onlarca terabayt cinsinden veri hacmi;
- Saatte 2 milyondan fazla işlemin yükü;
- Önem - İş Açısından Kritik.
Aynı zamanda bizim tarafımızda kaynak kod deposu da yoktu. Kesinlikle. Belgeler vardı ancak tüm temel bilgi ve yeterlilikler harici bir organizasyonun tarafındaydı.
Özelliklerini ve düşük dağıtımını dikkate alarak sistemin geliştirilmesine neredeyse sıfırdan hakim olmaya başladık. Ekim 2018'de başladı:
- Kod oluşturmanın belgelerini ve temellerini inceledi;
- Satıcıdan alınan geliştirmeyle ilgili kısa kursu inceledik;
- Başlangıç geliştirme becerilerinde uzmanlaştık;
- Yeni ekip üyeleri için bir eğitim kılavuzu hazırladık;
- Ekibi "savaş" moduna dahil etmeye karar verdik;
- Kod kalite kontrolüyle ilgili sorun çözüldü;
- Gelişime yönelik bir stant düzenledik.
Uzmanlığımızı geliştirmek ve kendimizi sisteme kaptırmak için üç ay harcadık ve 2019'un başından itibaren şirket içi geliştirme, bazen zorlukla ama kendinden emin ve kararlı bir şekilde parlak bir geleceğe doğru ilerlemeye başladı.
Depo geçişi ve otomatik testler
İlk DevOps görevi depodur. Erişim sağlama konusunda hızlı bir şekilde anlaştık, ancak birkaç daldan oluşan bir modele geçiş ve Git Flow'un geliştirilmesiyle tek trunk dallı mevcut SVN'den hedef Git'e geçiş yapmak gerekliydi. Ayrıca kendi altyapılarına sahip 2 ekibimiz ve yurtdışındaki satıcı ekibinin bir kısmı var. İki Git ile birlikte yaşamak ve senkronizasyonu sağlamak zorundaydım. Böyle bir durumda iki kötülükten daha azıydı.
Deponun taşınması defalarca ertelendi; ön cephedeki meslektaşların yardımıyla ancak Nisan ayında tamamlandı. Git Flow ile başlangıçta işleri basit tutmaya karar verdik ve düzeltme, geliştirme ve yayınlama ile klasik şemaya yerleştik. Ustayı terk etmeye karar verdiler (diğer adıyla dürtük gibi). Aşağıda bu seçeneğin neden bizim için en uygun olduğunu açıklayacağız. Çalışan olarak, satıcıya ait olan ve iki ekip için ortak olan harici bir depo kullanıldı. Bir programa göre dahili depoyla senkronize edildi. Artık Git ve Gitlab ile süreçleri otomatikleştirmek mümkündü.
Otomatik testler sorunu şaşırtıcı derecede kolay bir şekilde çözüldü - bize hazır bir çerçeve sağlandı. Sistemin özellikleri dikkate alındığında, ayrı bir operasyonun çağrılması iş sürecinin anlaşılır bir parçasıydı ve aynı zamanda birim testi görevi görüyordu. Geriye kalan tek şey test verilerini hazırlamak ve komut dosyalarının çağrılması ve sonuçların değerlendirilmesi için istenen sırayı ayarlamaktı. Operasyon istatistikleri, süreçlerin kritikliği ve mevcut regresyon metodolojisi baz alınarak oluşturulan senaryo listesi doldukça otomatik testler ortaya çıkmaya başladı. Artık boru hattını inşa etmeye başlayabiliriz.
Nasıldı: Otomasyondan önceki model
Uygulama sürecinin mevcut modeli ayrı bir hikaye. Her değişiklik, ayrı bir artımlı kurulum paketi olarak manuel olarak aktarıldı. Daha sonra Jira'ya manuel kayıt ve ortamlara manuel kurulum geldi. Bireysel paketler için her şey net görünüyordu ancak sürümün hazırlanmasıyla işler daha karmaşık hale geldi.
Montaj, bağımsız nesneler olan bireysel teslimatlar düzeyinde gerçekleştirildi. Herhangi bir değişiklik yeni bir teslimattır. Diğer şeylerin yanı sıra, ana sürüm bileşiminin 60-70 paketine 10-15 teknik sürüm eklendi - sürümden bir şey eklenirken veya çıkarıldığında elde edilen ve sürümler dışındaki satışlardaki değişiklikleri yansıtan sürümler.
Teslimatlardaki nesneler, özellikle yarıdan daha az benzersiz olan yürütülebilir kodda birbiriyle örtüşüyordu. Hem halihazırda kurulu olan koda hem de kurulumu yeni planlanan koda birçok bağımlılık vardı.
Kodun gerekli sürümünü elde etmek için, nesnelerin fiziksel olarak birçok kez, yaklaşık 10-12 kez yeniden yazıldığı kurulum sırasını sıkı bir şekilde takip etmek gerekiyordu.
Bir paket paketi yükledikten sonra ayarları başlatmak için talimatları manuel olarak takip etmek zorunda kaldım. Sürüm satıcı tarafından toplandı ve kuruldu. Sürümün bileşimi, "ayrılma" paketlerinin oluşturulmasını gerektiren uygulama anından hemen önce netleştirildi. Sonuç olarak, tedariklerin önemli bir kısmı, kendi “ayrışma” kuyruğuyla, sürümden sürüme geçti.
Artık bu yaklaşımla (sürüm bulmacasını paket seviyesinde bir araya getirmenin) tek bir ana dalın pratik bir anlamı olmadığı açıktır. Üretimde kurulum bir buçuk ila iki saatlik manuel işçilik gerektirdi. En azından kurulumcu düzeyinde nesne işleme sırasının belirlenmiş olması iyidir: alanlar ve yapılar, onlar için verilerden ve prosedürlerden önce girilmiştir. Ancak bu yalnızca ayrı bir pakette işe yaradı.
Bu yaklaşımın mantıksal sonucu, nesnelerin çarpık versiyonları, gereksiz kodlar, eksik talimatlar ve serbest bırakıldıktan sonra hararetle ortadan kaldırılan nesnelerin karşılıklı etkilerinin hesaba katılmaması şeklindeki zorunlu kurulum kusurlarıydı.
İlk güncellemeler: montaj ve teslimatı taahhüt etme
Otomasyon, kodun bu rota boyunca bir boru aracılığıyla iletilmesiyle başladı:
- Bitmiş teslimatı depodan alın;
- Özel bir ortama yükleyin;
- Otomatik testleri çalıştırın;
- Kurulum sonucunu değerlendirin;
- Test komutunun yanında aşağıdaki boru hattını çağırın.
Bir sonraki işlem hattı, görevi Jira'ya kaydetmeli ve görev uygulamasının zamanlamasına bağlı olarak komutların seçilen test döngülerine dağıtılmasını beklemelidir. Tetikleyici - belirli bir adrese teslimata hazır olunduğuna dair bir mektup. Bu elbette bariz bir destekti ama bir yerden başlamam gerekiyordu. Mayıs 2019'da ortamlarımızda yapılan kontrollerle kod aktarımına başlandı. Süreç başladı, geriye kalan tek şey onu düzgün bir şekle getirmek:
- Her değişiklik, kurulum paketine karşılık gelen ve hedef ana dalla birleşen ayrı bir dalda gerçekleştirilir;
- Boru hattı başlatma tetikleyicisi, şirket içi ekipteki bakımcılar tarafından kapatılan bir birleştirme isteği aracılığıyla ana dalda yeni bir taahhüdün ortaya çıkmasıdır;
- Depolar her beş dakikada bir senkronize edilir;
- Satıcıdan alınan derleyici kullanılarak kurulum paketinin montajı başlatılır.
Bundan sonra, kodu kontrol etmek ve aktarmak, boruyu başlatmak ve bizim tarafımızda montaj yapmak için zaten mevcut adımlar vardı.
Bu seçenek Temmuz ayında kullanıma sunuldu. Geçişin zorlukları satıcı ve ön saflarda bir miktar memnuniyetsizliğe yol açtı, ancak önümüzdeki ay tüm pürüzleri ortadan kaldırmayı ve ekipler arasında bir süreç oluşturmayı başardık. Artık taahhüt ve teslimat yoluyla montajımız var.
Ağustos ayında, üretim hattımızı kullanarak ayrı bir paketin üretimdeki ilk kurulumunu tamamlamayı başardık ve Eylül ayından bu yana, istisnasız, yayınlanmayan bireysel paketlerin tüm kurulumları CD aracımız aracılığıyla gerçekleştirildi. Ek olarak, satıcıdan daha küçük bir ekiple kurum içi görevlerin sürüm kompozisyonunun %40'ında pay sahibi olmayı başardık - bu kesin bir başarıdır. Geriye en ciddi görev kaldı - sürümün montajı ve kurulumu.
Nihai çözüm: toplu kurulum paketleri
Satıcının talimatlarını yazmanın şöyle böyle bir otomasyon olduğunu çok iyi anladık; sürecin kendisini yeniden düşünmemiz gerekiyordu. Çözüm açıktı: sürüm şubesinden gerekli sürümlerin tüm nesnelerini içeren kümülatif bir tedarik toplamak.
Konsept kanıtıyla başladık: Sürüm paketini geçmiş uygulamanın içeriğine göre elle derledik ve ortamlarımıza kurduk. Her şey yolunda gitti, konseptin uygulanabilir olduğu ortaya çıktı. Daha sonra, başlatma ayarlarının komut dosyası haline getirilmesi ve bunların işleme dahil edilmesi sorununu çözdük. Kontur güncellemesi kapsamında yeni bir paket hazırlayıp test ortamlarında test ettik. Uygulama ekibinden gelen çok çeşitli yorumlara rağmen kurulum başarılı oldu. Ama asıl önemli olan, montajımızla birlikte Kasım sürümünde üretime geçmemiz için bize izin verilmiş olmasıdır.
Bir aydan biraz fazla bir süre kala, özenle seçilen malzemeler zamanın tükendiğini açıkça gösteriyordu. Yapıyı sürüm dalından yapmaya karar verdiler ama neden ayrılsın ki? Prod benzeri bir kodumuz yok ve mevcut şubelerimiz de işe yaramıyor; çok fazla gereksiz kod var. Acilen dürtüklemeleri kesmemiz gerekiyor ve bu üç binin üzerinde taahhüt anlamına geliyor. Elle montaj kesinlikle bir seçenek değildir. Ürün kurulum günlüğünde çalışan ve şubeye yapılan taahhütleri toplayan bir komut dosyası taslağı hazırladık. Üçüncü kez doğru çalıştı ve "bir dosyayla bitirdikten" sonra şube hazırdı.
Kurulum paketini kendi builder'ımızı yazdık ve bir haftada bitirdik. Daha sonra, açık kaynak olduğundan yükleyiciyi sistemin temel işlevlerinden değiştirmek zorunda kaldık. Bir dizi kontrol ve değişiklikten sonra sonuç başarılı kabul edildi. Bu arada, doğru kurulumu için test devresini üretim devresi ile hizalamanın gerekli olduğu sürümün kompozisyonu şekillendi ve bunun için ayrı bir senaryo yazıldı.
Doğal olarak ilk kurulumla ilgili birçok yorum vardı ama genel olarak kod işe yaradı. Ve yaklaşık üçüncü kurulumdan sonra her şey iyi görünmeye başladı. Nesnelerin kompozisyon kontrolü ve versiyon kontrolü, bu aşamada oldukça haklı olan manuel modda ayrı ayrı izlendi.
Ek bir zorluk da dikkate alınması gereken çok sayıda yayınlanmayan yayındı. Ancak Prod benzeri dal ve Rebase ile görev şeffaf hale geldi.
İlk seferde, hızlı ve hatasız
Çıkışa iyimser bir tavırla ve farklı devrelerde bir düzineden fazla başarılı kurulumla yaklaştık. Ancak kelimenin tam anlamıyla son teslim tarihinden bir gün önce, satıcının sürümü kurulum için kabul edilen şekilde hazırlama işini tamamlamadığı ortaya çıktı. Herhangi bir nedenle yapımız çalışmazsa sürüm kesintiye uğrayacaktır. Üstelik bizim çabalarımızla, ki bu özellikle tatsız. Geri çekilme şansımız yoktu. Bu nedenle alternatif seçenekleri düşündük, eylem planları hazırladık ve kuruluma başladık.
Şaşırtıcı bir şekilde, 800'den fazla nesneden oluşan sürümün tamamı, ilk seferde ve yalnızca 10 dakika içinde doğru bir şekilde başladı. Hata aramak için günlükleri kontrol etmek için bir saat harcadık ancak herhangi bir hata bulamadık.
Ertesi gün boyunca sürüm sohbetinde sessizlik hakimdi: hiçbir uygulama sorunu, çarpık sürüm veya "uygunsuz" kod yoktu. Hatta bir şekilde garipti. Daha sonra bazı yorumlar ortaya çıktı, ancak diğer sistemlerle ve önceki deneyimlerle karşılaştırıldığında bunların sayısı ve öncelikleri gözle görülür derecede düşüktü.
Kümülatif etkinin ek bir etkisi de montaj ve test kalitesinin artmasıydı. Tam sürümün birden fazla kurulumu nedeniyle yapı kusurları ve dağıtım hataları zamanında tespit edildi. Tam sürüm konfigürasyonlarında yapılan testler, artımlı kurulumlar sırasında ortaya çıkmayan nesnelerin karşılıklı etkisindeki kusurları ek olarak tanımlamayı mümkün kıldı. Özellikle yayına olan %57'lik katkımız dikkate alındığında kesinlikle bir başarıydı.
Sonuçlar ve sonuçlar
Bir yıldan kısa bir sürede şunları başardık:
- Egzotik bir sistem kullanarak tam teşekküllü bir iç gelişim oluşturun;
- Kritik satıcı bağımlılığını ortadan kaldırın;
- Son derece düşmanca bir miras için CI/CD'yi başlatın;
- Uygulama süreçlerini yeni bir teknik seviyeye yükseltin;
- Dağıtım süresini önemli ölçüde azaltın;
- Uygulama hatalarının sayısını önemli ölçüde azaltın;
- Kendinizi güvenle lider bir geliştirme uzmanı olarak ilan edin.
Elbette anlatılanların çoğu tamamen saçmalık gibi görünüyor, ancak bunlar sistemin özellikleri ve içinde var olan süreç sınırlamalarıdır. Şu anda değişiklikler IS Profili ürün ve hizmetlerini (ana hesaplar, plastik kartlar, tasarruf hesapları, emanet, nakit krediler) etkilemiştir, ancak potansiyel olarak bu yaklaşım, DevOps uygulamalarını uygulama görevinin belirlendiği herhangi bir IS'ye uygulanabilir. Kümülatif model, birçok teslimattan sonraki uygulamalar (yayınlanmayanlar dahil) için güvenli bir şekilde kopyalanabilir.
Kaynak: habr.com