# DevOps
DevOps, yazılım geliştirme ve bilgi teknolojileri endüstrisinde bir metodolojidir. Bir dizi uygulama ve araç olarak kullanılan DevOps, sistem geliştirme yaşam döngüsünü iyileştirmek ve kısaltmak için bir araç olarak DevOps çalışmalarını entegre eder ve otomatikleştirir. DevOps kelimesi yazılım geliştirme "("Dev) ve bilgi teknolojileri operasyonlarının ("Ops") birleşiminden oluşmaktadır. DevOps, çevik yazılım geliştirmeyi tamamlayıcı niteliktedir; "DevOps"'un birçok yönü "çevik" çalışma biçiminden gelmektedir.


## Tanım.
"Geliştirme" ve "operasyon" terimlerinin ve kavramlarının çapraz fonksiyonel bir kombinasyonu (ve bir portmanteau) olması dışında, akademisyenler ve uygulayıcılar "DevOps" terimi için evrensel bir tanım geliştirmemişti.#YÖNLENDİRME #YÖNLENDİRME #YÖNLENDİRME #YÖNLENDİRME DevOps çoğunlukla temel ilkelerle karakterize edilir: paylaşılan sahiplik, iş akışı otomasyonu ve hızlı geri bildirim. 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 akademik bir bakış açısıyla "bir sistemde değişiklik yapılması ile değişikliğin normal üretime geçmesi arasındaki süreyi kısaltmayı ve aynı zamanda yüksek kaliteyi sağlamayı amaçlayan bir dizi uygulama" olarak tanımlamayı önerdi. Ancak terim birden fazla bağlamda kullanılmaktadır. En başarılı haliyle DevOps, belirli uygulamalar, kültür değişimi ve araçların bir kombinasyonudur.


## Tarih.
Yazılım geliştirme metodolojilerini dağıtım ve operasyon kavramlarıyla birleştirme önerileri 80'lerin sonunda ve 90'ların başında ortaya çıkmaya başladı.
2007 ve 2008 yıllarında, yazılım geliştirme ve BT toplulukları içinde yer alan kişiler tarafından, yazılımı yazan ve yaratan ile yazılımı dağıtan ve destekleyenlerin birbirinden tamamen ayrı olduğu iki sektör arasındaki ayrımın sektörde ölümcül düzeyde bir işlev bozukluğu yarattığına dair endişeler dile getirildi.
2009 yılında DevOps Days adlı ilk konferans Belçika'nın Gent kentinde düzenlendi.Konferans Belçikalı danışman, proje yöneticisi ve atik uygulayıcı Patrick Debois tarafından kurulmuştur. Konferans artık diğer ülkelere de yayılmıştır.
İlk olarak 2012 yılında Puppet Labs'ten Alanna Brown tarafından "DevOps'un Durumu" adlı bir rapor yayınlandı.
2014 yılı itibarıyla, Nicole Forsgren, Gene Kim, Jez Humble ve diğerleri tarafından yıllık State of DevOps raporu yayınlanmıştır. DevOps'un benimsenmesinin hızlandığını belirttiler. Ayrıca 2014 yılında Lisa Crispin ve Janet Gregory, test ve DevOps hakkında bir bölüm içeren More Agile Testing kitabını yazdılar.
2016 yılında, verim (dağıtım sıklığı, değişiklikler için teslim süresi) ve istikrar (ortalama iyileşme süresi, değişiklik başarısızlık oranı) için DORA metrikleri DevOps'un Durumu raporunda yayınlandı. Ancak, araştırma metodolojisi ve metrikler uzmanlar tarafından eleştirildi.


## Diğer yaklaşımlarla ilişki.
DevOps uygulamalarının temelini oluşturan fikirlerin çoğu, Yalın ve Deming'in Planla-Uygula-Kontrol Et-Önlem Al döngüsünden Toyota Yöntemi'ne ve bileşenleri ve parti boyutlarını parçalara ayıran Çevik yaklaşıma kadar iyi bilinen diğer uygulamalardan esinlenmiştir veya bunları yansıtmaktadır. 1990'larda ITIL'in"yukarıdan aşağıya" kuralcı yaklaşımının ve katı çerçevesinin aksine, DevOps "aşağıdan yukarıya" ve esnektir, yazılım mühendisleri tarafından kendi ihtiyaçları için yaratılmıştır.


### Atik (Agile).
Modern DevOps ve otomatik derleme ve test, sürekli entegrasyon ve sürekli teslimat gibi çeşitli standart DevOps uygulamalarının motivasyonu, (gayri resmi olarak) 1990'lara ve resmi olarak 2001'e dayanan Atik dünyadan kaynaklanmıştır. Ekstrem programlama gibi yöntemler kullanan atik geliştirme ekipleri, uygulamaları için operasyon ve altyapı sorumluluğunu üstlenmedikleri ve bu işin çoğunu otomatikleştirmedikleri sürece "değerli yazılımların erken ve sürekli teslimi yoluyla müşteriyi memnun edemezlerdi". Scrum 2000'lerin başında baskın Atik çerçeve olarak ortaya çıktığından ve birçok Atik ekibin parçası olan mühendislik uygulamalarını ihmal ettiğinden, operasyonları ve altyapı işlevlerini otomatikleştirme hareketi Atik'ten ayrılarak modern DevOps'a dönüştü. Günümüzde DevOps, ister Atik odaklı metodolojiler ister diğer metodolojiler kullanılarak 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 eserlerinden 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.


