Agile Consulting&Coaching

DevOps ile Engelleri Aşmak

Kısıtlar Teorisinin sahibi ve bu teorinin bir roman kurgusunda anlatıldığı “The Goal” kitabının yazarı Eliyahu Goldratt diyor ki; her bilgi teknolojileri organizasyonu aynı anda,

  • Acil iş taleplerine ve ihtiyaçlarına daha hızlı yanıt verebilmenin,
  • İstikrarlı, güvenli ve tahmin edilebilir bilgi teknolojileri hizmeti sağlamanın,

baskısı altındadır. Sözü edilen bu baskı, müşteri ihtiyaçlarına hızlı bir şekilde çözüm üretmesi beklenen geliştirme ekipleri ile, üretilen bu çözümleri kritik sistemleri sekteye uğratmadan müşteriye ulaştırmaya çalışan operasyon ekiplerinin, ortak bir hedefe farklı paradigmalarla yaklaşmasına sebep oluyor. Oysa her iki ekibin lideri konumunda olan pozisyondan (CIO) bakıldığında hedef tek ve ortak: Müşteriye değer katacak ürün ve hizmetleri kaliteli ve hızlı bir şekilde sunmak. Geliştirme ve operasyon ekiplerinin paradigma farklılıklarından kaynaklanan sebeplerle bu hedefe ulaşılamaması CIO (Career Is Over) pozisyonunu zor durumda bırakabilir.

Yazılım geliştirme sürecinde bahsedilen bu ikilemi daha da kötü boyutlara götürecek bir davranış şeklini, bugüne kadar insani bir yaklaşım olarak benimsemiş olabiliriz: Yapmakta zorlandığımız şeyleri ötelemek. Örneğin test aşaması analiz ve yazılımın arkasından gelir veya üretim ortamına benzer bir ortama taşıma yapmak için yazılımın tamamlanmasını bekleriz. Oysa ötelediğimiz bu işler ortak hedefe ulaşma yolundaki en kritik aşamalardır. Test olmadan kalite olmaz, sona kalan test aşamasının hızlı tamamlanması için baskı yapılıyorsa hiç olmaz. Son aşamada tespit edilen bulgular için önceki aşamalara geri dönülüyorsa hız olmaz. Üretilen yazılımı üretim ortamında çalıştırmakta sıkıntı varsa, müşteri için değer üretimi olmaz.

Psikolojik açıdan baktığımızda da zorlandığımız şeyleri öteleme eğilimimiz, deneyimlediğimiz kötü tecrübelerin etkisini artırır. Çünkü beynimiz herhangi bir süreçte yaşadığımız acının en yoğun olduğu anı ve sürecin bitimindeki son anı kaydeder. Bu acıya ne kadar süre maruz kaldığımızı ise gözardı eder. Bu demektir ki acı veren işleri önce yapmalı ve mümkün olduğunca sürecin içine yayarak etkisini azaltmalıyız.

Bu bakış açısı ile yazılım geliştirme sürecine baktığımızda;

  • Yazılımın çalışacağı ortamı hazırlamak acı veriyorsa, geliştirme faaliyetleri başladığında ihtiyacımız olan her ortamı mümkünse üretim ortamına benzer şekilde oluşturmaya başlayacağız,
  • Kodu entegre etmekten korkuyorsak ve bu yüzden her özelliği başka yerde geliştirmeye yöneldiysek sürekli entegrasyon yapacağız,
  • Entegre ettiğimiz kodun çalışmama ihtimali bizi endişelendiriyorsa, birim testleri ve diğer gerekli testleri çalışacak kodu oluştururken ve entegrasyon anında otomatik çalıştıracağız,
  • Yazılımın kullanıcının ihtiyaçlarını karşılayamaması gibi bir durumla karşılaşmak istemiyorsak, entegrasyonun hemen arkasından otomatik kabul testlerini devreye sokacağız,
  • Sürümde problem yaşamak istemiyorsak, kodu her aşamada, üretim ortamına benzer bir ortama aynı taşıma süreci ile tek tuşla otomatik olarak taşıyarak sürüm öncesi bu süreci defalarca test etmiş olacağız,
  • Yaptığımız değişikliklerin birşeyleri bozmasından endişe ediyorsak, proje boyunca değişebilecek herşeyi versiyon yönetim sistemi üzerinden yönetip istediğimiz ana geri döneceğiz.
  • Devreye aldığımız değişikliklerin sistemi sekteye uğratacağından korkuyorsak, kod, konfigürasyon ve altyapıdaki her değişiklikle tetiklenen, tekrarlanabilir, güvenilir ve tahmin edilebilir bir yapı kuracağız.  

DevOps yaklaşımı, yazılım geliştirmenin korkularımıza yenik düşerek ördüğümüz duvarların arkasından yapılamayacağını bize anlatıyor. Çevik yaklaşımlarla iş tarafı ve geliştirme ekipleri arasındaki, geliştirme ekibinin kendi içindeki duvarlar nasıl yıkılıyorsa, devops hareketi de geliştirme ekibi ve operasyon ekibi arasındaki duvarları kaldırıyor.

Bütün bunları yapabilmek için, geliştirme ekibi ve operasyon ekibinin hedefin tek ve ortak olduğunu anlaması, sürecin ilk aşamalarından itibaren sinerji yaratacak şekilde birlikte çalışması ve farklı bakış açıları yerine tek bir paradigmaya yönelmesi gerekiyor: “Hedeflerimiz çelişmiyor. Müşteriye değer katan çözümleri kaliteli ve hızlı bir şekilde sunarken, kritik sistemlerin daha istikrarlı çalışmasını da sağlayabiliriz.”