Bir zamanlar bir müşteriye bir tesiste elektronik belge yönetim sistemi sağladık. Ve sonra başka bir nesneye. Ve bir tane daha. Ve dördüncüde ve beşincide. O kadar kapıldık ki 10 dağıtılmış nesneye ulaştık. Çok güçlü bir sonuç ortaya çıktı... özellikle de değişiklikleri gerçekleştirmeye başladığımızda. Üretim devresine teslimatın bir parçası olarak, test sisteminin 5 senaryosu sonuçta 10 saat ve 6-7 çalışan gerektirdi. Bu tür maliyetler bizi mümkün olduğunca nadir teslimat yapmaya zorladı. Üç yıllık operasyonun ardından dayanamadık ve projeye bir miktar DevOps ile renk katmaya karar verdik.
Artık tüm testler 3 saat içinde gerçekleşiyor ve buna 3 kişi katılıyor: bir mühendis ve iki test uzmanı. İyileştirmeler açıkça rakamlarla ifade ediliyor ve çok sevilen TTM'de bir azalmaya yol açıyor. Deneyimlerimize göre DevOps'tan yararlanabilen müşteri sayısı, bunu bilen müşteri sayısından çok daha fazladır. Bu nedenle DevOps'u insanlara yaklaştırmak için bu yazıda daha ayrıntılı olarak konuşacağımız basit bir kurucu geliştirdik.
Şimdi size daha detaylı anlatalım. Bir enerji şirketi 10 büyük tesiste teknik belge yönetim sistemi kullanıyor. DevOps olmadan bu ölçekteki projelerde ilerlemek kolay değil çünkü manuel emeğin büyük bir kısmı işi büyük ölçüde geciktiriyor ve aynı zamanda kaliteyi de düşürüyor; tüm manuel işler hatalarla doludur. Öte yandan tek kurulumun olduğu ancak her şeyin otomatik, sürekli ve hatasız çalışması gereken projeler de var - örneğin büyük monolitik organizasyonlarda aynı belge akış sistemleri. Aksi takdirde, birisi ayarları manuel olarak yapacak, dağıtım talimatlarını unutacak ve sonuç olarak üretimde ayarlar kaybolacak ve her şey çökecek.
Genellikle müşteriyle bir sözleşme yoluyla çalışırız ve bu durumda çıkarlarımız biraz farklılaşır. Müşteri projeye kesinlikle bütçe ve teknik özellikler dahilinde bakar. Teknik spesifikasyonlarda yer almayan çeşitli DevOps uygulamalarının faydalarını ona anlatmak zor olabilir. Peki ya iş değeri katan hızlı sürümlerle veya bir otomasyon hattı oluşturmakla ilgileniyorsa?
Ne yazık ki önceden onaylanmış bir maliyetle çalışırken bu ilgi her zaman bulunamıyor. Uygulamamızda vicdansız ve dikkatsiz bir yüklenicinin gelişimini üstlenmemiz gereken bir durum vardı. Korkunçtu: güncel kaynak kodları yoktu, aynı sistemin kod tabanı farklı kurulumlarda farklıydı, belgeler kısmen yoktu ve kısmen berbat kalitedeydi. Elbette müşterinin kaynak kodu, derleme, sürümler vb. üzerinde kontrolü yoktu.
Şu ana kadar DevOps'u herkes bilmiyor ama avantajlarından, gerçek kaynak tasarrufundan bahsettiğimizde tüm müşterilerin gözleri parlıyor. Dolayısıyla DevOps içeren isteklerin sayısı zamanla artıyor. Burada müşterilerle aynı dili kolayca konuşabilmek için iş sorunlarını ve uygun bir geliştirme hattı oluşturmaya yardımcı olacak DevOps uygulamalarını hızlı bir şekilde birbirine bağlamamız gerekiyor.
Yani bir yanda bir takım sorunlarımız var, diğer yanda DevOps bilgimiz, uygulamalarımız ve araçlarımız var. Neden bu deneyimi herkesle paylaşmıyorsunuz?
DevOps yapıcısı oluşturma
Agile'ın kendi manifestosu vardır. ITIL'in kendi metodolojisi vardır. DevOps daha az şanslı; henüz şablon ve standart edinmedi. Rağmen Gelişimlerinin ve operasyonel uygulamalarının değerlendirilmesine dayanarak şirketlerin olgunluğunu belirlemek.
Neyse ki, 2014 yılında tanınmış Gartner şirketi ve temel DevOps uygulamalarını ve aralarındaki ilişkileri analiz ettik. Buna dayanarak bir infografik yayınladım:
Bunu temel aldık . Dört alanın her birinin bir takım araçları vardır; bunları bir veritabanında topladık, en popüler olanları belirledik, entegrasyon noktalarını ve uygun optimizasyon mekanizmalarını belirledik. Toplamda ortaya çıktı 36 uygulama ve 115 araçbunların dörtte biri açık kaynak veya özgür yazılımdır. Daha sonra, her alanda neler başardıklarımızdan ve örnek olarak, yazıya başladığımız teknik belge yönetimi oluşturma projesinde bunun nasıl uygulandığından bahsedeceğiz.
süreçler
Ünlü EDMS projesinde teknik dokümantasyon yönetim sistemi, 10 nesnenin her birinde aynı şemaya göre konuşlandırıldı. Kurulum 4 sunucu içerir: veritabanı sunucusu, uygulama sunucusu, tam metin indeksleme ve içerik yönetimi. Kurulumda tek bir düğüm içerisinde çalışırlar ve tesislerdeki veri merkezinde bulunurlar. Tüm nesneler altyapı açısından biraz farklılık gösterir ancak bu, küresel etkileşimi engellemez.
DevOps uygulamalarına göre öncelikle altyapıyı lokal olarak otomatize ettik, ardından teslimatı test devresine, ardından da müşterinin ürününe getirdik. Her süreç adım adım gerçekleştirildi. Ortam ayarları, hangi dağıtım kitinin otomatik güncelleme için derlendiği dikkate alınarak kaynak kod sisteminde sabitlenir. Konfigürasyon değişiklikleri durumunda mühendislerin sürüm kontrol sisteminde uygun değişiklikleri yapması yeterlidir; ardından otomatik güncelleme sorunsuz bir şekilde gerçekleşecektir.
Bu yaklaşım sayesinde test süreci büyük ölçüde basitleştirildi. Daha önce projede, standları manuel olarak güncellemekten başka hiçbir şey yapmayan test uzmanları vardı. Artık gelip her şeyin yolunda gittiğini görüyorlar ve daha faydalı şeyler yapıyorlar. Yüzey seviyesinden iş senaryosu otomasyonuna kadar her güncelleme otomatik olarak test edilir. Sonuçlar TestRail'de ayrı raporlar olarak yayınlanır.
Kültür
Sürekli deney en iyi şekilde test tasarımı örneğiyle açıklanır. Henüz var olmayan bir sistemi test etmek yaratıcı bir iştir. Test planı yazarken doğru test yapmayı ve hangi dalları takip edeceğinizi anlamanız gerekir. Ayrıca optimum kontrol sayısını belirlemek için zaman ve bütçe arasında bir denge bulun. Gerekli testleri tam olarak seçmek, kullanıcının sistemle nasıl etkileşime gireceğini düşünmek, çevreyi ve olası dış faktörleri dikkate almak önemlidir. Sürekli denemeler olmadan yapmak imkansızdır.
Şimdi etkileşim kültürü hakkında. Daha önce iki karşıt taraf vardı: mühendisler ve geliştiriciler. Geliştiriciler şunları söyledi: “Nasıl başlatılacağı umurumuzda değil. Mühendissiniz, akıllısınız, arızasız çalışmasını sağlayın”. Mühendisler cevap verdi: “Siz geliştiriciler çok dikkatsizsiniz. Daha dikkatli olalım ve yayınlarınızı daha az sıklıkla çalacağız. Çünkü bize sızdıran bir kod verdiğinizde, nasıl etkileşim kuracağımız bizim için net değil.". Bu, DevOps perspektifinden farklı yapılandırılmış bir kültürel etkileşim meselesidir. Burada hem mühendisler hem de geliştiriciler, sürekli değişen ancak aynı zamanda güvenilir yazılıma odaklanan tek bir ekibin parçasıdır.
Aynı ekip içinde uzmanlar birbirlerine yardım etmeye kararlıdır. Daha önce olduğu gibi mi? Örneğin, yaklaşık 50 sayfa uzunluğunda bazı kalın dağıtım talimatları hazırlanıyordu, mühendis bunu okudu, bir şey anlamadı, küfretti ve geliştiriciden sabah saat üçte yorum yapmasını istedi. Geliştirici hem yorum yaptı hem de küfretti - sonunda kimse mutlu olmadı. Ayrıca doğal olarak bazı hatalar da vardı çünkü talimatlardaki her şeyi hatırlayamazsınız. Ve şimdi mühendis, geliştiriciyle birlikte uygulama yazılımı altyapısının otomatik dağıtımı için bir komut dosyası yazıyor. Ve birbirleriyle neredeyse aynı dilde konuşuyorlar.
Insanlar
Ekibin büyüklüğü güncellemenin kapsamına göre belirleniyor. Ekip, teslimatın oluşumu sırasında işe alınır; genel proje ekibinden ilgilenenleri içerir. Daha sonra her aşamadan sorumlu olanlarla birlikte bir güncelleme planı yazılır ve ekip ilerledikçe rapor verir. Tüm ekip üyeleri değiştirilebilir. Ekibin bir parçası olarak bir de yedekleme geliştiricimiz var, ancak neredeyse hiçbir zaman bağlantı kurması gerekmiyor.
Teknoloji
Teknoloji şemasında birkaç nokta vurgulanmıştır, ancak bunların altında bir dizi teknoloji vardır; bunların açıklamalarıyla birlikte bir kitabın tamamını yayınlayabilirsiniz. Bu yüzden en ilginç olanı vurgulayacağız.
Kod Olarak Altyapı
Şimdi, muhtemelen bu konsept kimseyi şaşırtmayacaktır, ancak daha önce altyapı açıklamaları arzulanan çok şey bırakmıştı. , test ortamları benzersizdi, el üstünde tutuldu ve el üstünde tutuldu, üzerlerinden toz parçacıkları uçtu.
Günümüzde kimse denemekten korkmuyor. Sanal makinelerin temel görüntüleri var, ortamları dağıtmak için hazır senaryolar var. Tüm şablonlar ve komut dosyaları bir sürüm kontrol sisteminde saklanır ve anında güncellenir. Daha önce, bir paketin standa teslim edilmesi gerektiğinde bir konfigürasyon boşluğu ortaya çıkıyordu. Artık kaynak koduna bir satır eklemeniz yeterli.
Altyapı komut dosyalarına ve işlem hatlarına ek olarak, belgeleme için Kod Olarak Belgeleme yaklaşımı da kullanılır. Bu sayede yeni insanları projeye bağlamak, örneğin test planında açıklanan işlevlere göre onları sisteme tanıtmak ve ayrıca test senaryolarını yeniden kullanmak kolaydır.
Sürekli teslimat ve izleme
DevOps hakkında sürekli teslimat ve izlemeyi uygulamaya yönelik araçları nasıl seçtiğimizi anlattık. Çoğu zaman hiçbir şeyi yeniden yazmaya gerek yoktur - önceden yazılmış komut dosyalarını kullanmak, bileşenler arasında doğru şekilde entegrasyon oluşturmak ve ortak bir yönetim konsolu oluşturmak yeterlidir. Ve tüm işlemler tek bir düğme veya program kullanılarak başlatılabilir.
İngilizce'de Sürekli Teslimat ve Sürekli Dağıtım olmak üzere farklı kavramlar vardır. Her ikisi de “sürekli teslimat” olarak çevrilebilir ama aslında aralarında ufak bir fark var. Dağıtılmış bir enerji şirketinin teknik belge akışına yönelik projemizde, üretim için kurulum komut üzerine gerçekleştiğinde Teslimat kullanılır. Dağıtımda kurulum otomatik olarak gerçekleşir. Bu projede Sürekli Teslimat genel olarak DevOps'un merkezi kısmı.
Genel olarak belirli parametreleri toplayarak DevOps uygulamalarının neden faydalı olduğunu net bir şekilde anlayabilirsiniz. Ve bunu sayıları gerçekten seven yönetime iletin. Toplam lansman sayısı, senaryo aşamalarının yürütme süresi, başarılı lansmanların payı - tüm bunlar herkesin en sevdiği pazara çıkış süresini, yani sürüm kontrol sistemine taahhütten bir sürümün bir platformda yayınlanmasına kadar geçen süreyi doğrudan etkiler. Üretim ortamı. Gerekli araçların uygulanmasıyla mühendisler posta yoluyla değerli göstergeler alırlar ve proje yöneticisi bunları kontrol panelinde görür. Bu şekilde yeni araçların faydalarını anında değerlendirebilirsiniz. DevOps tasarımcısını kullanarak bunları altyapınızda deneyebilirsiniz.
Kimin bize ihtiyacı olacak? ?
Rol yapmayalım: Başlangıç olarak bizim için yararlı oldu. Daha önce de söylediğimiz gibi müşteriyle aynı dili konuşmanız gerekiyor ve DevOps tasarımcısının yardımıyla böyle bir konuşmanın temelini hızlı bir şekilde çizebiliriz. İş uzmanları neye ihtiyaç duyduklarını kendileri değerlendirebilecek ve böylece daha hızlı gelişebilecekler. Herhangi bir kullanıcının ne seçtiğini anlayabilmesi için bir dizi açıklama ekleyerek tasarımcıyı mümkün olduğunca ayrıntılı hale getirmeye çalıştık.
Tasarımcının formatı, şirketin bina süreçleri ve otomasyon alanındaki mevcut gelişmelerini dikkate almanıza olanak tanır. Yalnızca mevcut süreçlerle iyi bir şekilde bütünleşen ve boşlukları kolayca doldurabilen çözümleri seçebiliyorsanız, her şeyi yıkıp yeniden inşa etmeye gerek yoktur.
Belki de gelişiminiz zaten daha yüksek bir seviyeye taşınmıştır ve aracımız fazla "kaptan" gibi görünecektir. Ancak biz bunu kendimiz için yararlı buluyoruz ve bazı okuyuculara da yararlı olacağını umuyoruz. Size hatırlatıyoruz tasarımcıya - eğer varsa, ilk verileri girdikten hemen sonra diyagramı alırsınız. Geri bildiriminiz ve eklemeleriniz için minnettar olacağız.
Kaynak: habr.com