Bugünler de yazılım sektörü başta olmak üzere bir çok sektörde zaman ile yarıştığımızı gözlemliyorum. Bu yarış içinde öne çıkan en önemli şeylerden birisi de verimlilik olarak görünüyor. Çünkü verimlilik aynı zamanda geliştirme ve kaliteyi doğrudan etkilediği gibi zaman yönetimi açısından da çok önemli bir parametredir. Firmalar veya kuruluşlar Çevik (agile) yaklaşımları , mühendislik pratiklerini ve sürekli teslim (devops) süreçleri ile bunu sağlamaya çalışıyorlar. Fakat yeterli mi? derseniz şuan için yeterli değil. Çünkü değişim sürekli olan bir şey ve buna adapte olma kısmında eksiklerimiz görünüyor. Çevik yaklaşımların prensiplerinden biriside aslında budur. Fakat bu adaptasyonu yaparken şuan öğrendiğimiz kalıplara bağlı kalarak ilerliyoruz. İşte bu kalıp bağlı kalma yaklaşımı bizi bu yeni düzende ayağı bağlı bırakmaktadır. Bir adım önde ilerlemesi gereken konularda önde olmayı bırakalım bir adım geriden ilerliyoruz.
Bu yazımızda bu hızlı değişime ayak uydurma kısmında değişmemiz gereken alanlardan biri olan uygulamalara eklediğimiz özellikler ve bunların kullanıma alınması konusu üzerinde durmak istedim. Bunu sürümlerin ve/veya ön sürümlerin yönetilmesi olarak görebilirsiniz. Şuan aslında çok görünmese de ön planda olan kısımlardan biri budur. Özellikle çevik yaklaşımlar ve hızlı olarak ürünü kullanıma sunulması kısmında yaklaşımlarımızı değiştirmemiz gerekiyor. Özellikle devops süreçlerinin hayatımıza hızlıca girdiği bu günlerde mikro servis ve konteyner teknolojilerini de ele aldığımızda karışımıza çıkan sorulardan bir tanesi.
Biz gerçekten ürünlerimizi doğru test ederek mi kullanıma açıyoruz?
Evet bunu bir düşünmemiz gerekiyor. Biz uygulamalarımızı gerçekten tam anlamıyla test edebiliyor muyuz ? Birim testleri çok iyi yaptığımızı var sayalım. Testçilerimizin standartları ve kara kutu testlerini de tam yaptıklarını farz edelim. Otomatikleştirilmiş bir sistemimiz bile var. Sizce yine de uygulamalar bu hız çağında yeterli seviyede test ediliyor mu ?
Çünkü günümüzdeki bu kızlı kod yazma ve otomatik testlerle belli zaman aralıklarında (aslında beklenen dakikalar içerisinde olmasıdır) sürekli üretim ortamına kod çıkma kendi içinde riskleri de barındırmaktadır.
Onlarca birbirinden bağımsız mikro servis ve konteynerlere yollanmış uygulamaları bir düşünün. Bunlarda sorunlar oluştuğunda olabilecekleri bir hayal edelim.
Şunu dediğinizi duyar gibiyim “Yukarıdakileri yapıyorsak bu neden olsun ki! “. Hadi görmemiz gereken o gri noktaya odaklanalım. Üretim ortamının kendisi ve oradaki verinin geliştirme ortamları için oluşturulabilmesi halen çok zor. KVKK’nın da hayatımıza girmesiyle aslında imkansız gibi bir hal aldı. Kendi ortamlarımızdan yazılımcılar olarak artık kontrolümüzde olmayan ortamlara doğru kaymaktayız. Bu kayışta çok hızlı olmaktadır. Bu kayışlar da bizi farklı yerlere götürmektedir.
Üretim Ortamında Test Yapmak
Üretim ortamında test yapılması gerçekten istenmeyen bir şeydir. Ama gerçekçi olmak gerekirse hiçbir test de canlı sistem testi gibi olmamaktadır. Fakat insanlara bunu yapıp yapmadıklarını sorsanız. “Canlı sistem de test mi olur biz yapmıyoruz” derler. Hatta sizleri küçümseyenler olur. Fakat bunu diyenlerin Pilot yapıyor musunuz sorusuna cevabı ise evet olacaktır. Aslında Pilotlama , Canary releases, Ring deployments ve Percentage rollouts olarak adlandırılan bu kalıplar uygulamaların canlı sistemde test edilmesinden başka bir şey değildir. Adını ne koyarsanız koyun yaptığınız iş değişmez. Buradan canlı sistem kodunu debug etmeye çalışanlar lüften pay çıkarmasın. Bu ikisi farklı iki literatürdür.
Güçlü yazılım firmaları ürünlerini geliştirirken ürünlerin gelecekteki özelliklerin bir kısmını aslında canlı sistemlere de çıkmaktadır. Bunları canlı ortamda belli kitlelere göre deneterek nihai halini aldırıp bir sonraki sürümle çıkmaktadırlar.
Hatta bu durumla ilgili olarak üniversite zamanlarımızda nvidia ekran kartlarının bu özelliğinden faydalanarak aynı chipsete sahip daha iyi bir ekran kartının saklı özelliklerini aktif edebiliyorduk. Nvidia bizim gibi bir çok kişi tarafından fark edilen bu durumu daha sonra kapamıştı veya biz öyle sanıyorduk. Şuan baktığımda bu işi yönetilebilir hale getirdiğini düşünüyorum.
Yazılım sektöründeki derin örneklerinde birisi de Java 8 ile gelen Java 9 garbage collector’ udur. Bir parametre ile yeni gelecek olan gc’yi sistemlerinizde kullanabilir oluyordunuz. Javanın yeni gc’si çalışıyor ise neden bunu yapsın ki ? Cevap çok basit canlı sistem ortamını oluşturmanız ve yeterli test yapmanız aslında mümkün değildir. Java canlı sistem testini bizlere yaptırarak ve geri dönüşleri toplayarak daha iyi bir gc sistemine kavuşmuş oldu.
O zaman karşımıza şu çıkmıyor mu ? Kodun dağıtılması (code deployment ) ile uygulama sürümü (release) aynı şey değildir. Evet doğru okudunuz. Çünkü bir kodun dağıtılması onun kullanılacağı anlamına gelmez. Onun ne zaman kullanıma açılacağı sizin elinizdedir. Yani sürümün aktif edilmesi size bağlıdır.
Özelliklerin Yönetimi
Özelliklerin veya sürümlerin yönetimini çeşitli teknikler altında ele alabiliriz.
Kanarya sürümü (Canary Release)
Bu sürüm adını eskiden madencilerin zehirli gazları tespit etmek için beraberlerinde tünellere indirdiği kanaryalardan almaktadır. Böylece tehlike herkesi etkilemeden önce kanarya ile bu tehlikeyi tespit edebiliyorlardı.
Günümüzde ise yeni özellikler tüm altyapıya yayılmadan ve herkes için kullanılabilir hale getirilmeden önce, küçük bir kullanıcı alt grubuna bu değişikliği yavaşça dağıtarak yapılan bir uygulamadır. Burada ki amaç üretimde yeni bir yazılım sürümü oluşturma riskini azaltmaktır.
Yeni sürümden memnun olduğunuzda, seçilen birkaç kullanıcıyı bu uygulamaya yönlendirmeye başlayabilirsiniz. Hangi kullanıcıların yeni sürümü göreceğini seçmek için farklı stratejiler vardır: Basit bir strateji rastgele bir örnek kullanmaktır; bazı şirketler yeni sürümü dünyaya salıvermeden önce iç kullanıcılarına ve çalışanlarına yayınlamayı tercih eder;
Pilotlama
Pilotlama genel bir teknik olarak değil bir terim olarak düşünülebilir. Pilotlamayı buraya anti pattern olarak eklemek istedim. Çünkü bu işlemler bizde bir teknik veya pratiğe göre yapılmamaktadır. Bir tekniğe dayalı olmayan ama bizim kendi seçtiğimiz bir grup veya firma içinden yaptığımız prod ortamı denemesi olarak düşünebilirsiniz. Diğer bir tabir ile profesyonel olmayan ama kullanılan bir iş yapış şeklidir.
Yüzdelik Dağıtımlar (Percentage Deployments)
Buradaki amaç sistemi yüzdesel olarak kullanıma açmaktır. Küçük bir grup kullanıcı seçilerek sistem başlatılır. Gelen geri bildirimler olumluysa bu yüzdelik dilim genişletilerek ilerletilir. Bu sistem kullanıcı yapısı çok değişmeyen uygulamalar için daha başarılıdır.
Ring Deployments
Buradaki amaç en az riskli gruptan daha riskli olana doğru ilerlemesi şeklindedir. En az risk grubu seçilerek bunlar üzerindeki denemeler ile başlayabilirsiniz. Böylece olası bir problemde etkilenme çapını hem azaltmış hemde kontrol altında tutmuş olursunuz. Firma içinden başlayan denemeleri bu örnekler içinde düşünebiliriz. Muhasebe yazılımı yazan bir firmayı düşünelim önce kendi muhasebe ekibinden başlayarak müşterisi olan firmalara doğru yayılması bu kapsama güzel bir örnektir.
Sürümleri Yönetmek
Yukarıda anlattığımız teknikleri kullanmanın dezavantajı, uygulamanın birden çok sürümünü aynı anda yönetmemiz gerektiğidir. Üretimde ortamlarında birden fazla sürüm olabilir ama bunları en azda tutmak daha iyi olacaktır. Web uygulamalarını düşündüğümüzde bu çok büyük bir sorun olarak görünmüyor. Çünkü dağıtımları yönetmek kolaydır.
Asıl zor olan ise bilgisayarlar veya mobil cihazlar üzerinde yüklü olan yazılımları istemcilere dağıtmamız veya bu dağıtımları geri almamızdır. Çünkü bu durumda istemci tarafındaki uygulamaları yönetmek bir hayli zor olacaktır. Bunu yönetmek için sürüm destekleri vb. teknikler uygulanabilir.
Bütün bu durum ele alındığında güçlü bir değişilik yönetimine sahip olmanız gerektiği ön plana çıkmaktadır. Bu sistemde devops ekibi , değişikli yönetimi ekipleri ve sürümlerden kaynaklı geri bildirimleri yönetecek olan ekiplerin güçlü bir birlikteliği gerekmektedir. Bunları yapabildiğimiz zaman işte o bir adım önde olma yönünde hızlıca ilerliyor olacağız.