DevOps Nedir?

DevOps, hepsi yeni olmasa da bir harekete katalize eden ve teknik topluluk içinde hızla yayılan bir grup kavram için kullanılan bir terimdir. Herhangi bir yeni ve popüler terim gibi, insanlar da ne olduğu hakkında kafa karıştırıcı ve bazen de çelişkili izlenimler bırakmış olabilir. İşte DevOps’un nasıl yararlı bir şekilde tanımlanabileceğine dair benim görüşüm; Bu tanımı DevOps’un kapsadığı çeşitli alanları daha net tartışmak için standart bir çerçeve olarak öneriyorum. “Kalite” veya “Çevik” gibi, DevOps da tam anlamıyla anlamak için biraz nüans gerektiren bir büyük kavramdır.

DevOps’un tanımı

DevOps, iki ana eğilimin çarpışmasından ortaya çıkan yeni bir terimdir. Birincisi “çevik altyapı” veya “çevik operasyonlar” olarak da adlandırıldı; operasyon çalışmalarına Çevik ve Yalın yaklaşımları uygulamaktan çıktı. İkincisi, bir hizmet yaratırken ve işletirken geliştirme yaşam döngüsünün tüm aşamalarında gelişim ve operasyon personeli arasındaki işbirliğinin değerini ve giderek artan hizmet odaklı dünyamızdaki operasyonların ne kadar önemli hale geldiğini anlamaktır.

Jez Humble’ın bana önerdiği bir tanım DevOps’un “ ölçekte hızla değişen esnek sistemler inşa etme, geliştirme ve işletme çalışmalarına adanmış disiplinler arası bir uygulama topluluğu” olduğu yönünde  .

Bu iyi ve etli, ancak İnternet başlangıç ​​türlerine göre biraz fazla ezotik ve spesifik olabilir. DevOps’u daha pratik bir şekilde tanımlayabileceğinize inanıyorum.

DevOps, tasarımdan geliştirme sürecine ve üretim desteğine kadar hizmet ömrünün tamamına birlikte katılan işletme ve geliştirme mühendislerinin pratiğidir.

Bunun temel bir sonucu, önceki yöntemlerden uygulamadaki ana değişikliklerin bir kısmıdır.

DevOps ayrıca, sistemleri için geliştiricilerle aynı tekniklerin çoğunu kullanan operasyon personeli ile de karakterize edilir.

Bu teknikler, kaynak kontrolünün kullanılmasından test etmeye ve Çevik bir geliştirme sürecine katılmaya kadar değişebilir.

Bu amaçla, “DevOps” farklı sysadmin alt disiplinleri arasında ayrım yapmaz – “Ops” sistem mühendisleri, sistem yöneticileri, işletme personeli, sürüm mühendisleri, DBA’lar, ağ mühendisleri, güvenlik uzmanları ve diğer çeşitli alt disiplinler için kullanılan bir terimdir. ve iş ünvanları. “Dev” özellikle geliştiriciler için kısa yol olarak kullanılır, ancak gerçekte pratikte daha da geniştir ve Ürün, QA ve diğer disiplinleri içerebilen “ürünü geliştirmeye katılan tüm insanlar” anlamına gelir.

DevOps, Çevik ve Yalın yaklaşımlarla güçlü ilişkilere sahiptir. Operasyonların eski görüşü “Dev” tarafının “yapımcı” ve “Ops” tarafının “doğduktan sonra yaratılışla uğraşan insanlar” – sanayide yapılan zararın gerçekleşmesi yönünde bu endişeler sessiz kaygılar olarak görülüyor DevOps’un arkasındaki ana itici güç. Bu şekilde DevOps, Çevik – çevik yazılım geliştirme sürecinin bir sonucu olarak yorumlanabilir; bu da müşterileri, ürün yönetimini, geliştiricileri ve (bazen) KG’nın yakın işbirliğini boşlukları doldurup daha iyi bir ürüne doğru hızla yinelemesini öngörür – DevOps “evet Ancak, hizmet sunumu ve uygulamanın ve sistemlerin nasıl etkileşime girdiği, müşteriye değer teklifinin temel bir parçasıdır ve bu nedenle ürün ekibinin bu endişeleri en üst düzeyde bir madde olarak içermesi gerekir.

