DevOps - DevOps

DevOps , yazılım geliştirme ( Dev ) ve BT operasyonlarını ( Ops ) birleştiren bir dizi uygulamadır . Sistem geliştirme yaşam döngüsünü kısaltmayı ve yüksek yazılım kalitesi ile sürekli teslimat sağlamayı amaçlar . DevOps, Çevik yazılım geliştirmenin tamamlayıcısıdır ; Çevik metodolojiden birkaç DevOps yönü geldi.

Tanım

"Geliştirme" ve "operasyonlar" terimleri ve kavramlarının işlevler arası bir kombinasyonu olmasının dışında, akademisyenler ve uygulayıcılar "DevOps" terimi için evrensel bir tanım geliştirmediler. Çoğu zaman DevOps, temel ilkelerle karakterize edilir: paylaşılan sahiplik, iş akışı otomasyonu ve hızlı geri bildirim.

Akademik bir bakış açısıyla, CSIRO ve Yazılım Mühendisliği Enstitüsü'nden üç bilgisayar bilimi araştırmacısı olan Len Bass , Ingo Weber ve Liming Zhu, DevOps'u "bir sistemde değişiklik yapma ve değişiklik, yüksek kaliteyi sağlarken normal üretime yerleştirildi".

Bununla birlikte, terim birden çok bağlamda kullanılır. En başarılı haliyle DevOps, belirli uygulamaların, kültür değişikliğinin ve araçların bir birleşimidir.

Tarih

1993 yılında Telekomünikasyon Bilgi Ağı Mimarisi Konsorsiyumu ( TINA-C ), yazılım geliştirmeyi (telekom) hizmet operasyonlarıyla birleştiren bir Hizmet Yaşam Döngüsü Modeli tanımladı. DevOps ait "yukarıdan aşağıya" yasaklayıcı yaklaşıma bir tepki olarak kısmen ortaya çıktığını Bazı diyelim ITIL 1990'larda. DevOps, "aşağıdan yukarıya" bir yaklaşım olarak, yazılım mühendisleri tarafından yazılım mühendisleri için yaratıldığı ve katı bir çerçeveden ziyade esnek bir uygulama olduğu için çekiş kazandı ve ısrar etti.

2014'te Lisa Crispin ve Janet Gregory, test ve DevOps hakkında bir bölüm içeren More Agile Testing kitabını yazdı.

alet zincirleri

DevOps'un işlevler arası bir çalışma modu olması amaçlandığından, metodolojiyi uygulayanlar, tek bir araç yerine farklı araç setleri kullanır - " araç zincirleri " olarak adlandırılır . Bu araç zincirlerinin, geliştirme ve teslim sürecinin temel yönlerini yansıtan aşağıdaki kategorilerden bir veya daha fazlasına uyması beklenir.

  1. Kodlama – kod geliştirme ve inceleme, kaynak kod yönetimi araçları, kod birleştirme.
  2. Bina – sürekli entegrasyon araçları, inşa durumu.
  3. Test etme – iş riskleri hakkında hızlı ve zamanında geri bildirim sağlayan sürekli test araçları.
  4. Paketleme – yapıt deposu , uygulama dağıtım öncesi hazırlama.
  5. Yayınlama – değişiklik yönetimi, yayın onayları, yayın otomasyonu .
  6. Yapılandırma – altyapı yapılandırması ve yönetimi, kod araçları olarak altyapı .
  7. İzleme – uygulama performans izleme , son kullanıcı deneyimi.

Diğer yaklaşımlarla ilişki

DevOps uygulamaları için temel olan fikirlerin çoğu, Yalın ve Deming'in Planla- Uygula -Kontrol Et- Uygula döngüsü gibi diğer iyi bilinen uygulamalardan ilham alıyor veya bunları yansıtıyor , Toyota Way ve bileşenleri ve parti boyutlarını parçalamaya yönelik Agile yaklaşımı.

Atik

