DevOps

Vikipedi, özgür ansiklopedi
DevOps şeması.

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.[1] 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[değiştir | kaynağı değiştir]

"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. 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.[2] 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. [3]

Tarih[değiştir | kaynağı değiştir]

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ı. [4]

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. [5]

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 çevik uygulayıcı Patrick Debois tarafından kurulmuştur.[6][7]Konferans artık diğer ülkelere de yayılmıştır.[8]

İlk olarak 2012 yılında Puppet Labs'ten Alanna Brown tarafından "DevOps'un Durumu" adlı bir rapor yayınlandı. [9] [10]

2014 yılı itibariyle, 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.[11][12]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. [13] [14]

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ı.[15]Ancak, araştırma metodolojisi ve metrikler uzmanlar tarafından eleştirildi. [16] [17] [18] [19]

Diğer yaklaşımlarla ilişki[değiştir | kaynağı değiştir]

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.[20] 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.[21]

Çevik (Agile)[değiştir | kaynağı değiştir]

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 Çevik dünyadan kaynaklanmıştır. Ekstrem programlama gibi yöntemler kullanan çevik 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".[22] Scrum 2000'lerin başında baskın Çevik çerçeve olarak ortaya çıktığından ve birçok Çevik ekibin parçası olan mühendislik uygulamalarını ihmal ettiğinden, operasyonları ve altyapı işlevlerini otomatikleştirme hareketi Çevik'ten ayrılarak modern DevOps'a dönüştü. Günümüzde DevOps, ister Çevik odaklı metodolojiler ister diğer metodolojiler kullanılarak geliştirilmiş olsun, geliştirilen yazılımın dağıtımına odaklanmaktadır.

ArchOps[değiştir | kaynağı değiştir]

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

Mobile DevOps[değiştir | kaynağı değiştir]

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.[24] 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)[değiştir | kaynağı değiştir]

Otomasyon, DevOps'un başarıya ulaşması için temel bir ilkedir ve CI/CD kritik bir bileşendir.[25] 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.[26]

Site güvenilirliği mühendisliği (SRE)[değiştir | kaynağı değiştir]

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. [27] 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[değiştir | kaynağı değiştir]

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.[28] [29]

DevSecOps[değiştir | kaynağı değiştir]

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[30] 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.[31]

Kültürel değişim[değiştir | kaynağı değiştir]

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[32].[33] Bu grupların uyumlu bir şekilde çalışmasını sağlamak, kurumsal DevOps'un benimsenmesinde kritik bir zorluktur.[34] [35] DevOps, araç zinciriyle ilgili olduğu kadar kültürle de ilgilidir.[36]

Mikro servisler[değiştir | kaynağı değiştir]

Prensipte DevOps'u herhangi bir mimari tarzla uygulamak mümkün olsa da, mikro servis 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.[37]

DevOps otomasyonu[değiştir | kaynağı değiştir]

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."[38]

Sürüm kontrolü ile otomasyon[değiştir | kaynağı değiştir]

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"[39] denilmekte ve Git sürüm kontrol sistemi ile GitHub platformu örnek olarak gösterilmektedir.

GitOps[değiştir | kaynağı değiştir]

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.[40]