Derinlikteki Tanım

DevOps, farklı insanlara çok farklı şeyler ifade ediyor, çünkü etrafındaki tartışma çok fazla zemin kaplıyor. İnsanlar DevOps’un “geliştirici ve operasyon işbirliği” olduğu veya “kodunuzu altyapı olarak gördüğü” olduğu veya “otomasyon kullanımı” veya “kanban kullanımı” veya “bir araç zinciri yaklaşımı” veya “kültür” veya çeşitliliğinden bahseder. görünüşte gevşek ilişkili öğeler. Derinlemesine tanımlamanın en iyi yolu, benzer şekilde karmaşık, çevik bir gelişimin tanımına paralel bir yöntem kullanmaktır. Vikipedi ve çevik manifestoya göre çevik gelişme, dört farklı endişe düzeyinden oluşuyor. Beşinci olarak, takım seviyesini ekledim – çevik ve konuşmacılar hakkında konuşmak araçlara çok takıntılı hale gelebilir, ancak var olmadığını iddia etmek de yararsızdır.

• Çevik Değerler – Genellikle Çevik Manifesto’da somutlaştırılmaya karar verilen üst düzey felsefe . Bunlar çevik bilgi veren temel değerlerdir.
• Çevik İlkeler – Genel olarak bu değerleri destekleyen stratejik yaklaşımlar üzerinde anlaşmaya vardı. Çevik Manifesto, bu daha spesifik ilkelerden bir düzine alıntı yapıyor . Çevik olmak için hepsini satın almak zorunda değilsiniz, ancak çoğuna abone değilseniz, muhtemelen başka bir şey yapıyorsunuzdur.
• Çevik Yöntemler – İlkelerin daha spesifik süreç uygulamaları. Kendi homebrew süreciniz olan XP, Scrum – bu, felsefenin “bunu gerçek hayatta nasıl yapmayı planladığımız” operasyonel oyun kitaplarına bıraktığı yer.
• Çevik Uygulamalar – çevik uygulamalar ile birlikte kullanılma eğiliminde olan oldukça spesifik taktik teknikler. Hiçbirinin çevik olması gerekmez, ancak birçok çevik uygulama onları benimsemekten değer görmüştür. Standup’lar, poker planlama, biriktirme listeleri, CI, geliştiricinin işlerini yapmak için kullandığı tüm belirli eserler.
• Çevik Araçlar – Ekiplerin çalışmalarını bu yöntemlere göre yapmak için kullandıkları bu uygulamaların spesifik teknik uygulamaları. JIRA Agile (aka Greenhopper), planningpoker.com, ve ark.

İdeal olarak yüksek seviyeler düşük seviyelere bilgi verir – temelleri anlamadan belirli araç ve uygulamaları toplayan kişi veya kuruluşlar fayda görebilir veya görmeyebilir ancak bu “kargo kültü” yaklaşımının genellikle düşük sonuçlara sahip olduğu düşünülmektedir. DevOps’un farklı bölümlerinin insanların harita hakkında doğrudan aynı seviyelerde bulunduklarına inanıyorum.

