DevOps'un DNA'sını analiz edin
Şelaleler, çevik ve diğer geliştirme çerçeveleri DevOps'un evrimini nasıl şekillendiriyor?
Resim kaynağı: opensource.com
DevOps'un DNA'sını analiz ederseniz, soy raporunda ne bulacaksınız?
Bu makale bir metodoloji değildir, yazılım mühendisliğine en iyi yaklaşımla ilgili herhangi bir öneri veya tartışma yoktur. Bunun yerine, DevOps'u günümüzün dijital dönüşümünün ön saflarına taşıyan genetik diziyi keşfedeceğiz.
Çoğu DevOps, deneme yanılma yoluyla geliştirilir çünkü şirket, kaliteyi artırırken ve giderek daha rekabetçi bir pazarda kendisini farklı kılarken müşteri ihtiyaçlarına yanıt vermek için çok çalışmaktadır. Daha ciddi zorluk, ürün odaklı bir küresel ekonomiden hizmet odaklı bir küresel ekonomiye geçiş ve insanları yeni yollarla birbirine bağlamaktır. Yazılım geliştirme yaşam döngüsü, ara bağlantı ve denetim sistemleri de dahil olmak üzere giderek daha karmaşık bir hizmet ve mikro hizmet sistemi haline geliyor. DevOps gitgide daha da ilerledikçe, güncellemelerin hızı şelale gibi daha yavaş geleneksel yöntemleri ortadan kaldırıyor.
Şelale yaklaşımını eleştirmiyoruz - birçok kuruluşun kullanmaya devam etmek için iyi nedenleri var. Bununla birlikte, olgun kuruluşlar, savurgan süreçlerden kurtulmaya odaklanmalıdır.Aslında, birçok girişimin, günlük faaliyetlerinde daha geleneksel yöntemler kullanan şirketlere göre rekabet avantajı vardır.
İroni şu ki, Lean, Kanban, Continuous ve Agile'ın ilkeleri ve süreçleri 1940'ların başlarına kadar izlenebiliyor, dolayısıyla DevOps yeni bir kavram değil.
Birkaç yıl öncesine bakalım ve şelale, yalın ve çevik yazılım geliştirme yöntemlerine bakalım. Aşağıdaki şekil, yazılım geliştirme yaşam döngüsünün "haplogrup" u göstermektedir. (Unutmayın, en iyi yöntemi aramıyoruz, ancak hangi yöntemin 67 yıllık yazılım mühendisliğimizin ve DevOps düşüncemizin gelişimi üzerinde olumlu bir etkisi olduğunu anlamaya çalışıyoruz.)
Haplogrup-SDLC patriline
"Aleti kullanan aptal hala aptal." - Mathew Mathai
1. Geleneksel şelale yöntemi
Bizim açımızdan, en eski genetik materyal ilk olarak Dr. Winston W. Royce tarafından 1970'lerde yayınlanan bir makalede önerilen şelale modelinden gelmektedir.
Bir şelale gibi, bu yöntem de sırayla geçmeyi vurgular: gereksinimler, analiz, kodlama, test etme ve uygulama Bu adımlar ve sıra gerçekleştirilir. Her sekans tamamlandıktan sonra, bir sonraki sekans başlatılmadan önce koşullar karşılanmalı ve alınmalıdır. Şelale yaklaşımı, katı bir sıra, ayrıntılı ve öngörülebilir kapsam ve kilometre taşı tabanlı geliştirme gerektiren projeler için uygundur. Yaygın inanışın aksine, ekibin gereksinimler, analiz ve tasarım aşamalarında erken tasarım değişiklikleri yapmasına ve denemesine olanak tanır.
şelale
2. Yalın düşünme
Yalın düşüncenin izi 1550'lerde Venedik Cephaneliğine kadar izlenebilse de, Toyota'nın 1992'de yayınlanan Toyota Üretim Sistemine ilişkin resmi açıklamasına göre, Japon mühendisler 1948'den 1972'ye kadar Toyota Üretim Sistemini geliştirdiklerinde yalın düşünceyi kullanmaya başladılar.
Yalın düşünme beş ilkeye dayanır: Değer, değer akışı, akış, çekme ve mükemmellik. Bu yaklaşımın özü, etkili bir değer akışını anlamak ve desteklemek, israfı ortadan kaldırmak ve kullanıcılara sürekli değer sağlamaktır. Kesintisiz hoş kullanıcılar.
Yalın düşünme
3. Sürekli iyileştirme
Sürekli iyileştirme, aşamalı iyileştirmeye dayanır; plan- > gerçekleştirillen- > bir sınav- > Eylem yaşam döngüsü, şirketi sürekli iyileştirme zihniyetine taşır. Sürekli iyileştirme kavramı başlangıçta montaj hattının sürecini iyileştirmek için geliştirilmiştir ve aynı zamanda tedarik zinciri boyunca değer katmaktadır. Toyota Üretim Sistemi, sürekli iyileştirmenin ve sürekli iyileştirmenin ilk uygulayıcılarından biridir. Sürekli iyileştirme ve DevOps, iş akışının tasarımdan üretime olduğu bir ortamda birlikte iyi çalışabilir. Sürekli iyileştirme iki konuya odaklanır:
Akış
Süreç
4. Sürekli teslimat
Sürekli iyileştirme, otomatik üretim için süreçlerin ve araçların geliştirilmesine ilham verdi. Şirketler, israfı olabildiğince ortadan kaldırarak (kültürel ve zihinsel modeller dahil) ve mümkün olduğunca otomatikleştirmek için makineleri, yazılımları ve robotikleri kullanarak üretimi hızlandırabilir ve kalite, tasarım, inşa, test ve teslimat süreçlerini iyileştirebilir. Pek çok sürekli iyileştirme kavramı, yalın iş ve yazılım uygulamalarının ve DevOps ilkelerinin ve hedeflerinin sürekli olarak dağıtılması için de geçerlidir.
5. Çevik
"Çevik Yazılım Geliştirme Manifestosu" 2001 yılında yayınlandı ve alistair cockburn, bob martin, jeff sutherland, jim highsmith, ken schwaber, kent beck, ward cunningham vb. Tarafından yazılmıştır.
Çevik, tedbiri bırakmak, tasarımı terk etmek veya özgürce yazılım geliştirmekle ilgili değildir. Değişim yaratabilmek ve buna karşılık verebilmekle ilgili. Çevik geliştirme on iki ilkeye ve bir manifestoya dayanır ve bireylere ve işbirliğine, çalışan yazılıma, müşteri işbirliğine ve değişikliklere yanıt vermeye değer verir.
çevik
6. Standart çevik
Çevik Manifesto 20 yıldır değişmediğinden beri, birçok Agile uygulayıcı ona seçenek ve öznellik katmanın yollarını arıyor. Ek olarak, Çevik Manifesto geliştirmeye odaklanır, bu nedenle günümüzün hızlı tempolu geliştirme ortamında, kod veya yazılım yerine çözümleri ayarlamak özellikle gereklidir. Scott Ambler ve Mark Lines, Rational, IBM ve bazı kuruluşlardaki deneyimlerine dayanarak, Standard Agile Delivery ve Standard Agile Framework'ü birlikte yazdı. Bu organizasyonlarda, ekibin daha fazla seçeneğe ihtiyacı vardır veya yalın uygulamaları uygulamak için yeterince olgun değildir ya da proje ortamı yaşam döngüsü için uygun değildir.
DAD ve DA'nın önemi, artımlı ve yinelemeli çözüm sunumu etrafında süreç karar vermeyi basitleştirebilen bir süreç karar verme çerçevesi olmasıdır. DAD, scrum, çevik modelleme, yalın yazılım geliştirme vb. Dahil olmak üzere birçok çevik yazılım geliştirme uygulamasına dayanmaktadır. Test güdümlü geliştirme (TDD) yoluyla otomasyonun teşvik edilmesi, beş çevik yaşam döngüsü seçimi yoluyla yalın fikirlerin (Kanban, XP, scrum ve RUP gibi) kullanımı ve mimar sahibinin tanıtımı dahil olmak üzere çevik modelleme ve yeniden düzenlemenin yaygın kullanımı, Çevik uygulayıcıların DevOps'u başarıyla uygulamaları için zihinsel modeller, süreçler ve araçlar eklendi.
7. DevOps
Bildiğimiz kadarıyla DevOps, 2009'da Belçika'da bir dizi DevOps konferansında yer aldı ve birçok dijital değişikliğin temeli oldu. Microsoft'un ana DevOps yöneticisi olan Donovan Brown, DevOps'u "son kullanıcılara sürekli değer sunmak için insanlar, süreçler ve ürünlerin birliği" olarak tanımlıyor.
Orijinal soruya dönelim: DNA'sını analiz ederseniz, DevOps soy raporunda ne bulacaksınız?
DevOps
Araştırmamız 80, 48, 26 ve 17 yıl öncesine, nispeten sabit ve statik bir çağ olan günümüzün hızlı tempolu ve öngörülemez ortamında geçmişe gidiyor. Özünde, biz insanlar genetik zincirdeki avantajları devralmaya ve zayıflıkları gidermeye, denemeye, öğrenmeye ve uyarlamaya devam ediyoruz.
Mikroskop altında şelaleler, yalın düşünme, çeviklik, Scrum, Kanban ve diğer genetik izleri bulacağız. Örneğin, ayrıntılı ve öngörülebilir kapsamın şelale izleri, israfı azaltmak için kullanılan yalın izler ve teslim edilebilir kod artışlarını desteklemek için kullanılan çevik izler vardır. Kodun ne zaman ve nasıl iletileceğini tanımlayan gen zinciri, DevOps keşfimizin parlayan noktasıdır.
Üretimdeki çözümleri gözlemleyerek toplanan telemetri verilerini deneyleri yönlendirmek, hipotezleri onaylamak ve ürün biriktirme listelerine öncelik vermek için kullanabilirsiniz. Diğer bir deyişle, DevOps, kültürünüzü dönüştürmenize, ürünleri yönlendirmek için kullanmanıza ve en önemlisi müşterilerinizi mutlu etmenize olanak tanıyan çeşitli olgun ve gelişen çerçeveleri miras alır.
Yalın düşünme ve çeviklikten memnunsanız, DevOps'un tüm avantajlarından yararlanacaksınız. Bir şelale ortamından geliyorsanız, DevOps fikirlerinden yardım alırsınız, ancak yalın ve çevik iş arkadaşlarınız sizi geride bırakacaktır.
8. eDevOps
eDevOps
2016 yılında Brent Reed, eDevOps kavramını oluşturdu (şimdiye kadar Google veya Wikipedia tarafından alıntılanmadı) ve bunu "insanlar, süreçler ve araçlar aracılığıyla tüm işletmeye kesintisiz bir şekilde sürekli iyileştirme getiren bir çalışma yöntemi (WOW)" olarak tanımladı. . "
Brent, Agile'ın BT'de başarısız olduğunu buldu: Yalın düşünceyi benimseyen şirketler, BT uzmanlarının beklediği değer, odaklanma ve hıza ulaşamadı. İzole BT hizmetlerinin mimari, geliştirme, operasyonlar ve hizmet masası destek ekipleriyle bağlantısının kesildiği bir "fildişi kule" görünce bunalmış durumda. Standartlaştırılmış çevik teslimatla ilgili pratik bilgileri uyguladı ve DAD araç setine bazı hedefler ve pratik uygulamalar ekledi:
Sürekli iyileştirme (sürekli iyileştirme) düşüncesi yoluyla kültüre odaklanın ve bunları teşvik edin, böylece insanlar bölmelerle ayrılmış olsalar bile bir araya gelebilirler.
Otomasyon yoluyla israfı ortadan kaldırın (tüm olası şeylerin TDD + yeniden inşası) ve TOGAF, JBGE (yeterince çıplak) dokümantasyon yöntemlerini benimseyin.
Modelleme (mimari modelleme) ve sola doğru hareket ederek, daha işlevsel ve stratejik bir modern dijital havuzda işbirliği modellerini paylaşırken anti-kalıpları ortaya çıkararak değeri gerçekleştirin
IBM'deki yapay zeka deneyimiyle Brent, eDevOps için, her kuruluş için önemli olan sürekli devreye alma yoluyla (geliştirmeden üretime otomasyon) sürekli iyileştirme sağlamak amacıyla ölçüm ve karar verme için gösterge tablolarını kademeli olarak otomatikleştirebilen bir olgunluk modeli tasarladı. Pratik fizibilite var. Katı DevOps'a dayalı etkili bir dönüşüm planında, eDevOps şunları başarabilir:
DevOps işi (BizDevOps)
DevOps Güvenliği (SecDevOps)
DevOps bilgileri (DataDevOps)
Tüm paydaşları bir araya getirip teşvik ederken gevşek bir şekilde bağlı teknik hizmetler
İki haftada bir veya daha hızlı bir şekilde potansiyel sarf malzemesi çözümleri oluşturun
Konseptten gerçek zamanlı üretim kullanımına kadar DevOps süreci boyunca eyleme geçirilebilir içgörüleri toplayın, ölçün, analiz edin, görüntüleyin ve otomatikleştirin.
Sürekli iyileştirmeyi takip edin ve çevik yöntemleri standartlaştırın ve ardından iyileştirmeye devam edin
9. DevOps geliştirmenin bir sonraki aşaması
DevOps sonunda hype (birden çok teknoloji kombinasyonundan oluşan bir koleksiyon) olarak kabul edilecek ve zaten uzun olan moda sözcükler listesine eklenecek mi? Elbette, zaman bize DevOps'un nasıl gelişeceğini gösterecek. Ancak DevOps'un DNA'sı olgunlaşmaya ve gelişmeye devam etmeli ve geliştiriciler bunun tüm hastalıkları iyileştirmek ve tüm sorunları çözmek için ne derde deva ne de çare olmadığını anlamalıdır.
DevOps! = Çevik! = Yalın Düşünme! = Şelale
DevOps! = Araçlar! = Teknoloji
DevOpsAgileLean ThinkingŞelale
Orijinal bağlantı:
https://opensource.com/article/18/11/analyzing-devops
Çevirmen tanıtımı:
İçerik açıklaması Chen Yane, Ansteel Madencilik İşletme ve Bakımı, bulut ve sanallaştırma uygulaması ve teknolojisine odaklanan, bulut teknolojisi topluluk çevirmeni