Daha fazla okuma[değiştir | kaynağı değiştir]

  • Davis, Jennifer; Daniels, Ryn (2016-05-30). Effective DevOps : building a culture of collaboration, affinity, and tooling at scale. Sebastopol, CA: O'Reilly. ISBN 9781491926437. OCLC 951434424. 
  • Kim, Gene; Debois, Patrick; Willis, John; Humble, Jez; Allspaw, John (2015-10-07). The DevOps handbook : how to create world-class agility, reliability, and security in technology organizations. First. Portland, OR. ISBN 9781942788003. OCLC 907166314. 
  • Forsgren, Nicole; Humble, Jez; Kim, Gene (27 March 2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. First. IT Revolution Press. ISBN 9781942788331. 

Kaynakça[değiştir | kaynağı değiştir]

  1. ^ Courtemanche, Meredith; Mell, Emily; Gills, Alexander S. "What Is DevOps? The Ultimate Guide". TechTarget (İngilizce). Erişim tarihi: 2023-01-22. 
  2. ^ Bass, Len (2015). DevOps: A Software Architect's Perspective. ISBN 978-0134049847. 
  3. ^ Muñoz, Mirna; Rodríguez, Mario Negrete (2021-04-01). "A guidance to implement or reinforce a DevOps approach in organizations: A case study". Journal of Software: Evolution and Process. 36 (3). doi:10.1002/smr.2342. ISSN 2047-7473. 
  4. ^ Chapman, M., Gatti, N: A model of a service life cycle, Proceedings of TINA '93, pp. I-205–I-215, Sep., 1993.
  5. ^ Atlassian. "History of DevOps". Atlassian (İngilizce). Erişim tarihi: 2023-02-23. 
  6. ^ Mezak, Steve (25 January 2018). "The Origins of DevOps: What's in a Name?". devops.com. Erişim tarihi: 6 May 2019. 
  7. ^ Debois, Patrick (9 October 2008). "Agile 2008 Toronto". Just Enough Documented Information. Erişim tarihi: 12 March 2015. 
  8. ^ Debois, Patrick. "DevOps Days". DevOps Days. Erişim tarihi: 31 March 2011. 
  9. ^ Alana Brown; Nicole Forsgren; Jez Humble; Nigel Kersten; Gene Kim (2016). "2016 State of DevOps Report" (PDF). Puppet Labs, DORA (DevOps Research. Erişim tarihi: 2019-05-06. 
  10. ^ "Puppet - Alanna Brown". Puppet Labs. Erişim tarihi: 2019-04-27. 
  11. ^ Nicole Forsgren; Gene Kim; Nigel Kersten; Jez Humble (2014). "2014 State of DevOps Report" (PDF). Puppet Labs, IT Revolution Press and ThoughtWorks. Erişim tarihi: 2019-04-27. 
  12. ^ "2015 State of DevOps Report" (PDF). Puppet Labs, Pwc, IT Revolution Press. 2015. 2019-05-06 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 2019-05-06. 
  13. ^ "More Agile Testing" (PDF). October 2014. Erişim tarihi: 2019-05-06. 
  14. ^ Crispin, Lisa; Gregory, Janet (October 2014). More Agile Testing. Addison-Wesley. ISBN 9780133749571. Erişim tarihi: 2019-05-06. 
  15. ^ Alana Brown; Nicole Forsgren; Jez Humble; Nigel Kersten; Gene Kim (2016). "2016 State of DevOps Report" (PDF). Puppet Labs, DORA (DevOps Research. Erişim tarihi: 2019-05-06. 
  16. ^ Turner, Graham (20 November 2023). "Report: Software Engineers Face Backlash for Reporting Wrongdoing". DIGIT (İngilizce). Erişim tarihi: 5 January 2024. 
  17. ^ Saran, Cliff. "Software engineers worry about speaking out - Computer Weekly". ComputerWeekly.com (İngilizce). Erişim tarihi: 5 January 2024. 
  18. ^ "75% of software engineers faced retaliation the last time they reported wrongdoing - ETHRWorldSEA". ETHRWorld.com (İngilizce). 
  19. ^ Cummins, Holly. "Holly Cummins on X". X.com. Erişim tarihi: 5 January 2024. 
  20. ^ Klein, Brandon Thorin (2021-05-01). "The DevOps: A Concise Understanding to the DevOps Philosophy and Science". Osti.gov (English). doi:10.2172/1785164. 
  21. ^ "The History and Evolution of DevOps | Tom Geraghty" (İngilizce). 5 July 2020. Erişim tarihi: 2020-11-29. 
  22. ^ "Principles behind the Agile Manifesto". agilemanifesto.org. Erişim tarihi: 2020-12-06. 
  23. ^ Castellanos, Camilo; Correal, Dario (15 September 2018). "Executing Architectural Models for Big Data Analytics". Software Architecture. Lecture Notes in Computer Science. 11048. ss. 364–371. doi:10.1007/978-3-030-00761-4_24. ISBN 978-3-030-00760-7. 
  24. ^ Tak, Rohin; Modi, Jhalak (2018). Mobile DevOps: Deliver continuous integration and deployment within your mobile applications. Packt Publishing. ss. 12-18. ISBN 9781788296243. 
  25. ^ Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. ISBN 978-0-321-60191-9. 
  26. ^ Chen, Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software. 32 (2): 50–54. doi:10.1109/MS.2015.27. 
  27. ^ Beyer, Betsy; Jones, Chris; Petoff, Jennifer; Murphy, Niall Richard (April 2016). Site Reliability Engineering. O'Reilly Media. ISBN 978-1-4919-2909-4. 
  28. ^ Analyzing the DNA of DevOps, Brent Aaron Reed, Willy Schaub, 2018-11-14.
  29. ^ Gene Kim; Patrick Debois; John Willis; Jezz Humble (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. 
  30. ^ "OWASP TOP10". June 8, 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: June 8, 2023. 
  31. ^ Wilson, Glenn (December 2020). 'DevSecOps: A leader's guide to producing secure software with compromising flow, feedback and continuous improvement'. Rethink Press. ISBN 978-1781335024. 
  32. ^ Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology. Gartner. 
  33. ^ Loukides, Mike (7 June 2012). "What is DevOps?". O'Reilly Media. 
  34. ^ "Gartner IT Glossary  – devops". Gartner. Erişim tarihi: 30 October 2015. 
  35. ^ Jones, Stephen; Noppen, Joost; Lettice, Fiona (21 July 2016). Proceedings of the 2nd International Workshop on Quality-Aware DevOps - QUDOS 2016 (PDF). ss. 7–11. doi:10.1145/2945408.2945410. ISBN 9781450344111. 
  36. ^ Mandi Walls (25 September 2015). "Building a DevOps culture". O'Reilly. 
  37. ^ Chen, Lianping; Ali Babar, Muhammad (2014). "2014 IEEE/IFIP Conference on Software Architecture". The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014). IEEE. ss. 195–204. doi:10.1109/WICSA.2014.45. ISBN 978-1-4799-3412-6. 
  38. ^ https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3798877
  39. ^ DevOps: development of a toolchain in the banking domain. Politecnico di Torino (laurea tez). 16 April 2021. Erişim tarihi: 16 August 2021. 
  40. ^ "What is GitOps?". www.redhat.com (İngilizce). Erişim tarihi: 2023-03-30. 

Ayrıca bakınız[değiştir | kaynağı değiştir]

"https://tr.wikipedia.org/w/index.php?title=DevOps&oldid=32563816" sayfasından alınmıştır