• DevOps Değerleri – Temel DevOps değerlerinin Agile Manifestosu’nda etkili bir şekilde yakalandığına inanıyorum – belki de sadece “çalışan yazılım” yerine müşteriye tam olarak sunulan genel hizmet veya yazılıma odaklanmak için hafif bir dağıtımla. Alex Honor’un “ Araçlar Üzerindeki Kişiler Üzerine Çalışanları ” , temel Agile Manifesto ifadelerini tekrarlıyor ve dev + ops işbirliğini öneriyor.
• DevOps Prensipleri – Listede kararlaştırılmış tek bir liste yok, ancak yaygın olarak kabul edilen birkaç girişim var – işte John Willis “CAMS” ibarelerini yazıyor ve işte James Turnbull bu seviyede kendi tanımını veriyor . “Kod olarak altyapı” yaygın olarak belirtilen bir DevOps prensibidir. Buradaki Çevik manifestosu ve ilkelerini “DevOps’ing” konusunda bir kesim yaptım . Kişisel olarak, DevOps’un kavramsal düzeyde, çoğunlukla Agile’nin kod denetiminde kaygılarını bırakmak yerine sistemleri ve işlemleri dahil etme ilkelerinin genişletilmesi olduğuna inanıyorum.
• DevOps Yöntemleri – Buradaki yöntemlerden bazıları aynıdır; Scrum’ı işlemlerle, Kanban’ı işlemlerle vb. kullanabilirsiniz (her ne kadar op’ları ürün ekiplerinde dev, QA ve ürün ile entegre etmeye daha fazla odaklanmakla birlikte). Görünür Ops tarzı değişim kontrolü ve olay yanıtı için Olay Komut Sisteminin kullanılması gibi bazı daha belirgin yöntemler vardır . Bu metodolojilerin seti büyüyor; Örneğin, izlemeye daha düşünceli bir yaklaşım, ortak metodolojilerin iyi tanımlanmadığı bir alandır.
• DevOps Uygulamaları – Yukarıdaki kavram ve işlemlerin bir parçası olarak kullanılan özel teknikler. Sürekli entegrasyon ve sürekli dağıtım, “Geliştiricilerinize çağrı cihazı çağırın ve onları devreye sokun”, yapılandırma yönetimi, ölçümler ve izleme şemaları, takımlama için bir araç zinciri yaklaşımı kullanarak… Sanallaştırma ve bulut bilişim kullanmak bile, modern altyapı dünyası.
• DevOps Araçları – Bu ilkelerin komisyonunda kullanacağınız araçlar. DevOps dünyasında, piyasaya sürülen (jenkins, travis, teamcity), konfigürasyon yönetimi (kukla, şef, aşçı, cfengine), orkestrasyon (zooker, noah, mesolar), izleme, sanallaştırma ve konteynırlama (AWS, OpenStack) araçlarında patlama meydana geldi. , serseri, liman işçisi) ve çok daha fazlası. Agile’de olduğu gibi, bir aracın size sihirli bir şekilde DevOps getireceği anlamında “bir DevOps aracı” olduğunu söylemek yanlış olsa da, yukarıda belirtilen ilkeleri, yöntemleri ve uygulamaları kolaylaştırmak amacıyla açık bir şekilde geliştirilen özel araçlar var. ve DevOps’un bütünsel bir anlayışı bu katmanı içermelidir.

Sonunda DevOps, tıpkı ağabeyi Agile gibi tanımlamak biraz zor. Ama yapmaya değer. Saf felsefe düzeyinde bırakıldığında, her ikisi de boş anne ve elmalı turta ifadeleri gibi görünebilir; “Bana sadece işimi daha iyi yap,“ ha…… ”diyerek eleştirmene tabi. Üst düzey rehberlik bir kargo kültüne dönüşür. “Bu Scrum kitabının söylediklerini yapıyorum, bu yüzden Çevik yapıyorum” “Şef kullanıyorum, bu yüzden DevOps haklıyım mı?” Kadar hatalı. Başarılı bir Çevik veya DevOps uygulayıcısı olmak, içine giren tüm katmanları anlamaktır. o ve belirli bir DevOps uygulamasının neler içerebileceğini veya içermeyeceğini. Sonunda, DevOps’un Agile’ye getirmeyi umduğu şey, yazılımın bir kullanıcıya başarıyla teslim edilip kullanılabilirlik, performans konusundaki beklentilerini karşılayana kadar yapılmadığı anlayışı ve uygulamasıdır.

Özellikle, genellikle DevOps bağlamında tartışılan üç ana uygulama alanı olduğuna inanıyorum.

• Altyapı Otomasyonu – sistemlerinizi, işletim sistemi yapılandırmalarınızı ve uygulama dağıtımlarınızı kod olarak oluşturun.
• Sürekli Teslimat – uygulamalarınızı hızlı ve otomatik bir şekilde oluşturun, test edin, kullanın.
• Site Güvenilirlik Mühendisliği – sistemlerinizi çalıştırın; İzleme ve düzenleme, elbette, ancak ilk etapta işletilebilirlik için tasarım.

