DevOps: Revizyonlar arasındaki fark

Vikipedi, özgür ansiklopedi
[kontrol edilmiş revizyon][kontrol edilmiş revizyon]
İçerik silindi İçerik eklendi
Ahmet DEMİREN (mesaj | katkılar)
Tashis yapıldı
Berkayinam (mesaj | katkılar)
İngilizce DevOps sayfasını Türkçeye çevrildi. Kaynakça eklemesi ve madde genişletmesi yapıldı.
1. satır: 1. satır:
[[Dosya:Industrial DevOps Knoten.png|küçükresim|DevOps şeması.]]
[[Dosya:Industrial DevOps Knoten.png|küçükresim|DevOps şeması.]]
'''DevOps''', [[yazılım geliştirme]] ve [[bilgi teknolojileri]] endüstrisinde bir [[Metodoloji|metodolojidir]]. Bir dizi uygulama ve araç olarak kullanılan DevOps, [[:en:Systems_development_life_cycle|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.<ref>{{Cite web|url=https://www.techtarget.com/searchitoperations/definition/DevOps|title=What Is DevOps? The Ultimate Guide|access-date=2023-01-22|language=en|website=TechTarget|first=Meredith|last=Courtemanche|first2=Emily|first3=Alexander S.|last2=Mell|last3=Gills}}</ref> DevOps kelimesi yazılım geliştirme ''(''Dev) ve bilgi teknolojileri operasyonlarının (''Ops'') birleşiminden oluşmaktadır. DevOps, [[Atik yazılım geliştirme|çevik yazılım geliştirmeyi]] tamamlayıcı niteliktedir; ''DevOps''<nowiki/>'un birçok yönü ''çevik'' çalışma biçiminden gelmektedir.
'''DevOps''', [[yazılım geliştirme]] ve [[bilgi teknolojisi]] endüstrisinde bir metodolojidir.<ref>{{Web kaynağı|url=https://about.gitlab.com/topics/devops|başlık=What is DevOps?|erişimtarihi=27 Kasım 2023|dil=en-us|çalışma=about.gitlab.com|arşivurl=https://web.archive.org/web/20231129123505/https://about.gitlab.com/topics/devops/|arşivtarihi=29 Kasım 2023|ölüurl=hayır}}</ref> [[Sistem geliştirme yaşam döngüsü]]'nü iyileştirmek ve kısaltmak için bir araç olarak kullanılır. DevOps, yazılım geliştirme (Dev) ve BT operasyonları (Ops) çalışmalarını entegre eder ve otomatikleştirir.<ref>{{Web kaynağı | url = https://www.knowledgehut.com/blog/devops/top-devops-tools | başlık = 35 Best DevOps Tools and Technologies in 2023 | erişimtarihi = 27 Kasım 2023 | çalışma = www.knowledgehut.com | arşivurl = https://web.archive.org/web/20201122123950/https://www.knowledgehut.com/blog/devops/top-devops-tools | arşivtarihi = 22 Kasım 2020}}</ref><ref>{{Web kaynağı | url = https://www.simplilearn.com/tutorials/devops-tutorial/devops-tools | başlık = 30 Best DevOps Tools for 2023: Git, Docker, Jenkins and More {{!}} Simplilearn | erişimtarihi = 27 Kasım 2023 | dil = en-US | çalışma = Simplilearn.com | arşivurl = https://web.archive.org/web/20200524080908/https://www.simplilearn.com/tutorials/devops-tutorial/devops-tools | arşivtarihi = 24 Mayıs 2020}}</ref>

== 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. 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.<ref>{{Kitap kaynağı|başlık=DevOps: A Software Architect's Perspective|yıl=2015|soyadı=Bass, Len|isbn=978-0134049847}}</ref> 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. <ref>{{Akademik dergi kaynağı|url=http://dx.doi.org/10.1002/smr.2342|başlık=A guidance to implement or reinforce a DevOps approach in organizations: A case study|tarih=2021-04-01|sayı=3|çalışma=Journal of Software: Evolution and Process|cilt=36|ad=Mirna|soyadı=Muñoz|issn=2047-7473|doi=10.1002/smr.2342|ad2=Mario Negrete|soyadı2=Rodríguez}}</ref>

== Tarih ==
<span class="cx-segment" data-segmentid="23">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ı. <ref>Chapman, M., Gatti, N: A model of a service life cycle, Proceedings of TINA '93, pp. I-205–I-215, Sep., 1993.</ref></span>

<span class="cx-segment" data-segmentid="24">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. <ref>{{Web kaynağı|url=https://www.atlassian.com/devops/what-is-devops/history-of-devops|başlık=History of DevOps|erişimtarihi=2023-02-23|dil=en|çalışma=Atlassian|soyadı=Atlassian}}</ref></span>

2009 yılında DevOps Days adlı ilk konferans [[Belçika|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.<ref>{{Cite web|url=https://devops.com/the-origins-of-devops-whats-in-a-name/|title=The Origins of DevOps: What's in a Name?|access-date=6 May 2019|date=25 January 2018|publisher=devops.com|first=Steve|last=Mezak}}</ref><ref>{{Cite web|url=http://www.jedi.be/blog/2008/10/09/agile-2008-toronto-agile-infrastructure-and-operations-presentation/|title=Agile 2008 Toronto|access-date=12 March 2015|date=9 October 2008|publisher=Just Enough Documented Information|first=Patrick|last=Debois}}</ref>Konferans artık diğer ülkelere de yayılmıştır.<ref>{{Cite web|url=http://www.devopsdays.org/|title=DevOps Days|access-date=31 March 2011|publisher=DevOps Days|first=Patrick|last=Debois}}</ref>

<span class="cx-segment" data-segmentid="30">İlk olarak 2012 yılında [[Puppet Labs|Puppet Labs'ten]] Alanna Brown tarafından "DevOps'un Durumu" adlı bir rapor yayınlandı. <ref name="2016 State of DevOps Report2">{{Web kaynağı|url=https://devops-research.com/assets/state-of-devops-2016.pdf|başlık=2016 State of DevOps Report|erişimtarihi=2019-05-06|tarih=2016|yayıncı=Puppet Labs, DORA (DevOps Research|soyadı=Alana Brown|soyadı2=Nicole Forsgren|soyadı3=Jez Humble|soyadı4=Nigel Kersten|soyadı5=Gene Kim}}</ref> <ref>{{Web kaynağı|url=https://puppet.com/people/alanna-brown|başlık=Puppet - Alanna Brown|erişimtarihi=2019-04-27|yayıncı=Puppet Labs}}</ref></span>

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.<ref>{{Cite web|url=https://devops-research.com/assets/state-of-devops-2014.pdf|title=2014 State of DevOps Report|access-date=2019-04-27|date=2014|publisher=Puppet Labs, IT Revolution Press and ThoughtWorks|last=Nicole Forsgren|last2=Gene Kim|last3=Nigel Kersten|last4=Jez Humble}}</ref><ref>{{Cite web|url=https://devops-research.com/assets/state-of-devops-2015.pdf|title=2015 State of DevOps Report|access-date=2019-05-06|archive-date=2019-05-06|archive-url=https://web.archive.org/web/20190506165632/https://devops-research.com/assets/state-of-devops-2015.pdf|date=2015|publisher=Puppet Labs, Pwc, IT Revolution Press|url-status=dead}}</ref>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. <ref>{{Web kaynağı|url=https://agiletester.ca/wp-content/uploads/sites/26/2014/09/TOC.pdf|başlık=More Agile Testing|erişimtarihi=2019-05-06|tarih=October 2014}}</ref> <ref>{{Kitap kaynağı|url=https://www.oreilly.com/library/view/more-agile-testing/9780133749571/|başlık=More Agile Testing|erişimtarihi=2019-05-06|tarih=October 2014|yayıncı=Addison-Wesley|ad=Lisa|soyadı=Crispin|isbn=9780133749571|ad2=Janet|soyadı2=Gregory}}</ref>

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ı.<ref name="2016 State of DevOps Report3">{{Web kaynağı|url=https://devops-research.com/assets/state-of-devops-2016.pdf|başlık=2016 State of DevOps Report|erişimtarihi=2019-05-06|tarih=2016|yayıncı=Puppet Labs, DORA (DevOps Research|soyadı=Alana Brown|soyadı2=Nicole Forsgren|soyadı3=Jez Humble|soyadı4=Nigel Kersten|soyadı5=Gene Kim}}</ref>Ancak, araştırma metodolojisi ve metrikler uzmanlar tarafından eleştirildi. <ref>{{Haber kaynağı|url=https://www.digit.fyi/report-software-engineers-facing-retaliation-for-reporting-wrongdoing/|başlık=Report: Software Engineers Face Backlash for Reporting Wrongdoing|erişimtarihi=5 January 2024|tarih=20 November 2023|dil=en|çalışma=DIGIT|ad=Graham|soyadı=Turner}}</ref> <ref>{{Haber kaynağı|url=https://www.computerweekly.com/news/366560292/Software-engineers-worry-about-speaking-out|başlık=Software engineers worry about speaking out - Computer Weekly|erişimtarihi=5 January 2024|dil=en|çalışma=ComputerWeekly.com|ad=Cliff|soyadı=Saran}}</ref> <ref>{{Haber kaynağı|url=https://hrsea.economictimes.indiatimes.com/news/workplace/75-of-software-engineers-faced-retaliation-the-last-time-they-reported-wrongdoing/105335733|başlık=75% of software engineers faced retaliation the last time they reported wrongdoing - ETHRWorldSEA|dil=en|çalışma=ETHRWorld.com}}</ref> <ref>{{Web kaynağı|url=https://twitter.com/holly_cummins/status/1448357917384744964|başlık=Holly Cummins on X|erişimtarihi=5 January 2024|çalışma=X.com|ad=Holly|soyadı=Cummins}}</ref>

== <span class="cx-segment" data-segmentid="38">Diğer yaklaşımlarla ilişki</span> ==
DevOps uygulamalarının temelini oluşturan fikirlerin çoğu, [[Yalın üretim|Yalın]] ve [[William Edwards Deming|Deming'in]] [[PUKÖ|Planla-Uygula-Kontrol Et-Önlem Al]] döngüsünden [[Toyota Tarzı|Toyota Yöntemi]]'ne ve bileşenleri ve parti boyutlarını parçalara ayıran [[Atik yazılım geliştirme|Çevik]] yaklaşıma kadar iyi bilinen diğer uygulamalardan esinlenmiştir veya bunları yansıtmaktadır.<ref>{{Akademik dergi kaynağı|url=https://www.osti.gov/biblio/1785164/|başlık=The DevOps: A Concise Understanding to the DevOps Philosophy and Science|tarih=2021-05-01|dil=English|çalışma=Osti.gov|ad=Brandon Thorin|soyadı=Klein|doi=10.2172/1785164}}</ref> 1990'larda [[Bilgi Teknolojisi Altyapı Kütüphanesi|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.<ref>{{Web kaynağı|url=https://tomgeraghty.co.uk/index.php/the-history-and-evolution-of-devops/|başlık=The History and Evolution of DevOps {{!}} Tom Geraghty|erişimtarihi=2020-11-29|tarih=5 July 2020|dil=en-GB}}</ref>

== Çevik (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 Ç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<sup>"</sup>.<ref>{{Web kaynağı|url=https://agilemanifesto.org/principles.html|başlık=Principles behind the Agile Manifesto|erişimtarihi=2020-12-06|çalışma=agilemanifesto.org}}</ref> [[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 ==
ArchOps, operasyon dağıtımı için kaynak kodu yerine [[yazılım mimarisi]] eserlerinden başlayarak DevOps uygulaması için bir uzantı sunar.<ref>{{Kitap kaynağı|başlık=Software Architecture|kısım=Executing Architectural Models for Big Data Analytics|tarih=15 September 2018|sayfalar=364–371|seri=Lecture Notes in Computer Science|cilt=11048|ad=Camilo|soyadı=Castellanos|isbn=978-3-030-00760-7|ad2=Dario|soyadı2=Correal|doi=10.1007/978-3-030-00761-4_24}}</ref> 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üreci|yazılım geliştirme sürecini]] kolaylaştırmaya odaklanır, ancak [[Mobil uygulama geliştirme|mobil geliştirmenin]] özel bir yaklaşım gerektiren kendine özgü zorlukları vardır.<ref>{{Kitap kaynağı|başlık=Mobile DevOps: Deliver continuous integration and deployment within your mobile applications|tarih=2018|sayfalar=12-18|yayıncı=Packt Publishing|ad=Rohin|soyadı=Tak|isbn=9781788296243|ad2=Jhalak|soyadı2=Modi}}</ref> Mobil DevOps, DevOps'un sadece mobil uygulama geliştirmeye özgü bir dalı değil, DevOps felsefesinin bir uzantısı ve yeniden yorumlanmasıdır.

== <span class="cx-segment" data-segmentid="60">Sürekli Entegrasyon ve Teslimat (CI/CD)</span> ==
Otomasyon, DevOps'un başarıya ulaşması için temel bir ilkedir ve CI/CD kritik bir bileşendir.<ref>{{Kitap kaynağı|başlık=Continuous Delivery: reliable software releases through build, test, and deployment automation|tarih=2011|yayıncı=Pearson Education Inc.|ad=Jez|soyadı=Humble|isbn=978-0-321-60191-9|ad2=David|soyadı2=Farley}}</ref> Ayrıca, ekipler arasında ve içinde gelişmiş işbirliği ve iletişim, riskleri azaltarak [[Market zamanı|pazara sunma süresine]] ulaşmaya yardımcı olur.<ref>{{Akademik dergi kaynağı|başlık=Continuous Delivery: Huge Benefits, but Challenges Too|sayı=2|sayfalar=50–54|çalışma=IEEE Software|yıl=2015|cilt=32|ad=Lianping|soyadı=Chen|doi=10.1109/MS.2015.27}}</ref>

== <span class="cx-segment" data-segmentid="70">Site güvenilirliği mühendisliği (SRE)</span> ==
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ği|site güvenilirliği mühendisliğini]] (SRE) geliştirdi. <ref>{{Kitap kaynağı|başlık=Site Reliability Engineering|tarih=April 2016|yayıncı=O'Reilly Media|ad=Betsy|soyadı=Beyer|isbn=978-1-4919-2909-4|ad2=Chris|ad3=Jennifer|ad4=Niall Richard|soyadı2=Jones|soyadı3=Petoff|soyadı4=Murphy}}</ref> SRE, DevOps'un geliştirilmesinden önce ortaya çıkmış olsa da, genellikle birbirleriyle ilişkili olarak görülürler

== <span class="cx-segment" data-segmentid="75">Toyota üretim sistemi, yalın düşünce, kaizen</span> ==
Toyota üretim sistemi (TPS), [[Sürekli iyileştirme süreci|sürekli iyileştirme]], [[kaizen]], akış ve küçük partilere odaklanmasıyla [[Yalın düşünme|yalın düşünceye]] ilham kaynağı olmuştur. [[Andon|Andon kordonunun hızlı geri bildirim oluşturma, sürü oluşturma ve sorunları çözme ilkesi]] TPS'den kaynaklanmaktadır.<ref>[https://opensource.com/article/18/11/analyzing-devops Analyzing the DNA of DevOps], Brent Aaron Reed, Willy Schaub, 2018-11-14.</ref> <ref>{{Kitap kaynağı|başlık=The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations|tarih=2016|soyadı=Gene Kim|soyadı2=Patrick Debois|soyadı3=John Willis|soyadı4=Jezz Humble}}</ref>

== <span class="cx-segment" data-segmentid="82">DevSecOps</span> ==
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 testi|sola kaydırma]]" terimi kullanılır. Güvenlik üç ana alanda test edilir: statik, yazılım bileşimi ve dinamik.

[[Statik uygulama güvenliği testi|Statik uygulama güvenlik testi]] (SAST) aracılığıyla yazılımı statik olarak kontrol etmek, özellikle güvenliğe odaklanan [[Beyaz kutu testi|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ü [[Bilgisayar acil müdahale ekibi|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üvenliği testi|dinamik uygulama güvenlik testi]](DAST) veya sızma testi olarak adlandırılabilir. Amaç, [[Siteler arası betik çalıştırma|siteler arası komut dosyası oluşturma]] ve [[SQL Enjeksiyonu|SQL enjeksyion]] açıkları dahil olmak üzere kusurların erken tespit edilmesidir. Tehdit türleri, [[Owasp|açık web uygulaması güvenlik projesi]], örneğin TOP10<ref>{{Web kaynağı|url=https://owasp.org/Top10/|başlık=OWASP TOP10|erişimtarihi=June 8, 2023|arşivtarihi=June 8, 2023|arşivurl=https://web.archive.org/web/20230608171837/https://owasp.org/Top10/}}</ref> ve diğer kuruluşlar tarafından yayınlanmaktadır.

<span class="cx-segment" data-segmentid="105">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.<ref>{{Kitap kaynağı|başlık='DevSecOps: A leader's guide to producing secure software with compromising flow, feedback and continuous improvement'|tarih=December 2020|yayıncı=Rethink Press|ad=Glenn|soyadı=Wilson|isbn=978-1781335024}}</ref></span>

== Kültürel değişim ==
DevOps girişimleri, geliştirme ve teslimat süreçlerinde [[:en:Data_center_management#Operations|operasyonların]], geliştiricilerin ve [[Yazılım testi|test uzmanlarının]] işbirliği yapma şeklini dönüştürerek şirketlerde kültürel değişiklikler yaratabilir<ref>{{Rapor kaynağı|başlık=Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology|yayıncı=Gartner}}</ref>.<ref>{{Web kaynağı|url=http://radar.oreilly.com/2012/06/what-is-devops.html|başlık=What is DevOps?|tarih=7 June 2012|yayıncı=[[O'Reilly Media]]|ad=Mike|soyadı=Loukides}}</ref> Bu grupların uyumlu bir şekilde çalışmasını sağlamak, kurumsal DevOps'un benimsenmesinde kritik bir zorluktur.<ref>{{Web kaynağı|url=http://www.gartner.com/it-glossary/devops/|başlık=Gartner IT Glossary {{ndash}} devops|erişimtarihi=30 October 2015|çalışma=Gartner}}</ref> <ref>{{Kitap kaynağı|url=https://ueaeprints.uea.ac.uk/id/eprint/59131/4/Accepted_manuscript.pdf|başlık=Proceedings of the 2nd International Workshop on Quality-Aware DevOps - QUDOS 2016|tarih=21 July 2016|sayfalar=7–11|ad=Stephen|soyadı=Jones|isbn=9781450344111|ad2=Joost|ad3=Fiona|soyadı2=Noppen|soyadı3=Lettice|doi=10.1145/2945408.2945410}}</ref> DevOps, araç zinciriyle ilgili olduğu kadar kültürle de ilgilidir.<ref>{{Web kaynağı|url=https://www.oreilly.com/ideas/building-a-devops-culture|başlık=Building a DevOps culture|tarih=25 September 2015|yayıncı=O'Reilly|soyadı=Mandi Walls}}</ref>

== Mikro servisler ==
Prensipte DevOps'u herhangi bir mimari tarzla uygulamak mümkün olsa da, [[Mikro hizmetler|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.<ref>{{Konferans kaynağı|başlık=2014 IEEE/IFIP Conference on Software Architecture|kitapbaşlığı=The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014)|bölüm=Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development|tarih=2014|sayfalar=195–204|yayıncı=IEEE|ad=Lianping|soyadı=Chen|isbn=978-1-4799-3412-6|doi=10.1109/WICSA.2014.45|ad2=Muhammad|soyadı2=Ali Babar}}</ref>

== 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."<ref>https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3798877</ref>

== <span class="cx-segment" data-segmentid="120">Sürüm kontrolü ile otomasyon</span> ==
Birçok kuruluş [[Sanal makine|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 sistemi|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<sup>"<ref>{{Tez kaynağı|url=https://webthesis.biblio.polito.it/18120/|başlık=DevOps: development of a toolchain in the banking domain|erişimtarihi=16 August 2021|tarih=16 April 2021|lisans=laurea|çalışma=Politecnico di Torino}}</ref></sup> denilmekte ve [[Git (yazılım)|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 kontrol sistemi|sürüm kontrollüdür]]. En popüler sürüm kontrolü [[Git (yazılım)|Git]] olduğu için GitOps'un yaklaşımı Git'in adını almıştır. Yapılandırmadaki değişiklikler [[Kod incelemesi|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.<ref>{{Web kaynağı|url=https://www.redhat.com/en/topics/devops/what-is-gitops|başlık=What is GitOps?|erişimtarihi=2023-03-30|dil=en|çalışma=www.redhat.com}}</ref>''

=== Daha fazla okuma ===

* {{Kitap kaynağı|başlık=Effective DevOps : building a culture of collaboration, affinity, and tooling at scale|tarih=2016-05-30|yer=Sebastopol, CA|yayıncı=O'Reilly|ad=Jennifer|soyadı=Davis|isbn=9781491926437|ad2=Ryn|soyadı2=Daniels|oclc=951434424}}
* {{Kitap kaynağı|başlık=The DevOps handbook : how to create world-class agility, reliability, and security in technology organizations|tarih=2015-10-07|yer=Portland, OR|seri=First|ad=Gene|soyadı=Kim|isbn=9781942788003|ad2=Patrick|ad3=John|ad4=Jez|ad5=John|soyadı2=Debois|soyadı3=Willis|soyadı4=Humble|soyadı5=Allspaw|oclc=907166314}}
* {{Kitap kaynağı|başlık=Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations|tarih=27 March 2018|yayıncı=IT Revolution Press|seri=First|ad=Nicole|soyadı=Forsgren|isbn=9781942788331|ad2=Jez|ad3=Gene|soyadı2=Humble|soyadı3=Kim}}


== Kaynakça ==
== Kaynakça ==
6. satır: 73. satır:


== Ayrıca bakınız ==
== Ayrıca bakınız ==

*[[Veri merkezi yönetimi]]
* [[Scrum]]
*[[Atik yazılım geliştirme]]
* [[DataOps]]
*[[Yazılım geliştirme yöntembilimi]]
*[[Scrum]]
* [[Değer akışı]]
* [[Kod olarak altyapı]]
* [[DevOps araç zinciri]]
* [[Veri merkezi yönetimi]]
* [[Atik yazılım geliştirme]]
* [[Yalın yazılım geliştirme]]
* [[On iki faktörlü uygulama]]
* [[Yazılım geliştirme yöntembilimi]]
{{Yazılım mühendisliği}}
{{Yazılım mühendisliği}}
{{Otorite kontrolü}}
{{Otorite kontrolü}}

Sayfanın 03.59, 24 Nisan 2024 tarihindeki hâli

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

"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

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

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)

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

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

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)

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)

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

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

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

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

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

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

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

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

  • 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

  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