### Mobile DevOps.
Mobil DevOps, DevOps ilkelerini özellikle mobil uygulamaların geliştirilmesine uygulayan bir dizi uygulamadır. Geleneksel DevOps genel olarak yazılım geliştirme sürecini kolaylaştırmaya odaklanır, ancak mobil geliştirmenin özel bir yaklaşım gerektiren kendine özgü zorlukları vardır. Mobil DevOps, DevOps'un sadece mobil uygulama geliştirmeye özgü bir dalı değil, DevOps felsefesinin bir uzantısı ve yeniden yorumlanmasıdır.


### Sürekli Entegrasyon ve Teslimat (CI/CD).
Otomasyon, DevOps'un başarıya ulaşması için temel bir ilkedir ve CI/CD kritik bir bileşendir. Ayrıca, ekipler arasında ve içinde gelişmiş işbirliği ve iletişim, riskleri azaltarak pazara sunma süresine ulaşmaya yardımcı olur.


### Site güvenilirliği mühendisliği (SRE).
2003 yılında Google, yüksek kaliteli son kullanıcı deneyimini korurken yeni özellikleri sürekli olarak büyük ölçekli yüksek kullanılabilirlikli sistemlerde yayınlamaya yönelik bir yaklaşım olan site güvenilirliği mühendisliğini (SRE) geliştirdi. SRE, DevOps'un geliştirilmesinden önce ortaya çıkmış olsa da, genellikle birbirleriyle ilişkili olarak görülürler


### Toyota üretim sistemi, yalın düşünce, kaizen.
Toyota üretim sistemi (TPS), sürekli iyileştirme, kaizen, akış ve küçük partilere odaklanmasıyla yalın düşünceye ilham kaynağı olmuştur. Andon kordonunun hızlı geri bildirim oluşturma, sürü oluşturma ve sorunları çözme ilkesi TPS'den kaynaklanmaktadır.


### DevSecOps.
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 modelinin aksine, her teslimat ekibine yazılım teslimatlarına doğru güvenlik kontrollerini dahil etme yetkisi verilir. Güvenlik uygulamaları ve testleri geliştirme yaşam döngüsünün başlarında gerçekleştirilir, bu nedenle "sola kaydırma" terimi kullanılır. Güvenlik üç ana alanda test edilir: statik, yazılım bileşimi ve dinamik.
Statik uygulama güvenlik testi (SAST) aracılığıyla yazılımı statik olarak kontrol etmek, özellikle güvenliğe odaklanan beyaz kutu testidir.Programlama diline bağlı olarak, bu tür statik kod analizi yapmak için farklı araçlara ihtiyaç vardır.Yazılım bileşimi, özellikle kütüphaneler analiz edilir ve her bileşenin sürümü CERT ve diğer uzman gruplar tarafından yayınlanan güvenlik açığı listelerine göre kontrol edilir.İstemcilere yazılım verilirken, özellikle copyleft lisansları olmak üzere, kütüphane lisansları ve bunların dağıtılan yazılımın lisansıyla eşleşmesine odaklanılır.
Kara kutu testi olarak da adlandırılan dinamik testlerde yazılım, iç işlevleri bilinmeden test edilir. DevSecOps'ta bu uygulama dinamik uygulama güvenlik testi (DAST) veya sızma testi olarak adlandırılabilir. Amaç, siteler arası komut dosyası oluşturma ve SQL enjeksyion açıkları dahil olmak üzere kusurların erken tespit edilmesidir. Tehdit türleri, açık web uygulaması güvenlik projesi, örneğin TOP10 ve diğer kuruluşlar tarafından yayınlanmaktadır.
DevSecOps, güvenlik eğitimi, tasarım yoluyla güvenlik ve güvenlik otomasyonunu entegre ederek güvenli yazılım üretmeye yönelik bütünsel bir yaklaşımı içeren kültürel bir değişim olarak da tanımlanmaktadır.


## Kültürel değişim.
DevOps girişimleri, geliştirme ve teslimat süreçlerinde operasyonların, geliştiricilerin ve test uzmanlarının işbirliği yapma şeklini dönüştürerek ş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, araç zinciriyle ilgili olduğu kadar kültürle de ilgilidir.


### Mikro servisler.
Prensipte DevOps'u herhangi bir mimari tarzla uygulamak mümkün olsa da, mikroservis mimari tarzı sürekli olarak konuşlandırılan sistemler oluşturmak için standart haline gelmektedir. Küçük boyutlu hizmet, tek bir hizmetin mimarisinin sürekli yeniden düzenleme yoluyla ortaya çıkmasını sağlar.


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


### Sürüm kontrolü ile otomasyon.
Birçok kuruluş sanal makineler, konteynerizasyon (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ı makalede, aynı proje üzerinde çalışan geliştirici ekiplerinde "Tüm geliştiricilerin aynı kod tabanında değişiklik yapması ve hatta bazen aynı dosyaları düzenlemesi gerekir. Verimli bir çalışma için, mühendislerin çatışmalardan kaçınmasına ve kod tabanı geçmişini korumasına yardımcı olan bir sistem olmalıdır" denilmekte ve Git sürüm kontrol sistemi ile GitHub platformu örnek olarak gösterilmektedir.


## GitOps.
GitOps, DevOps'tan evrimleşmiştir. Dağıtım yapılandırmasının özel durumu sürüm kontrollüdür. En popüler sürüm kontrolü Git olduğu için GitOps'un yaklaşımı Git'in adını almıştır. Yapılandırmadaki değişiklikler kod inceleme uygulamaları kullanılarak yönetilebilir ve sürüm kontrolü kullanılarak geri alınabilir. Esasen, bir koddaki tüm değişiklikler izlenir, yer imlerine eklenir ve geçmişte herhangi bir güncelleme yapmak daha kolay hale getirilebilir. Red Hat tarafından açıklandığı gibi, ""değişimin görünürlüğü, sorunları hızlı bir şekilde izleme ve yeniden üretme yeteneği anlamına gelir ve genel güvenliği artırır."