DevOps’un Tarihçesi

DevOps’un ortaya çıkışı, teknoloji çalışmasının sistemler tarafında yenilikçilik ihtiyacının artmasından kaynaklanıyor. DevOps hareketi, Çevik Sistem Yönetimi hareketi ve Kurumsal Sistem Yönetimi (ESM) hareketinden miras kalmıştır.

2000’li yılların ortalarında ortaya çıkan ESM, “Hey, çalışan sistemler metodolojimiz yıllar süren çabalara rağmen oldukça ilkel bir durumda gibi görünüyor. Bunu daha iyi yapmak hakkında konuşmaya başlayalım. ”John Willis, Whurley ve Zenoss’dan Mark Hinkle buna katıldı ve konsept etrafında bir BarCamp’a sponsor oldu . Bu aşamada, ITIL ile bir yönetim çerçevesi olarak ilk büyülenmenin “ITIL Lite” Görünür Operasyonları için büyük ölçüde devrildiğini düşünüyorum. yaklaşım, “büyük satıcı” odaklı olmaktan öteye geçmenin yanı sıra – eskiden olduğu gibi, HP, IBM ve CA gibi kurumsal çerçeveler uçtan uca sistem yönetimine uçacak tek anlamlı çözümdü, ancak daha açık kaynak ve daha küçük satıcılar oldu. Spiceworks, Hyperic, Zenoss ve diğerleri de dahil olmak üzere ortaya çıkıyor.

Ayrıca 2008’de, ilk Velocity konferansı O’Reilly tarafından gerçekleştirildi ve web performansına ve operasyonlarına odaklandı ve operasyonların en iyi uygulamaları etrafında bilgi paylaşımına yer verdi. 2009’da büyük mağazalarda  geliştirici / operasyon işbirliği hakkında ve bunun Web ortamlarında güvenli, hızlı bir değişimi nasıl teşvik ettiği hakkında bazı önemli sunumlar yapıldı . Kukla ve Şef gibi araçlar sağlayan orada güçlü gösteriler vardı. Daha fazla insan bu yeni kavramlar hakkında düşünmeye başladı ve onları nasıl uygulayabileceklerini merak etti.

Buna paralel olarak, çevik kalkınmanın gelişim alanındaki büyümesi en ateşli adımına ulaşıp nişlerden ortak uygulamaya geçerken, özellikle Avrupa’da “Çevik Sistem Yönetimi” düşüncesine dönüştü. İngiltere’den Gordon Banner bu sunumla ilgili daha önce konuştu . Bu hareketin odağının çoğu, süreç ve kanban ve yalın üretim süreçlerinden BT sistemleri yönetimine benzetmeler üzerineydi. Daha sonra 2009’da Belçika’dan Patrick Debois ve ABD’li Andrew “Clay” Shafer, ABD’den bir araya geldi ve  konuşmaya başladı (ve terimini koydu) ve ardından Patrick, sigortayı yakan ilk DevOpsDays etkinliğini düzenledi. Şimdi bir adı vardı kavramı, diğer yerlerde daha fazla konuşulmaya başlandı .Velocity ve DevOpsDays dahil ABD’de burada ve hızla yayıldı.

Patrick Debois’in görüşüne göre DevOps, muhtemelen tanıdık gelen mevcut uygulamalardan kaynaklanan silolara ve esnekliğe karşı bir tepki olarak ortaya çıktı. İşte John Willis tarafından DevOps hareketinin tarihi üzerine bir araya gelerek onu yaratan iplikleri yapılandıran güzel bir eser .

