Continuous Delivery-DevOps

10-11 Aralık 2015 tarihleri arasında İstanbul’da acm‘in organize ettiği Dave Farley‘in eğitimci olduğu “Continuous Delivery – DevOps” eğitimindeydim. Dave, “Continuous Delivery (CD)” kitabının yazarı ve hazır Türkiye’ye gelmişken bu ilginç konuda bişeyler öğrenmenin tam zamanı diye düşündüm.

Continuous delivery

CD, temel olarak bir Agile konsepti. Amaç özetle yazılımların çok daha hızlı bir şekilde yeni sürümünü çıkartmak. Öyle ki günde onlarca yeni sürüm yayınlayabilmek mümkün. Bu yöntemle her zaman el altında yayınlanabilir bir sürüm bulunuyor.

Bildiğiniz gibi yazılımların yeni bir sürümleri yazılım değişiklikleri ve/veya hata düzeltmeleri içerir. Her bir sürüm çeşitli test aşamalarından (Beta test, Unit Test, Functional Integration Test, User Acceptence Test, Deployment Test, Usability Test, Regression Test, vs.) geçerek nihayetinde canlı sisteme yüklenir (PRD deployment). Bu epey uzun (aylar sürebilir), meşakkatli, riskli ve pahalı bir yöntemdir.

Bütün firmalar bu “sürüm yönetiminin” (release management) en hızlı, risksiz ve ucuz yolunu bulmaya can atarlar. Amaç, işin getirdiği gereksinimleri çok çabuk yazılıma adapte etmek ve yeni sürüm yayınlamaktır. Tabi geleneksel yöntemler, özellikle waterfall yöntemi bu açıdan yavaş kalıyor. Bunun yerine son yıllarda Agile methodları giderek daha fazla rağbet görmeye, şirket üst yönetimlerinin radarına girmeye ve uygulanmaya başladı. İşte “Continuous Delivery” bu Agile yöntemlerden bir tanesi ve Dave’in iddasına göre şirketlerin tam da aradığı şey!

Tabii ki ben kendi tecrübelerimi de düşünerek bu konudaki çekincemi paylaşmadan edemezdim. Yani waterfall henüz ölmedi, yaşıyor ve ona da ihtiyaç var hala 🙂 Bana göre “CD”yi her organizasyonun şıp diye hemen uygulaması biraz zor gibi. Organizasyonun buna ikna olması gerekiyor öncelikle. Ama iyi tarafları da var tabii ki 🙂 Öncelikle development ekibinin “Acceptence Testing” yapması (sorumlu olması), bunun için iş biriminin “Acceptence Criteria” ları önceden tanımlamasının zorunluluğu “bi harika dostum!”. En çok sevdiğim tarafıysa bu “Acceptence Testing”in otomatize edilmesi (Testing Automation). Bu noktada Test Yönelimli Geliştirme (TDD-Test Driven Development), DSL (Domain Specific Language) araçlarıyla test otomasyonunu uygulamak oldukça ilgi çekici. Biz de HQ Quality Center ile test otomasyonu işine bu yıl şirket olarak adım atmış olduk. Sanırım seneye bu işle biraz ilgilenmem gerekecek. Kafamda bi ışık yandı! Benim için eğitimin en faydalı tarafı bu oldu. Şu an ekibim fazlasıyla bu “Unit Test” olayına dalmış durumda. Bu işi adamakıllı çözmek için “Develoment” ekibinin “Acceptence Test”i otomatize etmesi ve iş birimlerinin de gerekli “acceptence criteria/test case”leri önceden tanımlamaları gerekiyor. Aksiyon almaya başladım bile. Hadi hayırlısı bakalım. Bizim ekibin “unit test” yerine, şirket için katma değeri yüksek “change management”a daha fazla zaman harcaması gerekiyor. Kolları sıvadım bile..

dave_farley

Point Hotel Barbaros’ta Dave ve ben..

 

Bir Cevap Yazın