Modern DevOps'a dönüşen şeyin motivasyonları ve otomatik oluşturma ve test etme, sürekli entegrasyon ve sürekli teslimat gibi çeşitli standart DevOps uygulamaları , (gayri resmi olarak) 1990'lara ve resmi olarak 2001'e kadar uzanan Çevik dünyadan kaynaklanmıştır. Extreme Programming gibi yöntemler , birçoğu otomatikleştirdikleri uygulamalarıyla ilgili operasyonları / altyapı sorumluluklarını üstlenmedikçe "değerli yazılımların erken ve sürekli teslimi yoluyla müşteriyi tatmin edemez". Çünkü Scrum 2000'li yılların başında baskın Çevik çerçeve olarak ortaya çıkan ve birçok Çevik takımların parçası olan mühendislik uygulamalarını ihmal, hareket, modern DevOps hale geldiğini içine Çevik den parçalanmış ve genişletilmiş operasyonlar / altyapı fonksiyonlarını otomatik hale getirmek. Bugün DevOps, ister Agile ister diğer metodolojiler aracılığıyla geliştirilmiş olsun, geliştirilen yazılımın dağıtımına odaklanmaktadır.

ArchOps

ArchOps , operasyon dağıtımı için kaynak kodu yerine yazılım mimarisi yapılarından başlayarak DevOps uygulaması için bir uzantı sunar . ArchOps, mimari modellerin yazılım geliştirme, dağıtım ve operasyonlarda birinci sınıf varlıklar olduğunu belirtir.

CI/CD

Otomasyon, DevOps başarısına ulaşmak için temel bir ilkedir ve CI/CD kritik bir bileşendir.

CI/CD, sürekli entegrasyon (CI) ve sürekli teslim (CD) veya sürekli dağıtımdan (CD) oluşur. Birlikte kullanıldığında, üç süreç derleme, test etme ve dağıtımı otomatikleştirir, böylece DevOps ekipleri kod değişikliklerini daha hızlı ve daha güvenilir şekilde gönderebilir. CI/CD'den bahsederken, başvurulan "CD" genellikle sürekli dağıtımdır, sürekli dağıtım değildir. Sürekli teslim ve diğer CI/CD süreçleri, yazılım teslim görevlerini otomatikleştirmeye odaklanırken DevOps, ilgili birçok işlev arasında mükemmel işbirliğini desteklemek için organizasyonel değişime de odaklanır. Her ikisi de çevik yöntemlerde ve yalın düşüncede ortak bir arka planı paylaşıyor ve son müşteriye odaklanmış değerle küçük ve sık değişikliklere öncelik veriyor. Bu, iki şeyi garanti eder: Yazılım, yaşam döngüsü boyunca her zaman serbest bırakılabilir durumdadır, bu da yazılımı teslim etmeyi daha ucuz ve daha az riskli hale getirir.

Ayrıca, ekipler arasında ve ekipler içinde geliştirilmiş işbirliği ve iletişim , azaltılmış risklerle daha hızlı pazara sunma süresi elde edilmesine yardımcı olur .

Veri İşlemleri

Sürekli teslim ve DevOps'un veri analitiğine uygulanması DataOps olarak adlandırılmıştır. DataOps, veri mühendisliğini, veri entegrasyonunu, veri kalitesini, veri güvenliğini ve veri gizliliğini operasyonlarla bütünleştirmeyi amaçlar. Veri analitiğinden değer çıkarma döngü süresini iyileştirmek için DevOps, Çevik Geliştirme ve yalın üretimde kullanılan istatistiksel süreç kontrolünden ilkeleri uygular .

Site güvenilirlik mühendisliği

2003'te Google , yüksek kaliteli son kullanıcı deneyimini korurken büyük ölçekli yüksek kullanılabilirlik sistemlerine sürekli olarak yeni özellikler yayınlamak için bir yaklaşım olan site güvenilirlik mühendisliğini (SRE) geliştirdi . SRE, DevOps'un geliştirilmesinden önce gelse de, genellikle birbirleriyle ilişkili olarak görülürler.