DevOps bir araya gelen bu şeylerin “mükemmel fırtınasından” ortaya çıktı. Daha iyi izleme ve sağlama araçlarıyla beslenen artan otomasyon ve araç zinciri yaklaşımı, çevik süreçlere ve dev / op’ların işbirliğine olan gereksinimi ile birlikte, ITSM / ITIL’in büyük / ağır uygulamalarının başarısızlıkla sonuçlanmaması – birlikte çalıştığı üç katmanı da çarpıştı ve bilinçsizce bir araya getirdi. çevik harekete (ilkeler, süreç ve uygulamalar) ihtiyaç duyuyorsunuz ve ateş yaktınız. O zamandan bu yana, özellikle Yalın prensiplerini birçok düşünce liderinin dahil etmesiyle geliştirmiştir.

DevOps Nedir?

NoOps değil

“İşlerimizi alıyorlar!” Değildir. Bazı insanlar DevOps’un geliştiricilerin operasyonları devraldıkları ve kendileri yaptıkları anlamına geldiğini düşünüyor. Bunun bir kısmı doğru, bir kısmı da değil.

DevOps’un, evin silinme yönünden operasyonları silmek için geldiği bir yanılgıdır – DevOps ve çevik operasyonlardaki öncülleri operasyon ekiplerinden daha sık başlatılmamaktadır. Bunun nedeni, operasyon milletinin (ve burada kendim için de konuşuyorum) var olan ilkelerimizin, süreçlerimizin ve uygulamalarımızın başarı için gerekenlere ayak uyduramadığını fark etmeleridir. İşletmeler ve geliştirme ekipleri, iş ortamı daha hızlı büyüdükçe daha fazla çevikliğe ihtiyaç duydukça, sorunlarımızı daha sert bir şekilde çözmeye çalıştığımızdan daha az faydalanıyoruz ve etkili huy.

Şimdi, operasyonların bazı bölümlerinin otomatikleştirilmesi gerektiğinin farkına vardığımızda, bu demek oluyor ki ya insanların bazı otomasyon geliştirmeleri yapmasını istiyoruz ya da geliştiriciler “işlemler” kodu ya da her ikisi de yazıyor. Bu bazıları için korkutucu ama genel işbirlikçi yaklaşımın değerinin bir parçası. Bu yaklaşımı kullanarak koştuğum tüm başarılı ekipler, hem daha iyi bir genel ürün oluşturmak için birlikte çalışan derin yetenek becerilerine ve derin yetenek becerisine sahip insanlara sahip . Ve daha yüksek seviyedeki endişeler daha otomatik hale geldiğinden, teknik beceriye sahip personel daha yüksek değerli problemleri bir seviyeye çıkarmaya başlarken, kimsenin kendini yüksek teknolojideki işinden otomatik hale getirdiğini görmedim.

Değil (Sadece) Araçlar

DevOps aynı zamanda sadece bir takım araçları uygulamak değildir. DevOps’un daha yaygın olarak kabul edilen bir tanımına ihtiyaç duyulduğumun bir nedeni, çeşitli kafa karıştırıcı ve kötü yapılandırılmış tanımlara sahip olmanın, insanların “teori” tarafından geçirilme riskini arttırması ve DevOps’un süreçlerini veya araçlarını ilkeleri göz önünde bulundurmadan uygulamaktır. bu kesinlikle bir antipattern. Otomasyon sadece güç kullanımıdır ve akıllıca olmayan otomasyon akıllıca otomasyonun fayda sağlayabileceği kadar zarar verebilir.

Benzer şekilde, çevik uygulayıcılar, anlamlı işbirlikleri kurmadan tekrarlamalarda çalışmaya başlamanın ya da diğer özel uygulamaları benimsemenin size gerçekten iyi sonuç vermeyeceğini söyleyecektir. Çalıştığım şirketlerde, çevik yöntem ve / veya araçların bazılarını benimsemiş ancak prensiplerini benimsemiş bazı takımlar var ve sonuçlar yetersizdi. Elbette, bir araç Çevik’te (veya DevOps) yararlı olabilir, ancak nasıl kullanacağınızı bilmiyorsanız, o zaman eğitimsiz bir kişiye saldırı silahı vermek gibi bir şey.

