DevOps Nedir?
Blog
DevOps'un ne olduğu hakkında daha iyi bir yol mu bulmaya çalışıyorsun? İşte bilmeniz gereken sekiz temel kavram!
DevOps, birçok insan için birçok farklı şey anlamına gelen aşırı yüklenmiş bir kelimedir. DevOps'un ne olduğunu anlamaya veya DevOps'u tanımlamaya çalıştığınızda bu bir zorluktur. DevOps'u tanımlamaya çalışmak yerine, farklı kişilerin DevOps ile ilişkilendirdiği temel kavramları ve DevOps hareketinin bütünsel bir bakış edinmenize yardımcı olmak için nasıl geliştiği tarihini açıklayacağız:
1. DevOps Nereden Geldi?
DevOps, çevik yazılım geliştirmenin ürünüdür - artan yazılım hızına ayak uydurma ihtiyacından doğar ve verim çevik yöntemlere ulaşır . Çevik kültürdeki gelişmeler ve son on yıldaki yöntemler, uçtan uca yazılım teslim yaşam döngüsüne daha bütünsel bir yaklaşım gerekliliğini ortaya koydu.
Çevik Yazılım Geliştirme Nedir?
Agile Development, çeşitli yinelemeli ve artımlı yazılım geliştirme metodolojileri için kullanılan bir terimdir. En popüler çevik metodolojiler, Scrum, Kanban, Scaled Agile Framework® (SAFe®), Yalın Gelişim ve Aşırı Programlama'dır (XP).
Çevik metodolojilerin her biri kendine özgü yaklaşımında benzersiz olmasına rağmen, hepsi ortak bir vizyon ve temel değerleri paylaşır (bkz. Çevik Manifesto ). Hepsi temel olarak bir yazılım sistemini başarılı bir şekilde geliştirmek ve sunmak için sunduğu yinelemeyi ve sürekli geri bildirimi içerir. Hepsi sürekli planlama, sürekli test, sürekli entegrasyon ve hem projenin hem de yazılımın diğer sürekli gelişim biçimlerini içerir. Hepsi, özellikle geleneksel şelale tarzı işlemlere kıyasla hafif ve kendinden uyumludur. Çevik yöntemler konusunda en önemli şey, hepsinin insanların birlikte çalışmasını ve birlikte hızlı ve etkili bir şekilde karar vermelerini sağlamaya odaklanmalarıdır.
Başlangıçta, çevik ekipler öncelikle geliştiricilerden oluşuyordu. Bu çevik ekipler yazılım üretmede daha etkili ve verimli hale geldikçe, Kalite Güvence (KG) ve Dev'in ayrı ekipler olarak sahip olmasının yetersiz kaldığı ortaya çıktı. Çeviklik, yazılım sağlama hızını arttırmak için KG'yi kapsayacak şekilde büyüdü ve şimdi çeviklik, düşünceyi teslim etmeye çevikliği arttırmak için teslimat ve destek üyelerini kapsayacak şekilde bir kez daha büyüyor.
DevOps, tasarım ve üretim desteği ile tasarımdan tam işlevselliğe sahip çapraz işlevli ekipleri güçlendirirken, yazılım geliştirme, yapım, doğrulama ve dağıtım aşamalarındaki değişimin hareketini daha da hızlandırarak çevik geliştirme uygulamalarını genişletti.
DevOps, yazılım sağlama hızını ve kalitesini artırmak için yazılım geliştiricileri ve BT operasyonları arasında iletişimi, işbirliğini, entegrasyonu ve otomasyonu teşvik eden bir BT zihniyetidir.
DevOps ekipleri, teslimat öngörülebilirliğini, verimliliği, güvenliği ve sürdürülebilirliği geliştirmek için geliştirme ortamlarını standartlaştırmaya ve teslimat süreçlerini otomatikleştirmeye odaklanıyor. DevOps idealleri, geliştiricilere üretim ortamını daha iyi kontrol etmelerini ve üretim altyapısını daha iyi anlamalarını sağlar. DevOps, kendi uygulamalarını kurma, onaylama, teslim etme ve destekleme yetkisine sahip ekipleri güçlendirmektedir. DevOps ile hiçbir şey “duvarın üzerinden atılmaz”.
2. DevOps'un Çözdüğü Zorluklar Nelerdir?
DevOps uygulama geliştirmesinden önce, ekipler bir yazılım programı için iş gereksinimlerini toplamaktan ve kod yazmaktan sorumluydu. Ardından, ayrı bir KG ekibi, gereksinimleri karşılanırsa programı yalıtılmış bir geliştirme ortamında test eder ve uygulanacak işlemlerin kodunu bırakır. Dağıtım ekipleri ayrıca ağ ve veritabanı gibi sessiz gruplara ayrılmıştır. Bir yazılım programı her seferinde “duvarın üzerinden atılan” bağımsız bir ekibe darboğazlar ekler. Bu paradigma ile ilgili sorun, ekiplerin ayrı çalışması durumunda:
- Dev, genellikle programın beklendiği gibi çalışmasını önleyen KG ve Ops engellerinin farkında değildir.
- QA ve Ops tipik olarak birçok özellik üzerinde çalışır ve işin amacı ve yazılımın değeri hakkında çok az içeriğe sahiptir.
- Her grubun, bir şeyler ters gittiğinde verimsizliğe ve parmak işaretine yol açabilecek karşı hedefleri vardır.
DevOps, bu sorunları, yazılımı çalıştıran sistemi sürdürme sorumluluğunu paylaşan ve yazılım üzerinde çalışan kalite geri bildirimi ve otomasyon sorunları ile bu sistem üzerinde çalışacak şekilde hazırlanan sorumluluğu paylaşan ortak çalışanlar arası ekipler kurarak çözmektedir.
Ortak DevOps Öncesi Senaryo
Mümkün olduğu kadar çok özellik gönderme hedefine sahip olan Dev ekibi, “duvarın üzerinden” QA'ya yeni bir sürüm kazandırdı. O zaman test cihazının amacı mümkün olduğunca fazla hata bulmaktır. Test uzmanları bulgularını Dev'e getirdiğinde, geliştiriciler savunmacı hale gelir ve çevreyi böcekler için test eden test cihazlarını suçlar. Test edenler, test ortamları değil, problemi oluşturan geliştiricinin koduna cevap verirler.
Sonunda sorunlar çözüldü ve KG, hata ayıklanan yeni duvardan “duvarın üzerinden” Ops'a geçti. Ops ekibinin amacı sistemindeki değişiklikleri sınırlandırmak, ancak kodun derhal serbest bırakılmasını sağlıyor ve sistem çöküyor. Parmakla işaret devam eder.
Ops, Dev'in onlara hatalı eserler sağladığını söylüyor. Dev, test ortamında her şeyin iyi çalıştığını söylüyor. Yangın tatbikatları sistemin hatalarını gidermeye ve üretimi istikrarlı hale getirmeye başlar. Üretim ortamı Dev'in ve KG'nın sorumluluğu değildir, bu yüzden Ops tüm sorunları üretim sorunlarını gidermek için harcar.
3. DevOps'un Amacı Nedir?
Planlamaktan, teslimat sürecinin otomasyonuna kadar tüm paydaşlar arasında aşağıdakileri sağlamak için teslimat sürecinin otomasyonunu geliştirmek:
- Dağıtım sıklığını iyileştirin
- Pazarlamak için daha hızlı zaman kazanın
- Yeni sürümlerin düşük başarısızlık oranı
- Düzeltmeler arasındaki teslim süresinin kısaltılması
- İyileşme için ortalama süreyi iyileştirin
2015 DevOps Eyalet Raporuna göre, “yüksek performanslı BT organizasyonları 200 kat daha kısa teslim süreleriyle 30 kat daha sık konuşlandırıyor; 60x daha az hataya sahipler ve 168x daha hızlı iyileşiyorlar. ”
Ortak DevOps Öncesi Senaryo
Yazılım ekibi, yeni bir yazılım projesine başlamadan önce toplanır. Ekip geliştiricileri, test uzmanlarını, operasyonları ve destek profesyonellerini içerir. Bu ekip konuşlandırmaya hazır bir çalışma yazılımı oluşturmayı planlıyor.
Her gün geliştiriciler tamamladıkça yeni kodlar dağıtılır. Otomatik test, kodun konuşlandırılmaya hazır olmasını sağlar. Kod tüm otomatik testleri geçtikten sonra, az sayıda kullanıcıya dağıtılır. Yeni kod, öngörülemeyen bir sorun olmadığından ve istikrarlı olduğundan emin olmak için kısa bir süre boyunca izlenir. Daha sonra, izleme kararlı olduğunu gösterdiğinde, yeni kod kalan kullanıcılara çoğaltılır. Pek çoğu, hepsi olmasa da, planlama ve geliştirmeden sonraki adımların hiçbiri insan müdahalesi olmadan gerçekleştirilir.
4. DevOps Sürekliliği Neredesiniz?
DevOps sürekliliği, DevOps'un farklı yönlerine bakmak için yararlı bir yoldur. Alt yatay eksen, insanların DevOps'u temel olarak odaklandığını algıladıklarını gösterir. Bazı insanlar kesinlikle DevOps'un kültüre araçlara göre daha fazla odaklanması gerektiğini düşünürken, diğer insanlar kültür üzerine araçlara değer verme eğilimindedir.
Dikey eksen, DevOps teslimat zincirinin üç seviyesini gösterir: sürekli entegrasyon, sürekli teslimat ve sürekli dağıtım. DevOps topluluğu, DevOps süresinin sağ üstündeki örgütleri pembe tek boynuzlu atlar olarak adlandırmaktadır, çünkü şu anda onları çok az sayıda vahşi doğada görmeyeceksiniz. Bu tek boynuzlu atların popüler örnekleri Netflix, Etsy, Amazon, Pinterest, Flicker, IMVU ve Google gibi şirketlerdir. Son anketlerde katılımcılar, kuruluşlarının DevOps sürekliliğine nerede uyduğunu belirtti:
- % 55 alt sol
- % 26 Alt Sağ
- % 14 Üst Sol
- % 5 Üst Sağ
Düşünce liderleri, antrenörler ve blogcular çoğunlukla sağ üst köşede bir DevOps vizyonunu resmediyorlar ve çoğu zaman DevOps kültürüne veya otomasyon araçlarına karşı güçlü bir önyargıya sahip olacaklar. DevOps kültürünün ya da araçlarının daha önemli olup olmadığı hakkında ezoterik tartışmalar yapmak uygun olsa da, gerçek şu ki araç kullanmadan DevOps'a sahip olamayacaksınız ve dünyadaki tüm araçlar güçlü bir desteğiniz yoksa yardımcı olmaz kültür.
Bir diğer önemli nokta, sağa ve yukarıya doğru ilerlemenin zaman alması ve birçok kuruluşun ilk adımının kültür, araçlar ve sürekli entegrasyonun bir karışımı olacağı, bu yüzden “yapmamanız” konusundaki bir makaleyi okuduğunuzda cesaretiniz kırılmamalıdır. İnsan müdahalesi olmadan üretime girmediğiniz sürece “DevOps yapmak”.
DevOps, kurumunuz için anlamlı olan kültürün, araçların ve olgunluğun bir karışımı olabilir ve mantıklı olan şey, zaman içinde büyük olasılıkla gelişecektir. Önemli olan, işbirliğini ve otomasyonu iyileştirerek, yazılım teslim aşamaları arasındaki duvarları ve darboğazları sürekli olarak kırmaya çalışmaktır. İlerleyen bölümlerde, nereye uyduğunuzu daha iyi anlamanıza yardımcı olmak için DevOps sürekliliğinin her bir yönüne daha derine dalıyoruz.
5. DevOps Olgunluğunun Aşamaları Nelerdir?
DevOps'un olgunluğunun birkaç aşaması vardır; İşte bilmeniz gereken anahtar aşamalardan birkaçı.
Şelale Gelişimi
Sürekli entegrasyondan önce, geliştirme ekipleri üç ila dört ay boyunca bir sürü kod yazacaktı. O zaman bu takımlar kodu serbest bırakmak için kodlarını birleştirirdi. Farklı kod sürümleri çok farklı olacak ve gerçek entegrasyon adımının aylar alabileceği çok fazla değişiklik olacaktı. Bu süreç çok verimsizdi.
Sürekli Bütünleşme
Sürekli entegrasyon, yeni geliştirilen kodu, piyasaya sürülecek olan ana kod kütlesiyle hızlı bir şekilde bütünleştirme uygulamasıdır. Sürekli entegrasyon, takım kodu serbest bırakmaya hazır olduğunda çok zaman kazandırır.
DevOps bu terim ile gelmedi. Sürekli entegrasyon, Extreme Programming metodolojisinden kaynaklanan çevik bir mühendislik uygulamasıdır. Terimler bir süredir var ancak DevOps bu terimi benimsemiştir çünkü sürekli entegrasyonu başarıyla yürütmek için otomasyona ihtiyaç vardır. Sürekli entegrasyon genellikle DevOps vadesine giden yolda ilk adımdır.
Bir DevOps perspektifinden sürekli entegrasyon işlemi, kodunuzu kontrol etmeyi, kullanılabilir (genellikle ikili çalıştırılabilir) kod haline getirmeyi ve bazı temel doğrulama testlerini çalıştırmayı içerir.
Sürekli teslimat
Sürekli teslimat, sürekli entegrasyonun bir uzantısıdır [DevOps stage 2]. Sürekli entegrasyonun tepesinde oturuyor. Sürekli teslimat gerçekleştirirken, ek otomasyon ve testler eklersiniz, böylece kodu yalnızca ana kod satırıyla birleştirmezsiniz, ancak kodu neredeyse hiç insan müdahalesine gerek kalmadan dağıtmaya hazır hale getirirsiniz. Kod tabanının kurulmaya hazır bir durumda sürekli olması pratiktir.
Sürekli Dağıtım
Sürekli dağıtım, sürekli teslimatla karıştırılmaması gereken [DevOps nirvana], sürekli teslimatın en gelişmiş evrimidir. İnsan müdahalesi olmadan tüm yolu üretime sokma uygulamasıdır.
Sürekli teslimat kullanan ekipler denenmemiş kodlar kullanmazlar; bunun yerine, yeni oluşturulan kod üretime gönderilmeden önce otomatik testlerden geçirilir. Kod açıklaması genellikle küçük bir kullanıcı yüzdesine gider ve kodun ilerletilmesinden önce kaliteyi ve kullanımı izleyen otomatik bir geri bildirim döngüsü vardır.
Sürekli dağıtımı gerçekten uygulayan çok az sayıda şirket vardır. Netflix, Etsy, Amazon, Pinterest, Flicker, IMVU ve Google, sürekli dağıtım yapan şirketlerin popüler örnekleridir.
DevOps nirvana çoğu işletme için genellikle nihai hedef olmasa da, sürekli teslimat için hareket etmeye odaklanırlar.
6. DevOps'un Değerleri Nelerdir?
DevOps, yoğun bir şekilde işbirliğine dayalı bir kültür kurmaya ve DevOps araçlarıyla otomasyonla verimliliği arttırmaya odaklanmaktadır. Bazı kuruluşlar ve insanlar birbirlerinden daha değerli olmalarına rağmen, gerçek şu ki başarılı olmak için hem kültürün hem de araçların bir kombinasyonunu alıyor. İşte bu iki DevOps değeri hakkında bilmeniz gerekenler.
DevOps Kültürü
DevOps kültürü, artan işbirliği, siloları azaltma, ortak sorumluluk, özerk ekipler, kaliteyi iyileştirme, geri bildirime değer verme ve otomasyonu artırma özelliğine sahiptir. DevOps değerlerinin birçoğu çevik değerlerdir, çünkü DevOps çevikliğin bir uzantısıdır.
Çevik yöntemler, yazılım sunmanın daha bütünsel bir yoludur. Çevik geliştirme ekipleri, çalışma yazılımı açısından ilerlemeyi ölçer. Ürün sahipleri, geliştiriciler, test edenler ve UX çalışanları aynı amaçlarla birlikte çalışırlar.
DevOps, sadece operasyonların zihniyetini ve belki de bu sorumlulukların bazılarını çevik ekibine ekleyen bir ekip üyesi. DevOps ilerlemesi çalışma yazılımı açısından ölçülmeden önce, DevOps ilerlemesi müşterinin elinde çalışma yazılımı açısından ölçülür.
Bunu başarmak için, Dev ve Ops siloları parçalara ayırmalı ve birbirleriyle işbirliği yapmalı, yazılımı çalıştıran sistemi sürdürme sorumluluğunu paylaşmalı ve yazılımı artan kalite geri bildirimi ve teslimat otomasyonu ile sistem üzerinde çalışacak şekilde hazırlamalıdır.
DevOps Araçları
DevOps araçları konfigürasyon yönetimi, test ve yapı sistemleri, uygulama dağıtımı, sürüm kontrol ve izleme araçlarından oluşur. Sürekli entegrasyon, sürekli teslimat ve sürekli dağıtım farklı araçlar gerektirir. Her üç uygulama da aynı araçları kullanabilse de, teslimat zincirinde ilerledikçe daha fazla araca ihtiyacınız olacak.
7. DevOps'ta Hangi Araçlar Kullanılır?
Daha önce DevOps'ta kullanılan bazı araçları kısaca tartıştık; İşte bilmeniz gereken temel araç ve uygulamalardan bazıları.
Kaynak Kodu Deposu
Bir kaynak kod deposu, geliştiricilerin giriş yaptıkları ve kod değiştirdikleri bir yerdir. Kaynak kod deposu, kontrol edilen çeşitli kod sürümlerini yönetir, böylece geliştiriciler birbirlerinin çalışmalarını yazmazlar.
Kaynak kontrolü muhtemelen kırk yıldan beri sürmektedir, ancak sürekli entegrasyonun ana bileşenidir. Popüler kaynak kodu deposu araçları Git, Subversion, Cloudforce, Bitbucket ve TFS'dir.
Sunucu Oluştur
Yapı sunucusu, kaynak kod havuzundaki kodu yürütülebilir kod tabanına derleyen bir otomasyon aracıdır. Popüler araçlar Jenkins, SonarQube ve Artifactory'dir.
Konfigürasyon yönetimi
Yapılandırma yönetimi, bir sunucunun veya ortamın yapılandırmasını tanımlar. Popüler yapılandırma yönetimi araçları Kukla ve Şef'tir.
Sanal Altyapı
Amazon Web Servisleri ve Microsoft Azure, sanal altyapıların örnekleridir. Sanal altyapılar, altyapıyı veya platformu bir hizmet olarak satan bulut satıcıları tarafından sağlanır (PaaS). Bu altyapıların kukla ve şef gibi yapılandırma yönetimi araçlarıyla programlı olarak yeni makineler oluşturmanıza olanak sağlayan API'leri vardır.
Özel bulutlar da var. Örneğin, VMware'de vCloud var. Özel sanal altyapılar, veri merkezinizdeki donanımın üzerinde bir bulut çalıştırmanızı sağlar.
DevOps uygulayan kuruluşlara, klavyede parmak kullanmadan bir sunucuyu yapılandırabilme yeteneği kazandırmak için otomasyon araçlarıyla birleştirilmiş sanal altyapılar. Yepyeni kodunuzu test etmek istiyorsanız, otomatik olarak bulut altyapınıza gönderebilir, çevreyi oluşturabilir ve tüm testleri insan müdahalesi olmadan çalıştırabilirsiniz.
Test Otomasyonu
Test otomasyonu uzun süredir var. DevOps testi, konuşlandırılabilir bir yapıya sahip olduğunuzda, konuşlandırılmaya hazır olduğundan emin olduğunuzdan emin olmak için yapı hattınızdaki otomatik testlere odaklanır. Kapsamlı bir otomatik test stratejisi olmadan kodunuzun konuşlandırıldığına dair herhangi bir insan müdahalesi olmadan oldukça güvendiğiniz bir yerde sürekli teslimat noktasına gelemezsiniz. Popüler araçlar Selenyum ve Su'dur.
Boru Hattı Orkestrasyonu
Bir boru hattı, bir geliştiricinin “Yapıldığımı” söylediği andan itibaren, kodun üretim veya geç aşama öncesi üretim ortamında devreye alındığı ana kadar olan bir üretim montaj hattı gibidir.
Kurumsal Yazılım Geliştirme ve Teslimatı Birleştirme
VersionOne VS, çevik uygulama yaşam döngüsü yönetimini ve DevOps'u birleştirerek, tüm yazılım teslim hattınızın tek bir platformda tam bir resmini sunar. DevOps için VersionOne® Continuum ™ , yazılım dağıtım döngüsü boyunca değişiklik akışını otomatikleştirmek, düzenlemek ve görselleştirmek için kurumsal bir sürekli dağıtım çözümüdür.
8. DevOps'un Tarihi Nedir?
2007
Bir yazılım geliştirme danışmanı olan Patrick Debois, BT'nin tüm yönlerini öğrenme hedefine sahipti. On beş yıldan fazla bir süredir Patrick, bir BT organizasyonunun her rolünde çalışmak ve BT hakkında bütüncül bir anlayış kazanmak için BT'de birçok farklı rol üstlenmiştir. Bir geliştirici, ağ uzmanı, sistem yöneticisi, test cihazı ve proje yöneticisi olarak çalıştı.
Patrick büyük bir veri merkezi göçü için danışmanlık işi aldı. Testten sorumluydu, bu da Dev ve Ops ile çok fazla zaman geçirdiği anlamına geliyordu. Patrick, Dev ve Ops'un nasıl çalıştığı arasındaki farklardan her zaman rahatsız olmuştu, ancak özellikle bu veri merkezi göçü üzerindeki iki grup arasında çalışmayı yönetme zorlukları yüzünden hüsrana uğramıştı.
Sürekli entegrasyon çevik toplulukta popülerlik kazanıyordu ve Dev'i konuşlandırmaya yaklaştırıyordu, ama hala Dev ve Ops'un bölünmesini tamamen geçen hiçbir şey yoktu. Patrick, bu iki ekibin birlikte çalışması için daha iyi bir yol olması gerektiğinden emindi.
2008
Andrew Shafer, Agile 2008 Konferansında çevik bir altyapı “kuş tüyü kuşları” oturumu için bir fikir sundu. Patrick Debois göreve geldi ve oturuma gitti. Ne yazık ki, ortaya çıkan tek kişi oydu. Bu fikir o kadar kötü kabul edildi ki, Andrew kendi tartışmasını bile göstermedi.
Neyse ki, Patrick, bir başkasının birlikte çalışan Dev ve Ops'un zorluklarını çözmekle ilgilendiğini görmek için çok heyecanlandı ve Andrew'u takip etti ve Çevik Sistem Yönetimi adlı bir Google grubunu başlatmaya karar verdiler.
2009
Flickr'de teknik operasyonlar başkan yardımcısı olan John Allspaw ve Flickr'da mühendislik direktörü Paul Hammond, San Jose'deki O'Reilly Velocity Konferansında “Günde 10+ Birlikçi: Flickr'da Dev ve Ops İşbirliği” konulu sunum yaptı. Sunum, Dev ve Ops'un yazılım dağıtımını iyileştirmek için birlikte nasıl etkili bir şekilde çalışabileceğinin temelini attı.
Patrick Debois, Belçika'daki sunumu canlı bir akış üzerinden izledi ve kendi konferansını, DevOpsDays, Belçika'nın Gent kentinde başlatmak için ilham verdi. Konferans, yazılım dağıtımını iyileştirmeye çalışan enerjik ve ileri görüşlü bir grup oluşturdu. Daha da önemlisi, bu grup insanın Twitter'da #DevOpsDays etiketiyle sohbeti sürdürdüğüdür. Twitter karakter alanından tasarruf etmek için, insanlar yakında günler düştü ve hashtag #DevOps oldu.
2010
Ertesi yıl, DevOpsDays Avustralya ve ABD'de yapıldı. Zamanla, dünyadaki farklı ülkelerde ve şehirlerde ev sahipliği yapan daha fazla DevOpsDay oldu. Yüz yüze toplantılar, tam bir taban hareketi haline gelinceye kadar DevOps hakkında enerji almaya gittikçe daha fazla insanı ateşledi.
2011
2011 yılına kadar, DevOps hareketi bireyler ve analistlerden veya satıcılardan çok az dikkat çeken açık kaynak araçları tarafından beslendi. Ancak 2011'de, hareket, Gartner'dan Cameron Haight ve 451 Research'ten Jay Lyman gibi analistlerin dikkatini çekerek ana akım olmaya başladı. Büyük satıcılar DevOps'u pazarlamaya başladı.
2012
2012 yılına gelindiğinde DevOps hızla bir kelimeye dönüşüyordu ve DevOpsDays büyümeye devam ediyordu.
2013
DevOps bilgisine olan halkın susuzluğu bazı yazarlara konuyla ilgili kitap yazmak için ilham verdi. Dikkate değer örnekler, Gene Kim, Kevin Behr ve George Spafford'dan Phoenix Projesi ve Mary ve Tom Poppendiek tarafından Yalın Yazılım Geliştirme Uygulamasıdır .
2014 Target, Nordstrom ve LEGO gibi büyük şirketler DevOps'u işletmeye getiren ilk şirketlerden biri oldu.