DevSecOps, Güvenliği Sola Kaydırma

DevSecOps, güvenlik uygulamalarının DevOps yaklaşımına entegre edilmesini sağlamak için DevOps'un bir uzantısıdır. Geleneksel merkezi güvenlik ekibi modeli, her teslimat ekibinin DevOps uygulamalarına doğru güvenlik kontrollerini dahil etmesine olanak tanıyan birleşik bir model benimsemelidir. Güvenliği sola kaydırmak, güvenlik uygulamalarının ve testlerinin geliştirme yaşam döngüsünün başlarında gerçekleştirildiği bir yazılım güvenliği yaklaşımıdır.

BizOps

BizOps, daha entegre yaklaşımı nedeniyle DevOps'tan farklıdır. DevOps daha çok BT ve yazılım geliştirmeye odaklanırken, BizOps teknolojiyi günlük kurumsal kararlara ve iş operasyonlarına entegre eder.

kültürel değişim

DevOps girişimleri , geliştirme ve teslim süreçleri sırasında operasyonların , geliştiricilerin ve test uzmanlarının işbirliği yapma şeklini değiştirerek şirketlerde kültürel değişiklikler yaratabilir . Bu grupların uyumlu bir şekilde çalışmasını sağlamak, kurumsal DevOps'un benimsenmesinde kritik bir zorluktur. DevOps, alet zinciriyle ilgili olduğu kadar kültürle de ilgilidir.

DevOps kültürü oluşturma

Örgüt kültürü, BT ve örgütsel performansın güçlü bir tahmincisidir. Bilgi akışı, işbirliği, paylaşılan sorumluluklar, başarısızlıklardan öğrenme ve yeni fikirler gibi kültürel uygulamalar DevOps'un merkezinde yer alır. Ekip oluşturma ve diğer çalışan bağlılığı faaliyetleri, genellikle bir kuruluş içinde bu iletişimi ve kültürel değişimi teşvik eden bir ortam yaratmak için kullanılır. Bir hizmet yaklaşımı olarak DevOps, geliştiricilerin ve operasyon ekiplerinin uygulamaları ve altyapılarını hız kesmeden daha fazla kontrol etmelerini sağlar. Ayrıca, bir soruna sahip olma yükünü geliştirme ekibine devrederek, onların adımlarında çok daha dikkatli olmalarını sağlar.

2015 DevOps Durumu Raporu, kuruluş kültürüyle en güçlü korelasyona sahip ilk yedi ölçümün şunlar olduğunu keşfetti:

  1. Kurumsal yatırım
  2. Takım liderlerinin deneyimi ve etkinliği
  3. Sürekli teslimat
  4. Farklı disiplinlerin (geliştirme, operasyonlar ve bilgi güvenliği) kazan-kazan sonuçları elde etme yeteneği
  5. Organizasyonel performans
  6. Dağıtım ağrısı
  7. Yalın yönetim uygulamaları

dağıtım

Çok sık yayın yapan şirketler DevOps hakkında bilgi gerektirebilir. Örneğin, resim barındırma web sitesi Flickr'ı işleten şirket, günde on dağıtımı desteklemek için bir DevOps yaklaşımı geliştirdi. Çok odaklı veya çok işlevli uygulamalar üreten kuruluşlarda günlük dağıtım döngüleri çok daha yüksek olacaktır. Günlük dağıtım, sürekli dağıtım olarak adlandırılır

Mimari açıdan önemli gereksinimler

DevOps'u etkin bir şekilde uygulamak için yazılım uygulamalarının, konuşlandırılabilirlik, değiştirilebilirlik, test edilebilirlik ve izleme yeteneği gibi bir dizi mimari açıdan önemli gereksinimi (ASR'ler) karşılaması gerekir .

mikro hizmetler