Ancak sonuçta, “araçlar DevOps olarak adlandırılmamalı” hakkında endişelenmek yanlış yerleştirilmiş. Poker planlaması, ‘sihirli’ yapmanın sizi Çevik hale getirdiği anlamında “çevik” midir? Hayır. Ancak, çeşitli çevik metodolojilerde kullanılan yaygın bir araçtır, bu nedenle “çevik bir araç” olarak adlandırılması uygundur. Benzer şekilde, sadece DevOps araçların toplamı olmadığı için, bir DevOps zihniyetine uygun olarak sistemleri çalıştırmak için özel olarak tasarlanmış araçların değerli olmadığı anlamına gelmez. (Kesinlikle kullanmamı önlemek için özel olarak tasarlanmış bir takım araçlar var!)

(Sadece) Kültür Değil

Birçok kişi DevOps’un “sadece kültür” olduğunu ve sözünü belirli bir ilkeye veya uygulamaya uygulayamayacağınız konusunda ısrar ediyor, ancak bunun aşırı şişmiş ve yanlış olduğunu hissediyorum. Agile, binlerce geliştiricinin dükkanına yardım etmedi, çünkü onun üzerindeki çalışma, iş arkadaşlarına sarılmak için yapılan tavsiyelerde bulundu ve “en iyi uygulamaları tanımlayan en iyi uygulamaları tanımlayan lider pratisyenlerin, her şeyin açık ve net olduğunu reddetti. (Bunlardan bazıları olmasına rağmen). DevOps yukarıda listelediğim tüm seviyelerdeki nesnelerden oluşuyor ve çevresinde ortaya çıkan somut uygulama kitlesi olmadan büyük ölçüde işe yaramaz. Kültürel yön ve denemeye çok zaman harcanan tüm bu en iyi uygulamaları kendiniz çözebilirsiniz, ancak bilgi paylaşımı neden Internet’e sahip olduğumuzdur (ve bu konuda baskı yapıyoruz).

Değil (Sadece) Devs ve Ops

Ve sonunda, dışlayıcı değil. Bazı insanlar “Peki ya güvenlik insanları! Ve ağ yöneticileri! Neden bizi dışarıda bıraksın!?! ”Mesele şu ki, bir ürün ya da sistem yaratmadaki tüm katılımcıların başlangıçtan itibaren işbirliği yapmaları gerekiyor – çeşitli çizgilerin iş arkadaşları, çeşitli çizgilerin geliştiricileri ve çeşitli çizgilerin işlem insanları , ağ ve başka biri. Birçok farklı iş ve geliştirici paydaşları da var; Sadece herkes belirli bir çağrı almadığından (“Simge tasarımcılarını unutma!”) dahil olmadıkları anlamına gelmez. Orijinal çevik gelişim adamları çoğunlukla “biz + dev” işbirliğini düşünüyorlardı ve DevOps, “dev + ops” işbirliğine ilişkin sorunları ve çözümleri işaret ediyor. ancak tüm bunların olgun sonucu “herkes işbirliği”. Bu anlamda DevOps, bir disiplinin bir organizasyondaki tüm disiplinleri içermesi gereken genel çevik işbirliği kültürüne katılması için atılmış büyük bir adımdır. Öyleyse, yazılım veya hizmetin teslimatına katılan herkes DevOps’un bir parçasıdır.

(Sadece) Bir İş Unvanı Değil

Sadece mevcut bir ops ekibini almak ve onlara “DevOps Ekibi” adını vermek, aslında hiçbir şeye yardımcı olmuyor. Bir iş ünvanını “DevOps Engineer” olarak değiştirmek de mümkün değildir. Yukarıda belirtilen değerleri ve prensipleri benimsememeniz durumunda, sadece belirli bir takım içinde değil, genel bir sistem düzeyinde değişiklik yapılması gereken tüm avantajları elde edemezsiniz.

Bununla birlikte, kampta değilim ki, bir iş unvanında DevOps’a sahip olamayacaksınız. ”Bir iş unvanında“ yeni tarz DevOps düşünen, ilk önce otomasyon ilk önce yeni “İşbirliği yapan, CI çalışan, vb.” “şirketinizin geçim için ne yaptığını umursamayan, sersemlemiş arka odadan” sysadmin. Kendimi işe alma müdürü olarak, sistem mühendisliği için bir iş ilanına koyduğumda başvuru sahibinin durumu konusunda net bir fark görüyorum, bu da bunu sürdürmem için bana bir teşvik sunuyor.

