Resim:
Herkese selam! Biz şirketin otomasyon mühendisleriyiz ve şirket ürünlerinin geliştirilmesini destekliyoruz: geliştiriciler tarafından bir kod satırının işlenmesinden bitmiş ürünlerin ve lisansların güncelleme sunucularında yayınlanmasına kadar tüm montaj hattını destekliyoruz. Gayri resmi olarak bize DevOps mühendisleri denir. Bu yazımızda yazılım üretim sürecinin teknolojik aşamalarından, bunları nasıl gördüğümüzden ve nasıl sınıflandırdığımızdan bahsetmek istiyoruz.
Materyalden, çoklu ürün geliştirmeyi koordine etmenin karmaşıklığı, teknolojik haritanın ne olduğu ve çözümlerin kolaylaştırılmasına ve çoğaltılmasına nasıl yardımcı olduğu, geliştirme sürecinin ana aşamaları ve adımları nelerdir, sorumluluk alanları nasıldır hakkında bilgi edineceksiniz. DevOps ve şirketimizdeki ekipler arasında.
Kaos ve DevOps Hakkında
Kısaca DevOps kavramı, geliştirme araçları ve hizmetlerinin yanı sıra bunların kullanımına yönelik metodolojileri ve en iyi uygulamaları da içerir. Hadi küresel olanı ayıralım hedef DevOps fikirlerinin şirketimizde uygulanmasından: bu, ürünlerin üretim ve bakım maliyetlerinde niceliksel olarak (adam-saat veya makine saati, CPU, RAM, Disk, vb.) tutarlı bir azalmadır. Tüm şirket düzeyinde genel geliştirme maliyetini azaltmanın en kolay ve en belirgin yolu, tipik seri görevleri gerçekleştirme maliyetini en aza indirir Üretimin her aşamasında. Peki bu aşamalar nelerdir, genel süreçten nasıl ayrılır, hangi adımlardan oluşur?
Bir şirket bir ürün geliştirdiğinde her şey az çok açıktır: Genellikle ortak bir yol haritası ve geliştirme planı vardır. Peki ürün yelpazesi genişlediğinde ve daha fazla ürün ortaya çıktığında ne yapmalı? İlk bakışta benzer süreçlere ve montaj hatlarına sahipler ve loglarda ve scriptlerde “X farklarını bulma” oyunu başlıyor. Peki ya halihazırda aktif olarak geliştirilmekte olan 5'ten fazla proje varsa ve birkaç yılda geliştirilen çeşitli versiyonlar için desteğe ihtiyaç duyuluyorsa? Ürün hatlarında mümkün olan maksimum sayıda çözümü yeniden kullanmak mı istiyoruz yoksa her biri için benzersiz bir geliştirme için para harcamaya hazır mıyız?
Benzersizlik ve seri çözümler arasında denge nasıl bulunur?
Bu sorular 2015 yılından itibaren giderek daha sık karşımıza çıkmaya başladı. Ürün sayısı arttı ve bu ürünlerin montaj hatlarını destekleyen otomasyon departmanımızı (DevOps) minimuma indirmeye çalıştık. Aynı zamanda ürünler arasında mümkün olduğu kadar çok çözümü kopyalamak istedik. Sonuçta neden on üründe aynı şeyi farklı şekillerde yapıyoruz?
Geliştirme Müdürü: “Arkadaşlar, DevOps'un ürünler için neler yaptığını bir şekilde değerlendirebilir miyiz?”
Biz: “Bilmiyoruz, böyle bir soru sormadık ama hangi göstergelere dikkat edilmeli?”
Geliştirme Müdürü: "Kim bilir! Düşünmek…"
O meşhur filmde olduğu gibi: "Bir oteldeyim! .." - "Uh ... bana yolu gösterebilir misin?" Düşündüğümüzde, öncelikle ürünlerin son durumlarına karar vermemiz gerektiği sonucuna vardık; bu bizim ilk hedefimiz oldu.
Peki, 10 ila 200 kişiden oluşan oldukça büyük ekiplerle bir düzine ürünü nasıl analiz eder ve çözümleri kopyalarken ölçülebilir ölçümleri nasıl belirlersiniz?
1:0 Kaos lehine veya kürek kemiklerinde DevOps
BPwin serisinden IDEF0 diyagramlarını ve çeşitli iş süreci diyagramlarını uygulama girişimiyle başladık. Karışıklık bir sonraki projenin bir sonraki aşamasının beşinci karesinden sonra başladı ve her proje için bu kareler 50+ adımda uzun bir pitonun kuyruğunda çizilebilir. Üzüldüm ve aya ulumak istedim - genel olarak uymuyordu.
Tipik üretim görevleri
Üretim süreçlerini modellemek çok karmaşık ve zahmetli bir iştir: çeşitli departmanlardan ve üretim zincirlerinden çok sayıda veri toplamanız, işlemeniz ve analiz etmeniz gerekir. Bununla ilgili daha fazla bilgiyi makalede bulabilirsiniz "'.
Üretim sürecimizi modellemeye başladığımızda belirli bir hedefimiz vardı: şirketimizin ürünlerinin geliştirilmesinde yer alan her çalışana ve proje yöneticilerine:
- Bir kod satırının kaydedilmesinden başlayarak ürünlerin ve bileşenlerinin, yükleyiciler ve güncellemeler şeklinde müşteriye nasıl ulaştığı,
- Ürünlerin üretiminin her aşaması için hangi kaynakların sağlandığı,
- Her aşamada hangi hizmetlerin dahil olduğu,
- Her aşamanın sorumluluk alanlarının nasıl sınırlandırıldığı,
- Her aşamanın girişinde ve çıkışında hangi sözleşmelerin mevcut olduğu.
Resme tıkladığınızda tam boyutta açılacaktır.
Şirketteki işimiz birkaç fonksiyonel alana bölünmüştür. Altyapının yönü, bölümün tüm "demir" kaynaklarının operasyonunun optimizasyonunun yanı sıra sanal makinelerin ve üzerlerindeki ortamın konuşlandırılmasının otomasyonu ile ilgilidir. İzleme yönü 24/7 hizmet performans kontrolü sağlar; ayrıca geliştiriciler için bir hizmet olarak izleme sağlıyoruz. İş akışı yönü, ekiplere geliştirme ve test süreçlerini yönetmek, kodun durumunu analiz etmek ve projelerle ilgili analitik elde etmek için araçlar sağlar. Ve son olarak, webdev yönü, GUS ve FLUS güncelleme sunucularında sürümlerin yayınlanmasının yanı sıra, LicenseLab hizmetini kullanan ürünlerin lisanslanmasını sağlar. Üretim hattını desteklemek için, geliştiriciler için birçok farklı destek hizmeti kuruyoruz ve sürdürüyoruz (bazılarıyla ilgili hikayeleri eski buluşmalarda dinleyebilirsiniz: и). Aşağıdakiler dahil olmak üzere dahili otomasyon araçları da geliştiriyoruz: .
Son beş yılda, çalışmalarımız aynı türde ve rutin işlemlerden çokça birikti ve diğer departmanlardan geliştiricilerimiz çoğunlukla sözde departmanlardan geliyor. tipik görevlerÇözümü tamamen veya kısmen otomatik olan, sanatçılar açısından zorluk yaratmaz ve önemli miktarda çalışma gerektirmez. Önde gelen alanlarla birlikte bu tür görevleri analiz ettik ve bireysel iş kategorilerini tanımlayabildik veya üretim adımlarıaşamalar bölünemez adımlara bölünmüştür ve birkaç aşama toplanmıştır üretim süreci zinciri.
Teknolojik zincirin en basit örneği, her bir ürünümüzün şirket içinde montaj, devreye alma ve test aşamalarıdır. Örneğin derleme aşaması birçok ayrı tipik adımdan oluşur: GitLab'dan kaynakların indirilmesi, bağımlılıkların ve 3. taraf kitaplıkların hazırlanması, birim testi ve statik kod analizi, GitLab CI'da bir derleme komut dosyasının yürütülmesi, yapıtların depoda yayınlanması Dahili ChangelogBuilder aracımız aracılığıyla sürüm notlarının oluşturulması ve oluşturulması.
Tipik DevOps görevlerini Habré'deki diğer makalelerimizde okuyabilirsiniz: ""Ve"'.
Birçok tipik üretim zinciri oluşur üretim süreci. Süreçleri tanımlamaya yönelik standart yaklaşım, işlevsel IDEF0 modellerini kullanmaktır.
Bir üretim CI sürecini modelleme örneği
Sürekli entegrasyon sistemi için standart projelerin geliştirilmesine özel önem verdik. Bu, sözde vurgulayarak projelerin birleştirilmesini mümkün kıldı. Promosyonlarla derleme şemasını yayınlayın.
İşte nasıl çalışıyor? Tüm projeler tipik görünüyor: Artifactory'deki anlık görüntü deposuna giren montajların konfigürasyonunu içeriyor, ardından bunlar test tezgahlarında konuşlandırılıp test ediliyor ve ardından sürüm deposuna yükseltiliyor. Artifactory hizmeti, ekipler ve diğer hizmetler arasındaki tüm derleme yapıtları için tek bir dağıtım noktasıdır.
Yayınlama planımızı büyük ölçüde basitleştirir ve genelleştirirsek, aşağıdaki adımları içerir:
- platformlar arası ürün montajı,
- test tezgahlarına dağıtım,
- fonksiyonel ve diğer testleri yürütmek,
- Artifactory'de depoları serbest bırakmak için test edilmiş yapıları teşvik etmek,
- sürüm yapılarının güncelleme sunucularında yayınlanması,
- Montajların ve güncellemelerin üretime teslimi,
- Ürünün kurulumunu ve güncellenmesini başlatmak.
Örneğin, bu tipik sürüm şemasının (bundan sonra sadece Model olarak anılacaktır) teknolojik modelini işlevsel bir IDEF0 modeli biçiminde düşünün. CI sürecimizin ana aşamalarını yansıtır. IDEF0 modelleri sözde kullanır ICOM gösterimi (Girdi-Kontrol-Çıktı-Mekanizması) her aşamada hangi kaynakların kullanıldığını, hangi kural ve gereksinimlerin gerçekleştirildiğini, çıktının ne olduğunu ve belirli bir aşamada hangi mekanizmaların, hizmetlerin veya kişilerin uyguladığını açıklamaktır.
Resme tıkladığınızda tam boyutta açılacaktır.
Kural olarak, süreçlerin tanımını fonksiyonel modellerde ayrıştırmak ve detaylandırmak daha kolaydır. Ancak elementlerin sayısı arttıkça, onlarda bir şeyleri anlamak giderek zorlaşıyor. Ancak gerçek geliştirmede yardımcı aşamalar da vardır: izleme, ürünlerin sertifikalandırılması, iş süreçlerinin otomasyonu ve diğerleri. Ölçekleme sorunu nedeniyle bu açıklamayı bıraktık.
Umudun Doğuşu
Bir kitapta, teknolojik süreçleri anlatan eski Sovyet haritalarına rastladık (bu arada, bugün hala birçok devlete ait işletme ve üniversitede kullanılıyor). Bekle, bekle çünkü bizim de bir iş akışımız var!.. Aşamalar, sonuçlar, metrikler, gereksinimler, göstergeler falan var… Neden akış şemalarını ürün hatlarımıza da uygulamaya çalışmıyoruz? Bir his vardı: “İşte bu! Doğru ipliği bulduk, onu iyice çekmenin zamanı geldi!
Basit bir tabloda, ürünleri sütunlara, teknolojik aşamaları ve ürün boru hattını adım adım satırlara kaydetmeye karar verdik. Kilometre taşları, ürün oluşturma adımı gibi büyük bir şeydir. Ve adımlar, kaynak kodu yapı sunucusuna indirme adımı veya kodu derleme adımı gibi daha küçük ve daha ayrıntılı bir şeydir.
Haritanın satır ve sütunlarının kesişme noktalarında, belirli bir aşama ve ürün için durumları aşağıya koyuyoruz. Durumlar için bir dizi durum tanımlandı:
- Bilgi yok - veya uygunsuz. Üründeki bir aşamaya olan talebi analiz etmek gerekiyor. Ya analiz zaten yapılmıştır, ancak aşamaya şu anda ihtiyaç duyulmamaktadır ya da ekonomik olarak gerekçelendirilmemektedir.
- Ertelenen - veya şu anda konuyla alakalı değil. Boru hattında bir aşamaya ihtiyaç var, ancak bu yıl uygulamaya yönelik herhangi bir kuvvet yok.
- tarifeli. Etabın bu yıl uygulanması planlanıyor.
- uygulandı. Boru hattındaki aşama gerekli hacimde uygulanır.
Tablonun doldurulması proje proje başladı. Öncelikle bir projenin aşamaları ve adımları sınıflandırılarak durumları kaydedildi. Daha sonra bir sonraki projeyi aldılar, içindeki durumları düzelttiler ve önceki projelerde eksik olan aşamaları ve adımları eklediler. Sonuç olarak tüm üretim hattımızın aşamalarını, adımlarını ve bunların belirli bir projedeki durumlarını elde ettik. Ürün hattı yeterlilik matrisine benzer bir şey ortaya çıktı. Böyle bir matrise teknolojik harita adını verdik.
Teknolojik haritanın yardımıyla, yılın iş planlarını ve birlikte ulaşmak istediğimiz hedefleri metrolojik olarak ekiplerle koordine ediyoruz: bu yıl projeye hangi aşamaları ekliyoruz ve hangilerini sonraya bırakıyoruz. Ayrıca çalışma esnasında sadece tek bir ürün için tamamladığımız aşamalarda iyileştirmelerimiz olabilir. Daha sonra haritamızı genişletip bu iyileştirmeyi bir aşama veya yeni bir adım olarak tanıtıyoruz, ardından her ürün için analizler yapıyor ve iyileştirmeyi tekrarlamanın fizibilitesini buluyoruz.
Bize itiraz edebilirler: “Elbette bunların hepsi iyi, ancak zamanla adımların ve aşamaların sayısı aşırı derecede artacak. Nasıl olunur?
Şirket içindeki herkes tarafından aynı şekilde anlaşılabilmesi için her aşama ve adıma yönelik standart ve oldukça eksiksiz gereksinim açıklamaları sunduk. Zamanla, iyileştirmeler yapıldıkça, bir adım başka bir aşamaya veya adıma aktarılabilir ve daha sonra "çökerler". Aynı zamanda tüm gereksinimler ve teknolojik nüanslar genelleme aşamasının veya adımının gereksinimlerine uyar.
Çoğaltma çözümlerinin etkisi nasıl değerlendirilir? Son derece basit bir yaklaşım kullanıyoruz: yeni bir aşamanın uygulanması için ilk sermaye maliyetlerini yıllık genel ürün maliyetlerine atfediyoruz ve ardından çoğaltma sırasında tümüne bölüyoruz.
Gelişimin bazı kısımları halihazırda haritada kilometre taşları ve adımlar olarak gösteriliyor. Tipik aşamalar için otomasyonun getirilmesi yoluyla ürünün maliyetinin azaltılmasına etki edebiliriz. Bundan sonra, niteliksel özelliklerdeki, niceliksel ölçümlerdeki değişiklikleri ve ekiplerin elde ettiği karı (adam-saat veya makine-saat tasarrufu olarak) dikkate alıyoruz.
Üretim sürecinin teknolojik haritası
Tüm aşamalarımızı ve adımlarımızı alırsak, etiketlerle kodlarsak ve tek bir zincir halinde genişletirsek, o zaman çok uzun ve anlaşılmaz hale gelecektir (sadece makalenin başında bahsettiğimiz "python kuyruğu"). :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Bunlar, ürünleri oluşturma [Yapma], bunları test sunucularına dağıtma [Dağıt], test etme [Test], test sonuçlarına dayalı depoları serbest bırakmak için yapıları teşvik etme [Tanıtım], lisans oluşturma ve yayınlama [Lisans], yayınlama [ GUS güncelleme sunucusunda Yayımlama] ve FLUS güncelleme sunucularına teslim, Ürün Yapılandırma Yönetimi [Yükleme] kullanılarak müşterinin altyapısında ürün bileşenlerinin kurulumu ve güncellenmesi ve kurulu ürünlerden telemetri [Telemetri] toplanması.
Bunlara ek olarak ayrı aşamalar da ayırt edilebilir: altyapı durumu izleme [InfMonitoring], kaynak kodu sürüm oluşturma [SourceCodeControl], yapı ortamı hazırlama [Hazırlık], proje yönetimi [İş Akışı], ekiplere iletişim araçları sağlama [İletişim], ürün sertifikasyonu [ Sertifikasyon] ve CI süreçlerinin kendi kendine yeterliliğinin sağlanması [CISelfSufficiency] (örneğin, derlemelerin internetten bağımsızlığı). Süreçlerimizin onlarca adımı çok spesifik olduğundan dikkate bile alınmayacak.
şeklinde sunulursa tüm üretim sürecini anlamak ve bakmak çok daha kolay olacaktır. teknolojik harita; Modelin ayrı ayrı üretim aşamalarının ve ayrıştırılmış adımlarının satırlar halinde, sütunlar halinde ise her aşamada veya adımda neler yapıldığının anlatıldığı bir tablodur. Her aşamayı sağlayan kaynaklara ve sorumluluk alanlarının sınırlandırılmasına ağırlık verilmektedir.
Bizim için harita bir nevi sınıflandırıcıdır. Ürünlerin üretiminin büyük teknolojik parçalarını yansıtır. Bu sayede otomasyon ekibimizin geliştiricilerle etkileşime girmesi ve otomasyon aşamalarının uygulanmasını ortaklaşa planlaması ve bunun için hangi işçilik maliyetlerinin ve kaynakların (insan ve donanım) gerekli olacağını anlaması kolaylaştı.
Şirketimizde harita, jinja şablonundan normal bir HTML dosyası olarak otomatik olarak oluşturulur ve ardından GitLab Pages sunucusuna yüklenir. Tamamen oluşturulmuş bir harita örneğini içeren bir ekran görüntüsü görüntülenebilir .
Resme tıkladığınızda tam boyutta açılacaktır.
Kısacası teknolojik harita, tipik işlevselliğe sahip açıkça sınıflandırılmış blokları yansıtan üretim sürecinin genelleştirilmiş bir resmidir.
Yol haritamızın yapısı
Harita birkaç bölümden oluşuyor:
- Başlık alanı - burada haritanın genel bir açıklaması yer alır, temel kavramlar tanıtılır, ana kaynaklar ve üretim sürecinin sonuçları tanımlanır.
- Kontrol Paneli - burada bireysel ürünlere ilişkin verilerin gösterimini kontrol edebilirsiniz; uygulanan aşamaların ve genel olarak tüm ürünler için adımların bir özeti sağlanır.
- Teknolojik harita - teknolojik sürecin tablo halinde bir açıklaması. Haritada:
- tüm aşamalar, adımlar ve kodları verilmiştir;
- aşamaların kısa ve tam açıklamaları verilmiştir;
- her aşamada kullanılan girdi kaynakları ve hizmetler belirtilir;
- her aşamanın ve ayrı bir adımın sonuçları belirtilir;
- her aşama ve adımın sorumluluk alanı belirtilir;
- HDD (SSD), RAM, vCPU gibi teknik kaynaklar ve bu aşamada çalışmayı desteklemek için gerekli adam-saatler, hem şu anda - bir gerçek, hem de gelecekte - bir plan olarak belirlendi;
- her ürün için hangi teknolojik aşamaların veya adımların uygulandığı, uygulanmasının planlandığı, ilgisiz veya uygulanmadığı belirtilir.
Teknolojik haritaya dayalı karar verme
Haritayı inceledikten sonra, çalışanın şirketteki rolüne bağlı olarak (geliştirme yöneticisi, ürün yöneticisi, geliştirici veya testçi) bazı işlemler yapmak mümkündür:
- gerçek bir ürün veya projede hangi aşamaların eksik olduğunu anlamak ve bunların uygulanmasına olan ihtiyacı değerlendirmek;
- farklı aşamalarda çalışıyorlarsa sorumluluk alanlarını birkaç departman arasında sınırlandırın;
- etapların giriş ve çıkışlarında sözleşmeler üzerinde anlaşmaya varmak;
- çalışma aşamanızı genel geliştirme sürecine entegre edin;
- aşamaların her birini sağlayan kaynaklara olan ihtiyacı daha doğru bir şekilde değerlendirin.
Yukarıdakilerin hepsini özetlemek
Yönlendirme çok yönlüdür, genişletilebilir ve bakımı kolaydır. Bu formda süreçlerin bir tanımını geliştirmek ve sürdürmek, katı bir akademik IDEF0 modeline göre çok daha kolaydır. Ek olarak, tablo şeklinde bir açıklama, işlevsel bir modele göre daha basit, daha tanıdık ve daha iyi yapılandırılmıştır.
Adımların teknik uygulaması için, CI sistemleri, hizmetleri ve altyapısı arasında bir katman aracı olan özel bir dahili aracımız olan CrossBuilder'a sahibiz. Geliştiricinin bisikletini kesmesine gerek yoktur: CI sistemimizde, altyapımızın özelliklerini dikkate alarak onu doğru şekilde yürütecek olan CrossBuilder aracının komut dosyalarından birini (sözde görev) çalıştırmak yeterlidir. .
sonuçlar
Makalenin oldukça uzun olduğu ortaya çıktı ancak karmaşık süreçlerin modellenmesini anlatırken bu kaçınılmazdır. Son olarak ana fikirlerimizi kısaca düzeltmek istiyorum:
- DevOps fikirlerini şirketimizde uygulamanın amacı, şirket ürünlerinin üretim ve bakım maliyetlerini niceliksel olarak (adam-saat veya makine saatleri, vCPU, RAM, Disk) tutarlı bir şekilde azaltmaktır.
- Genel geliştirme maliyetini düşürmenin yolu, tipik seri görevleri gerçekleştirme maliyetini en aza indirmektir: teknolojik sürecin aşamaları ve adımları.
- Tipik bir görev, çözümü tamamen veya kısmen otomatik olan, uygulayıcılar için zorluk yaratmayan ve önemli işçilik maliyeti gerektirmeyen bir görevdir.
- Üretim süreci aşamalardan oluşur, aşamalar farklı ölçek ve kapsamdaki tipik görevler olan bölünemez adımlara bölünmüştür.
- Farklı tipik görevlerden, fonksiyonel bir IDEF0 modeli veya daha basit bir teknolojik harita ile tanımlanabilecek karmaşık teknolojik zincirlere ve üretim sürecinin çok seviyeli modellerine geldik.
- Teknolojik harita, üretim sürecinin aşamalarını ve adımlarını tablo halinde temsil eder. En önemlisi: Harita, tüm süreci bütünüyle, büyük parçalar halinde ve detaylandırma olanağıyla görmenizi sağlar.
- Teknolojik haritaya dayalı olarak, belirli bir üründe aşamaların tanıtılması, sorumluluk alanlarının belirlenmesi, aşamaların girdi ve çıktılarında sözleşmeler üzerinde anlaşmaya varılması ve kaynak ihtiyacının daha doğru bir şekilde değerlendirilmesi ihtiyacını değerlendirmek mümkündür.
İlerleyen yazılarımızda haritamızda belirli teknolojik aşamaları uygulamak için hangi teknik araçların kullanıldığını daha detaylı olarak anlatacağız.
Makalenin yazarları:
- — Positive Technologies'de Otomasyon Başkanı (DevOps)
- - Milletvekili Pozitif Teknolojiler'de Otomasyon Departmanı (DevOps) Başkanı
Kaynak: habr.com