DevOps’a olan rağbetin artmasıyla birlikte hakkında çıkan dedikodular da onunla birlikte artıyor. Her popüler konu gibi DevOps’da da bilgi kirliliği ortaya çıkmaya başladı desek çok da yalan söylemiş olmayız. Bu yazıda, ekosistemde sıkça karşılaşılan DevOps Agile’ı Öldürüyor Mu? sorusunu cevaplamaya çalışacağım. Bunu cevaplarken de bir yandan DevOps vs Agile tartışacağız. Öncesinde Scrum vs Kanban konusunda hazırladığım yazıyı da okumak isteyebilirsiniz.
Sorunun cevabı tabii ki hayır. Bunun çeşitli sebepleri var. En bariz olanı ise DevOps’un framework veya metodoloji olmayışı. DevOps’u bir felsefe olarak düşünmek yanlış olmayacaktır. Agile için olmazsa olmaz olan, her seferinde ufak özellikler eklenerek geliştirilen çalışan yazılım, çalışan yazılımın gelişiminin monitor edilmesi gibi konular aynı zamanda DevOps’un da olmazsa olmazıdır. Aslında Agile geliştirme yapan ekipler tarafından yazılmamış kanun olan bu özellikler için DevOps, benim olmazsa olmazım diyor.
Kesişen Noktalar
DevOps’un isminde saklı olan en büyük özelliği Dev Team ve Ops Team‘i birbirine yaklaştırmasıdır. Analist, Tester, QA, DB Admin gibi rollerin aralarında yer alan delay‘lerin kısaltılması DevOps felsefesinin esas amacıdır. Bu amaç uğrunda işletilen süreçler, pipeline‘lar ise birer araçtır. Scrum framework’ünde de benzer bir amaç söz konusudur. Scrum içerisinde Analist, Tester vs. gibi roller yer almaz. Bu rollerin tamamı Development Team içerisinde veya diğer 2 Scrum rolünde yer almaktadır. Scrum bu rollerin hiç birine gerek yok, gerekli olan Dev. Team‘in cross-functional yani bu rollerin tamamını kendi içinde çözebilen bir takım olması gerektiğini söylüyor fakat pratikte bireylerin uzmanlıkları olması da çok yanlış bir yaklaşım değil. Bu rollerin tamamının zaten Dev. Team içinde çözülebilmesi de Dev ve Ops kişilerinin zaten bir bütün olarak hareket etmesi demek oluyor.
DevOps tarafında önemli olarak vurgulanan ikinci büyük amaç ise CI/CD(Continuous Integration/Deployment) pipeline‘ları kullanarak minimum efor ile production ortamına çıkmak. Agile takımlarının da benzer yöntemi izlememesi için hiçbir sebep veya engel bulunmuyor. Agile bize şu yolları izleyerek prod‘a çıkmalısın demiyor. Tersine agile manifesto, kapsamlı dokümantasyondan ziyade, çalışan yazılıma önem verilmesi gerektiğinden bahsediyor. Bu aşamada da sürekli build alınması, hatta her commit ardından yazılımın çalışır durumda olduğundan emin olunması gerekiyor. Sadece çalışabilir olması da yeterli değil, unit testler, fonksiyonel testler, selenium testler her commit’in ardından çalıştırılmalı ve sadece sprint sonlarında değil, her an prod‘a çıkılabilir olunması gerekiyor.
Sprint’lere Gerçekten İhtiyacım Var Mı?
Sprint’ler bir Agile takım için sonunda elde edilecek hedefi belirler. Sprint Planlama aşamasında ilgili sprintin hedefi(Sprint Goal) ve bu hedefe ulaşabilmek için yapılması gereken işler(Sprint Backlog) belirlenir. Bunu bir bakıma Dev. Team‘in taahhütü olarak da değerlendirebiliriz. Dev. Team, Sprint sonunda hedefte belirlenen amaca ulaşabilmek adına taahhüt ettiği işlerin tamamını kendi içinde çözmek ve tamamlamaktan sorumludur. Belirlenen bu hedef ile aslında karşılıklı şu şekilde bir anlaşma kurulmuş oluyor;
- Dev. Team, Sprint için belirlenen hedefi dışarıdan yardım almadan çözebilir. Bu yüzden de cross-functional‘dır.
- Dev. Team, Sprint’te belirlenen hedefe Sprint sonunda ulaşacağını taahhüt etmiştir. Kendi kendine organize(self-organized) olup bu hedefe ulaşmaya çalışacaktır.
Kısa süreli projeler düşünüldüğünde gerçekten Sprint planlama ve hedef belirlemeye gerek olmayabilir. Ancak geliştirilmesi hedeflenen projenin kompleksitesi arttıkça sprintlerin önemi ortaya çıkmaya başlıyor. Tahmini olarak 1 ay ve üstü projelerde sprint planlaması yapılmadan, nasıl olsa DevOps uyguluyoruz, müşterinin isteklerini anlık çözüp karşısına çıkartıyoruz bakış açısıyla ilerlemek normalden daha kompleks bir projeyle karşı karşıya kalmamıza sebep olacak ve gün geçtikçe katlanarak artacaktır.
Buna ek olarak DevOps’un önerdiği gibi CI/CD pipeline‘larını iş akışına dahil edip, Dev/Test senaryolarına müşterileri de dahil ederek daha gerçekçi feedback‘lere ulaşmak mümkün. Scrum’da karşımıza çıkan, sadece 1 aylık sprint’in sonucunda elde edilen çıktının Sprint Review toplantısında demosunun yapılması devri bence artık geride kaldı.
Burada hem DevOps hem de Agile ekiplerinin geliştirmesi gereken özellikler ortaya çıkıyor. DevOps ekiplerinin Sprint ve seremonilerini, Scrum ekiplerinin ise CI/CD pipeline‘larını iş akışlarına dahil etmesi gelecek başarılar adına önemli.
Zaten DevOps uyguluyorum, Definition of “Done”a İhtiyacım Yok!
Definition of “Done”ı direk Türkçe’ye çevirip “Tamamlandı Tanımı” diyebiliriz. Bir işin tamamlanması için ihtiyaç olan maddeleri listelediğimiz bir tanım. Bu liste içerisine kodların yorumlanması, ilgili testlerin, QA incelemelerinin, test ortamına deployment’ın, load test’lerin yapılması gibi maddeler eklenebilir ki bu maddeler her ekipte farklılık gösterebilir.
Definition of “Done” sayesinde Dev. Team‘in bir işi tamamlandı olarak işaretleyebilmesi için izleyeceği adımlar sıralanmış oluyor. Bu maddelerin bir kısmının otomatize edilebileceği yadsınamaz bir gerçek. Daha önce de belirttiğim gibi Scrum ekiplerinin bu maddeleri CI/CD pipeline‘larına taşıması ile birlikte tanımda belirtilen bazı maddelerin, geliştiricinin insiyatifinde olmadan zaten otomatik olarak gerçekleşeceğini garanti altına almış oluyoruz. Bu hem Dev. Team üzerindeki yükün azalması hem de kesinlikle her seferinde gerçekleşeceği anlamına geliyor.
Otomatik gerçekleşemeyecek olan her türlü maddenin ise Definition of “Done” içerisinde yer alması ve Dev. Team tarafından uygulanılması gerekiyor. Kod yorumlama, pair-programming‘in uygulanması bunlara örnek olarak verilebilir. Hatta eskiden tanımlarımızda yer almayan deployment sonra monitoring işlemlerinin de artık Definition of “Done” içerisine yedirilmesi gerekiyor.
Bu konuda da hem Agile hem de DevOps ekiplerinin iş süreçlerine eklemesi gereken maddeler bulunuyor.
Özetle…
Agile ve DevOps bakıldığı zaman birbirlerinden çok ayrı şeyler değil. Agile takımları, mühendislik alanındaki gelişmeleri takip ederek bu tarz yaklaşımları iş süreçlerine yedirmeli. Günümüz dünyasında hızın önemi arttıkça otomatik gerçekleşmesi gereken işlemlere olan ihtiyaç daha da fazla artıyor. DevOps yaklaşımına ayak uydurabilen şirketler de gelecekteki yerlerini garanti altına alıyor. Geldiğimiz noktada DevOps ekiplerinin, Agile framework’lere, Agile ekiplerinin ise DevOps’a ayak uydurmadan maksimum verimliliği alabilmesi çok olası değil. İki tarafın da iş süreçlerinde çeşitli değişiklikler, eklemeler yapmaları gerekmekte.