Herşey Değil

Bazen, DevOps insanları devralınır ve DevOps’un “her yerdeki her şey hakkında” olduğu iddiasıyla büyük iddialar yapar! DevOps, pek çok yalın ve çevik düşüncenin genel yapısına bağlandığı ve kuruluş boyunca bu tür bir işbirliği için fırsatlar olduğu için, tüm paralellikler görmek güzel, ancak iş süreçlerinize gidip yeniden düzenlemek gerçekten de aslında DevOps değil. Genel, umarım işbirliğine dayalı ve çevik bir kurumsal kültürün bir parçasıdır, ancak DevOps özellikle operasyonların buna nasıl bağlı olduğu ile ilgilidir. Bazı insanlar, DevOps’u Lean, Agile’nin süper sulandırılmış bir versiyonuna dönüştürüyor ya da herkese sevgiyle geçiyorlar. Görme düzeyinde harika olan, ancak tanecik hiyerarşisi içinde yürüdüğünüz gibi, çoğunlukla operasyonel entegrasyonla uğraşırsınız – diğer çabalar diğer kısımlar için endişe duyuyor (şahsen de elbette). Ancak, yazılımın sunulması ve hizmetlerin bakımı ile hızlı, güvenilir, güvenli ve benzeri hale getirme konusunda hâlâ çözülmemiş bir çok sorun var. – eğer birisi DevOps’tan öğrendiklerini kullanmak için daha iyi bir kapsam dahilinde bir şirket danışmanı olmak istiyorsa, ancak DevOps’ta yer alan çoğu kişi daha iyi yollar arayan teknik pratisyenlerdir.onların işi, başkasının değil. Çevik’te “Çevik Yazılım Geliştirme” ve ardından daha büyük Çevik organizasyon çalışması var. Bence DevOps en iyi “Çevik Yazılım Teslimat ve İşlemleri” olarak tanımlanıyor, daha büyük organizasyonel inisiyatifler üzerinde çalışan diğerleriyle aynı şekilde çalışmalı, ancak organizasyon için birincil değer önerisini kaybetmeden çalışmalı.

DevOps ile Başlarken

DevOps’a giden bir yol yok – sadece kuruluşunuzda işe yarayanlar var. Çok başarılı DevOps girişimleri, dev ekiplerden ve ops ekiplerinden, yukarıdan aşağıya ve yukarıdan aşağıya, şirket içinden ve danışmanlardan, yaygın eğitim ve skunkwork pilotlarıyla başlatılmıştır. Bu nedenle, nasıl uygulayabileceğinizi gösteren genel bir oyun kitabı vermek zordur. DevOps’un değerlerini, ilkelerini, yöntemlerini ve uygulamalarını öğrenerek ve onu en etkili olan kanalla yaymaya çalışmakla başlayacağınızı söylemenin güvenli olduğunu düşünüyorum. daha DevOps’ta kendin yap ve başarının kendisi için konuşmasına izin ver… İnsanlar, işlerinin kuruluşunda nasıl başarılı olabileceğini anlatmaya çalışacaklar, ama bu tavsiye genellikle gerçeklikten daha fazla politika ve arzulu bir düşüncedir. Kuruluşunuzdaki diğer popüler şeylerin nasıl ortaya çıktığını ve para kazandığını gözlemleyin ve aynı kanalları deneyin. Ve öğrenmeye devam et.

LinkedIn Öğrenme Kursları

Çünkü DevOps eğitim durumundan hüsrana uğradığımız için, insanların temel DevOps kavramlarını öğrenmelerine yardımcı olmak için lynda.com/LinkedIn Learning ile bazı kurslar oluşturmaya başladık! Onları kontrol et:

• DevOps Vakıfları (James, Ernest) – yeni başlayanları DevOps’un kapsamına yönlendirmek için tasarlanmış üç saatlik bir dizi video.  Burada daha fazla bilgi edinin!
• DevOps Vakıfları: Kod Olarak Altyapı (James, Ernest) – iki saat altyapı otomasyonu konsepti, gösterileri Cloudformation’den şefe kadar her konuda gösteren.
• DevOps Vakıfları: Sürekli Entegrasyon / Sürekli Teslimat (James, Ernest) – sürekli entegrasyon ve teslimat hakkında bilmeniz gerekenler, jenkins, nexus ve diğerlerinde gösteriler.
• DevOps Vakıfları: Yalın ve Çevik (Karthik, Ernest) – Yalın ve Çevik, DevOps’u temel düzeyde bilgilendirir ve yöntemlerini benimsemek başarınıza katkıda bulunur.
• DevOps Temelleri: Site Güvenilirlik Mühendisliği (James, Ernest) – DevOps’un IaC ve CI / CD ile birlikte “Üçüncü Ayağı”, işte ops’un “ops” kısmı.
• DevOps Temelleri: İzleme ve Gözlenebilirlik (Peco, Ernest) – İzleme, SRE kursundan ayrı yaptığımız çok büyük bir konudur.

DevOps Okuma Listesi

DevOps hala yeni, bu nedenle aylık olarak değişen tanımsız bir blog grubu ve Twitter’daki insanları takip etmek çoğu zaman güncel bilgilerin en iyi kaynağı. Evet, bu can sıkıcı. Bununla birlikte, kullanabileceğiniz ve sonra başkalarıyla paylaşabileceğiniz birkaç kitap ve diğer güvenilir iyi bilgi kaynakları vardır.

• En çok tercih edilen – DevOps El Kitabı , Gene Kim, Patrick Debois, John Willis, John Allspaw ve Jez Humble tarafından 2016 yılının sonlarında çıktı ve sonunda DevOps’ta kesin bir kaynak oldu. Sadece bir kitap alırsan, bunu al.
• Phoenix Projesi , Gen Kim, George Spafford, Kevin Behr – Seminal Yalın çalışmasından esinlenilen yeni formatta Amaç, bu, sorunlu bir yazılım şirketindeki bir DevOps uygulamasının bir anlatısıdır.
• Web Operasyonları , çeşitli – DevOps’un en önemli öncülerinin birçoğunun düşünceleri olan Web operasyonları hakkında bir dizi makale toplayan bir O’Reilly kitabı.
• Sürekli Teslimat , Jez Humble ve David Farley – CI / CD, bazı insanların sahip olacağı gibi toplam DevOps toplamı olmasa da, kesinlikle büyük bir inovasyon alanı ve işte bu konuda kesin bir çalışma.
• Büyük Ölçekli Çevik Geliştirmeye Pratik Bir Yaklaşım , Gary Gruver – DevOps’un sadece yeni başlayanlar için ya da sadece Web yazılımı için olduğunu düşünenler için, bu, HP LaserJet ürün yazılımı bölümünün nasıl çevik / CI / DevOps yapısına geçtiğinin hikayesidir.
• Bulut Sistem Yönetimi Uygulaması , Tom Limoncelli, Strata Chalup, Christina Hogan – Operasyonlar tarafında bir çok yeni stil sistem rehberliği ve çok sayıda açık DevOps içeriği içeren bir kitap stil rehberi.
• Bırak onu! , Michael Nygard – Bunun gibi daha fazla kitap olması gerekiyor, ortak sistemlerdeki başarısızlık kalıplarını ve başarı kalıplarını açıklıyor – Bunu sistemler için Dört Tasarım Desenleri Çetesi kitabı olarak düşünüyorum.
• Yazılım Geliştirme Yalın , Mary ve Tom Poppendieck – Lean, DevOps topluluğu içinde giderek daha fazla kabul görüyor, ancak Deming ve TPS’den başlamak biraz korkutucu. Bu kitap Yalın yazılımdaki en önemli eserdir.
• Ve Gareth Rushgrove’s DevOps Weekly e-posta bülteniyle tamamlayın .