Prensipte DevOps'u herhangi bir mimari stille uygulamak mümkün olsa da, mikro hizmetler mimari stili, sürekli olarak dağıtılan sistemler oluşturmak için standart haline geliyor. Küçük boyutlu hizmet, bireysel bir hizmetin mimarisinin sürekli yeniden düzenleme yoluyla ortaya çıkmasına olanak tanır.

DevOps otomasyonu

Ayrıca kuruluş içinde tutarlılığı, güvenilirliği ve verimliliği destekler ve genellikle paylaşılan bir kod deposu veya sürüm kontrolü tarafından etkinleştirilir. DevOps araştırmacısı Ravi Teja Yarlagadda'nın varsaydığı gibi, "DevOps aracılığıyla, tüm işlevlerin basit bir kod kullanılarak merkezi bir yerde yürütülebileceği, kontrol edilebileceği ve yönetilebileceği varsayımı vardır."

Versiyon kontrolü ile otomasyon

Birçok kuruluş , sanal makineler , kapsayıcılaştırma (veya işletim sistemi düzeyinde sanallaştırma ) ve CI/CD gibi DevOps otomasyon teknolojilerini güçlendirmek için sürüm kontrolünü kullanır . DevOps: bankacılık alanında bir araç zincirinin geliştirilmesi başlıklı makale, aynı proje üzerinde çalışan geliştirici ekipleriyle, "Tüm geliştiricilerin aynı kod tabanında değişiklik yapması ve hatta bazen aynı dosyaları bile düzenlemesi gerekir. Verimli çalışma için, Örnek olarak başvurulan Git sürüm kontrol sistemi ve GitHub platformu ile mühendislerin çakışmalardan kaçınmasına ve kod tabanı geçmişini korumasına yardımcı olan bir sistem olun.

Benimseme

DevOps uygulamaları ve benimseme

DevOps uygulamaları ve bağımlılıkları, potansiyel faydaları düzenli bir uygulama zincirine bağlayan bir bağımlılık ağı içerir. Bu ağı kullanarak kuruluşlar, hedeflerine ulaşmalarını sağlayan bir yol seçebilirler.

DevOps'un benimsenmesi, aşağıdakiler de dahil olmak üzere birçok faktör tarafından yönlendiriliyor:

  1. Çevik ve diğer geliştirme süreç ve yöntemlerinin kullanımı;
  2. Uygulama ve iş birimi paydaşlarından üretim sürümlerinde artış oranı talebi ;
  3. Dahili ve harici sağlayıcılardan sanallaştırılmış ve bulut altyapısının geniş kullanılabilirliği ;
  4. Veri merkezi otomasyonu ve konfigürasyon yönetimi araçlarının artan kullanımı ;
  5. Test otomasyonu ve sürekli entegrasyon yöntemlerine daha fazla odaklanma ;
  6. Kamuya açık en iyi uygulamalardan oluşan kritik bir kitle.

Ayrıca bakınız

Notlar

Referanslar

daha fazla okuma

  • Davis, Jennifer; Daniels, Ryn (30 Mayıs 2016). Etkili DevOps : geniş ölçekte bir işbirliği, yakınlık ve araçlar kültürü oluşturma . Sivastopol, CA: O'Reilly. ISBN'si 9781491926437. OCLC  951434424 .
  • Kim, Gene; Debois, Patrick; Willis, John; Mütevazı, Jez; Allspaw, John (7 Ekim 2015). DevOps el kitabı : teknoloji organizasyonlarında birinci sınıf çeviklik, güvenilirlik ve güvenlik nasıl oluşturulur (İlk baskı). Portland, VEYA. ISBN'si 9781942788003. OCLC  907166314 .
  • Forsgren, Nicole; Mütevazı, Jez; Kim, Gene (27 Mart 2018). Hızlandırın: Yalın Yazılım ve DevOps Bilimi: Yüksek Performanslı Teknoloji Kuruluşları Oluşturma ve Ölçeklendirme (İlk baskı). BT Devrimi Basın. ISBN'si 9781942788331.