İçeriğe atla

DevOps

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.[a][b][c][d] 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.[5] 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.[6]

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

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

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.[9][10] Konferans artık diğer ülkelere de yayılmıştır.[11]

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

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.[14][15] 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.[16][17]

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

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.[22] 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.[23]

Atik (Agile)

Ana madde: Atik yazılım geliştirme

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".[24] 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.[25] 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.[26] 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.[27] 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.[28]

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

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[32] 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.[33]

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

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

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

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

Daha fazla okuma

Notlar

  1. ^ Dyck et al. (2015) "To our knowledge, there is no uniform definition for the terms release engineering and DevOps. As a consequence, many people use their own definitions or rely on others, which results in confusion about those terms."[2]
  2. ^ Jabbari et al. (2016) "The research results of this study showed the need for a definition as individual studies do not consistently define DevOps."[3]
  3. ^ Erich et al. (2017) "We noticed that there are various gaps in the study of DevOps: There is no consensus of what concepts DevOps covers, nor how DevOps is defined."[4]
  4. ^ Erich et al. (2017) "We discovered that there exists little agreement about the characteristics of DevOps in the academic literature."[4]

Kaynakça

  1. ^ Courtemanche, Meredith; Mell, Emily; Gills, Alexander S. "What Is DevOps? The Ultimate Guide". TechTarget (İngilizce). 22 Ocak 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 22 Ocak 2023. 
  2. ^ Dyck, Andrej; Penners, Ralf; Lichter, Horst (19 Mayıs 2015). "Towards Definitions for Release Engineering and DevOps". Proceedings of the 2015 IEEE/ACM 3rd International Workshop on Release Engineering. IEEE. s. 3. doi:10.1109/RELENG.2015.10. ISBN 978-1-4673-7070-7. 
  3. ^ Jabbari, Ramtin; bin Ali, Nauman; Petersen, Kai; Tanveer, Binish (May 2016). "What is DevOps?: A Systematic Mapping Study on Definitions and Practices". Proceedings of the 2016 Scientific Workshop. Association for Computing Machinery. 
  4. ^ a b Erich, F.M.A.; Amrit, C.; Daneva, M. (June 2017). "A Qualitative Study of DevOps Usage in Practice". Journal of Software: Evolution and Process. 29 (6). ss. e1885. doi:10.1002/smr.1885. 
  5. ^ Bass, Len (2015). DevOps: A Software Architect's Perspective. ISBN 978-0134049847. 
  6. ^ Muñoz, Mirna; Rodríguez, Mario Negrete (1 Nisan 2021). "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. 
  7. ^ Chapman, M., Gatti, N: A model of a service life cycle, Proceedings of TINA '93, pp. I-205–I-215, Sep., 1993.
  8. ^ Atlassian. "History of DevOps". Atlassian (İngilizce). 16 Şubat 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 23 Şubat 2023. 
  9. ^ Mezak, Steve (25 Ocak 2018). "The Origins of DevOps: What's in a Name?". devops.com. 24 Şubat 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Mayıs 2019. 
  10. ^ Debois, Patrick (9 Ekim 2008). "Agile 2008 Toronto". Just Enough Documented Information. 26 Kasım 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 12 Mart 2015. 
  11. ^ Debois, Patrick. "DevOps Days". DevOps Days. 8 Kasım 2011 tarihinde kaynağından arşivlendi. Erişim tarihi: 31 Mart 2011. 
  12. ^ a b Alana Brown; Nicole Forsgren; Jez Humble; Nigel Kersten; Gene Kim (2016). "2016 State of DevOps Report" (PDF). Puppet Labs, DORA (DevOps Research. 28 Haziran 2018 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 6 Mayıs 2019. 
  13. ^ "Puppet - Alanna Brown". Puppet Labs. 17 Aralık 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Nisan 2019. 
  14. ^ Nicole Forsgren; Gene Kim; Nigel Kersten; Jez Humble (2014). "2014 State of DevOps Report" (PDF). Puppet Labs, IT Revolution Press and ThoughtWorks. 27 Nisan 2019 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 27 Nisan 2019. 
  15. ^ "2015 State of DevOps Report" (PDF). Puppet Labs, Pwc, IT Revolution Press. 2015. 6 Mayıs 2019 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 6 Mayıs 2019. 
  16. ^ "More Agile Testing" (PDF). October 2014. 7 Eylül 2018 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 6 Mayıs 2019. 
  17. ^ Crispin, Lisa; Gregory, Janet (October 2014). More Agile Testing. Addison-Wesley. ISBN 9780133749571. 30 Kasım 2022 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Mayıs 2019. 
  18. ^ Turner, Graham (20 Kasım 2023). "Report: Software Engineers Face Backlash for Reporting Wrongdoing". DIGIT (İngilizce). 5 Aralık 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 5 Ocak 2024. 
  19. ^ Saran, Cliff. "Software engineers worry about speaking out - Computer Weekly". ComputerWeekly.com (İngilizce). 24 Aralık 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 5 Ocak 2024. 
  20. ^ "75% of software engineers faced retaliation the last time they reported wrongdoing - ETHRWorldSEA". ETHRWorld.com (İngilizce). 13 Mart 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Nisan 2024. 
  21. ^ Cummins, Holly. "Holly Cummins on X". X.com. 5 Ocak 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 5 Ocak 2024. 
  22. ^ Klein, Brandon Thorin (1 Mayıs 2021). "The DevOps: A Concise Understanding to the DevOps Philosophy and Science". Osti.gov (İngilizce). doi:10.2172/1785164. 5 Mart 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Nisan 2024. 
  23. ^ "The History and Evolution of DevOps | Tom Geraghty" (İngilizce). 5 Temmuz 2020. 1 Aralık 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 29 Kasım 2020. 
  24. ^ "Principles behind the Agile Manifesto". agilemanifesto.org. 7 Aralık 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Aralık 2020. 
  25. ^ Castellanos, Camilo; Correal, Dario (15 Eylül 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. 
  26. ^ Tak, Rohin; Modi, Jhalak (2018). Mobile DevOps: Deliver continuous integration and deployment within your mobile applications. Packt Publishing. ss. 12-18. ISBN 9781788296243. 
  27. ^ 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. 
  28. ^ Chen, Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software. 32 (2): 50-54. doi:10.1109/MS.2015.27. 
  29. ^ Beyer, Betsy; Jones, Chris; Petoff, Jennifer; Murphy, Niall Richard (April 2016). Site Reliability Engineering. O'Reilly Media. ISBN 978-1-4919-2909-4. 
  30. ^ Analyzing the DNA of DevOps 28 Kasım 2023 tarihinde Wayback Machine sitesinde arşivlendi., Brent Aaron Reed, Willy Schaub, 2018-11-14.
  31. ^ Gene Kim; Patrick Debois; John Willis; Jezz Humble (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. 
  32. ^ "OWASP TOP10". 8 Haziran 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Haziran 2023. 
  33. ^ 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. 
  34. ^ Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology. Gartner. 
  35. ^ Loukides, Mike (7 Haziran 2012). "What is DevOps?". O'Reilly Media. 25 Mayıs 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Nisan 2024. 
  36. ^ "Gartner IT Glossary  – devops". Gartner. 26 Kasım 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 30 Ekim 2015. 
  37. ^ Jones, Stephen; Noppen, Joost; Lettice, Fiona (21 Temmuz 2016). Proceedings of the 2nd International Workshop on Quality-Aware DevOps - QUDOS 2016 (PDF). ss. 7-11. doi:10.1145/2945408.2945410. ISBN 9781450344111. 6 Ocak 2024 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 24 Nisan 2024. 
  38. ^ Mandi Walls (25 Eylül 2015). "Building a DevOps culture". O'Reilly. 7 Mayıs 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Nisan 2024. 
  39. ^ 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. 
  40. ^ "DevOps and Its Practices by Ravi Teja Yarlagadda :: SSRN". 15 Nisan 2024 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Nisan 2024. 
  41. ^ DevOps: development of a toolchain in the banking domain. Politecnico di Torino (laurea tez). 16 Nisan 2021. 16 Ağustos 2021 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Ağustos 2021. 
  42. ^ "What is GitOps?". www.redhat.com (İngilizce). 30 Mart 2023 tarihinde kaynağından arşivlendi. Erişim tarihi: 30 Mart 2023. 

Ayrıca bakınız

İlgili Araştırma Makaleleri

<span class="mw-page-title-main">Açık kaynak yazılım</span> açık kaynak lisansıyla yayınlanmış programlama kodu

Açık kaynak yazılım ya da açık kaynak kodlu yazılım, telif hakkı sahibinin kullanıcılara yazılımı ve kaynak kodunu herhangi bir amaç için kullanma, inceleme, değiştirme ve dağıtma haklarını verdiği bir lisans kapsamında yayınlanan bilgisayar yazılımıdır. Kullandıkları lisans gereğince isteyen kişi ve grupların yazılımı kendi kişisel ihtiyaçlarına uyarlamalarına ve sonunda değişikliği benzer tercihlere sahip kullanıcılar için bir çatal olarak yayınlamalarına olanak tanır.

<span class="mw-page-title-main">Tümleşik geliştirme ortamı</span> yazılım geliştirmek için kullanılan yazılım ortamı

Tümleşik geliştirme ortamı, bilgisayar programcılarının hızlı ve rahat bir şekilde yazılım geliştirebilmesini amaçlayan, geliştirme sürecini organize edebilen birçok araç ile birlikte geliştirme sürecinin verimli kullanılmasına katkıda bulunan araçların tamamını içerisinde barındıran bir yazılım türüdür.

<span class="mw-page-title-main">Bilgisayar destekli tasarım</span>

Bilgisayar destekli grafik-tasarım, bir tasarımın oluşturulmasına, değiştirilmesine, analizine veya optimizasyonuna yardımcı olmak için kullanılan bir yazılım programı. CAD yazılımı, tasarımcının üretkenliğini ve tasarım kalitesini artırmak, dokümantasyon yoluyla iletişimi geliştirmek ve üretim için bir veritabanı oluşturmak için kullanılır. Üç boyutlu ve iki boyutlu tasarımlar için farklı programlar kullanılabilir. Siemens PLM NX, SOLIDWORKS, Autodesk Maya, AutoCAD, CATIA bu programlardan bazılarıdır.

Bilgi işlem platformu, bir uygulama yazılımı çalıştırmak için donanım mimarisi ve bir yazılım çerçevesi, yazılım, çeşitli bazı kombinasyon veya sıralamalarını içermektedir. Tipik platformlarda bir bilgisayar mimari, işletim sistemi, programlama dilleri ve ilgili kullanıcı arabirimi içerir.

<span class="mw-page-title-main">Yazılım iskeleti</span>

Bilgisayar programlamada yazılım iskeleti, yazılım çerçevesi ya da yazılım çatısı, standart fonksiyonların hazır olarak sunulduğu ancak programcı tarafından bu fonksiyonlardan arzu edilen kısımların ek kodlarla istenildiği şekilde güncellenebildiği sistemlerdir.

Mobil güvenlik ya da mobil telefon güvenliği, mobil işlemenin öneminin ve kullanılan akıllı telefonların sayısının artması ile birlikte öne çıkmıştır. Genel olarak bakıldığında, mobil güvenlik, mobil cihazlarda saklanan bilgilerin ve servislerin koruma altına alınması olarak değerlendirilebilir.

Palo Alto Networks, Inc. Santa Clara, Kaliforniya merkezli bir Amerikalı ağ güvenliği şirketidir. Şirketin ana ürünleri; ağ güvenliği, görünürlüğü ve uygulama, kullanıcı ve içerik tanımlamaya dayalı ağ ekinliklerinde taneli kontrolü sağlamak için tasarlanmış gelişmiş güvenlik duvarlarıdır. Palo Alto Networks Cisco, Fortinet, Check Point, Juniper Networks, Cyberoam ve diğerlerine karşı UTM ve ağ güvenliği sektöründe rekabet etmektedir.

<span class="mw-page-title-main">Yazılım testi</span>

Yazılım testi, test altında hizmetlerin veya ürünlerin kalitesi hakkında paydaşlara bilgi sağlamak için yürütülen bir araştırmadır. Yazılım testi aynı zamanda, yazılım uygulamalarının risklerini anlamak için yazılımı bağımsız ve nesnel olarak incelemektir. Test teknikleri yazılım böceklerini bulma niyetiyle uygulama veya bir programı çalıştırma süreçlerini kapsar.

<span class="mw-page-title-main">Bluemix</span> IBMin geliştirdiği yazılım

Bluemix, IBM'in bulut üzerinde geliştirdiği platform as a service (PaaS) platformudur.

<span class="mw-page-title-main">Regresyon testi</span>

Regresyon testi uygulama ortamındaki yapılan tüm değişiklikleri; uygulamaya yeni eklenen özellikler, daha önceki yaşanan hataların düzeltilmesinden sonra, mevcut problemlerin giderildiği ve yeni yapılan güncellemelerin, eklenen özelliklerin yeni bir hata üretip üretmediğini kontrol amaçlı olarak yapılan yazılım test türüdür.

Özel mülk yazılım ya da sahipli yazılım, yazılımın yaratıcısının, yayıncısının veya diğer hak sahibi ortaklarının fikrî mülkiyet hakkını ve telif hakkını kendi elinde tuttuğu bilgisayar yazılımıdır. Yazılımın alıcılarına, yazılımı özgürce paylaşma veya değiştirme hakkı vermez. Özel mülk yazılımlar, mülk sahipleri tarafından ücretli ya da ücretsiz olarak yayınlanabilir.

Yazılım test etmede, test otomasyonu önceden tahmin edilmiş sonuçlarla gerçek sonuçların karşılaştırılması ve testlerin koşulmasını kontrol etmek için(test edilmiş yazılımdan farklı olan) belirli yazılımın kullanılmasıdır. Test otomasyonu tekrar eden fakat çoktan test etme süreçlerinde yer almış gerekli testlerin otomatikleştirebilir veya manuel olarak koşulmasının zor olacağı testleri de içerebilir. Test otomasyonları sürekli paket dağıtımı veya sürekli test etme için kritik öneme sahiptir.

<span class="mw-page-title-main">Android yazılımı geliştirme</span>

Android yazılım geliştirmesi Android işletim sistemi için yeni uygulamaların oluşturulduğu süreçtir. Uygulamalar genellikle Android yazılım geliştirme kiti (SDK) kullanılarak Java programlama dilinde geliştirilir; ancak diğer geliştirme ortamları da mevcuttur. Google, Android uygulamaları Kotlin, Java ve C++ dilleri kullanılarak Android yazılım geliştirme kiti (SDK) kullanılarak yazılabilir" ve diğer dilleri kullanmak da mümkün olduğunu belirtiyor. Go, JavaScript, C, C++ veya Assembly gibi Java sanal makinesi (JVM) dışı tüm diller, muhtemelen kısıtlı API desteğiyle araçlar tarafından sağlanabilecek JVM dil kodunun yardımına ihtiyaç duyar.

<span class="mw-page-title-main">Kent Beck</span> Amerikalı yazılımcı

Kent Beck Amerikalı bir yazılım mühendisi ve ekstrem programlamanın yaratıcısıdır. işbirlikçi ve yinelemeli bir tasarım süreci için katı biçimsel belirtimlerden kaçınan bir yazılım geliştirme metodolojisi. Beck, Agile Manifesto'nun 17 orijinal imzacısından biriydi. Extreme ve Agile yöntemler, Beck'in belki de önde gelen savunucusu olduğu Test Odaklı Geliştirme (TDD) ile yakından ilişkilidir.

<span class="mw-page-title-main">Martin Fowler</span>

Martin Fowler, nesne yönelimli analiz ve tasarım, UML, kalıplar ve ekstrem programlama dahil çevik yazılım geliştirme metodolojilerinde uzmanlaşmış, yazılım geliştirme konusunda İngiliz bir yazılım geliştiricisi, uluslararası konuşmacı ve yazardır.

Michael Anthony Jackson, İngiliz bilgisayar bilimcisi ve Londra, İngiltere'de bağımsız bilgisayar danışmanıdır. Aynı zamanda Birleşik Krallık'taki Açık Üniversite'de misafir araştırma profesörüdür.

<span class="mw-page-title-main">Craig Larman</span>

Craig Larman 1958 yılında Kanada doğan bir bilgisayar bilimcisi, yazar ve organizasyonel geliştirme danışmanıdır. Bas Vodde ile en iyi LeSS formülasyonu ve ürün ve yazılım geliştirme üzerine birkaç kitabı ile tanınmaktadır.

Açık Web Uygulama Güvenliği Projesi (OWASP), web uygulama güvenliği alanında ücretsiz olarak kullanılabilen makaleler, metodolojiler, belgeler, araçlar ve teknolojiler üreten çevrimiçi bir topluluktur.

<span class="mw-page-title-main">Linus yasası</span>

Linus yasası, yazılım geliştirmede "Yeterince göz olduğu sürece, tüm hatalar yüzeyseldir" yönündeki görüştür. Bu yasa Eric S. Raymond tarafından "Katedral ve Pazar" adlı makale ve kitap çalışmasında formüle edilmiş ve Linus Torvalds'ın onuruna isimlendirilmiştir.

Rogue Wave Software Louisville, Colorado merkezli bir Amerikan yazılım geliştirme şirketiydi. Paralel, veri yoğun ve diğer yüksek performanslı bilgi işlem (HPC) uygulamaları için platformlar arası yazılım geliştirme araçları ve gömülü bileşenler sağlıyordu.


Bu sayfa, bu Vikipedi makalesine dayanmaktadır.
Metin, CC BY-SA 4.0 lisansı altında mevcuttur; ek koşullar uygulanabilir.
Görseller, videolar ve sesler kendi lisansları altında mevcuttur.