Yazılım Güncellemesi Yayına Alma: 7 Güvenli Adım

Bir ambalaj malzemeleri dağıtıcısı düşünün. Sipariş panelleri bayilerin kullandığı bir web uygulaması. Cuma akşamı saat altıda yeni bir iskonto ekranı yayına alınıyor; geliştirici ekranı denemiş, çalışıyor. Pazartesi sabahı muhasebe arıyor: hafta sonu gelen siparişlerin hiçbiri faturaya dönüşmemiş. İskonto için eklenen yeni alan, fatura aktarımının beklediği bir sütunun adını değiştirmiş. Kimse fatura tarafına bakmamış, çünkü değişiklik "yalnızca iskontoyla ilgiliydi".

Bu tür bir sabahı yaşayan şirket genellikle iki sonuçtan birine varır: ya geliştiriciye güveni azalır ya da güncellemeleri olabildiğince seyrek yapmaya karar verir. İkincisi daha tehlikelidir. Güncelleme seyrekleştikçe her biri daha büyük olur, daha büyük güncelleme de daha çok yeri aynı anda bozar.

Sorunun önemli bir kısmı yazılan koddan değil, kodun kullanıcıya nasıl ulaştığından kaynaklanır. Aşağıdaki yedi alışkanlık hem kendi ekibi olan şirketler hem de yazılımını bir dış ekibe yaptıranlar için geçerlidir.

1. Değişiklikleri küçük ve sık yayına alın

Üç ayda bir yapılan büyük güncellemede onlarca değişiklik aynı gün canlıya çıkar. Bir şey bozulduğunda hangisinin bozduğunu bulmak saatler alır, geri almak da hepsini birden geri almak demektir.

Haftada bir ya da iki kez yapılan küçük yayınlarda ise her seferinde birkaç değişiklik vardır. Sorun çıktığında aday listesi kısadır ve yalnızca o küçük parça geri alınabilir. Kullanıcı da her seferinde az şeyin değiştiğini görür, alışması kolaylaşır.

Bunun için işleri küçük parçalara bölmek gerekir. "Yeni iskonto modülü" tek bir iş değildir; önce veri alanı, sonra hesaplama, sonra ekran, en son bayiye açılması gibi ayrı yayınlara bölünebilir.

2. Deneme ortamı canlı sisteme benzesin

Geliştiricinin bilgisayarında çalışan şey canlıda çalışmayabilir. Arada farklı bir veritabanı sürümü, eksik bir ayar, başka bir dosya yolu ya da bağlı olunan bir dış servisin farklı sürümü olabilir.

Yayından önce değişikliği deneyeceğiniz ayrı bir ortam kurun ve onu canlıyla aynı yazılım sürümleri, aynı ayarlar ve aynı entegrasyonlarla çalıştırın. Verisi canlının kişisel bilgileri maskelenmiş bir kopyası olabilir; boş bir veritabanında her şey hızlı ve sorunsuz görünür.

Fatura aktarımı gibi başka sistemlere dokunan akışlar bu ortamda da uçtan uca denenmelidir. Yukarıdaki dağıtıcının sorunu tam olarak burada yakalanırdı.

3. Yayın saatini takvime bağlayın

Cuma akşamı yayına alınan bir değişiklik, sorun çıkarsa hafta sonu boyunca kimsenin bakmadığı bir sorundur. Ay sonu kapanış günleri, kampanya başlangıçları ve sezonun en yoğun haftası da aynı şekilde kötü zamanlardır.

Şirketiniz için bir yayın penceresi belirleyin: örneğin salıdan perşembeye, öğleden önce, geliştiricinin ve işi bilen bir kullanıcının ulaşılabilir olduğu saatler. Acil güvenlik düzeltmeleri bu kuralın dışındadır; geri kalan her şey takvimi bekleyebilir.

4. Geri dönüş yolunu yayından önce yazın

"Bir şey olursa geri alırız" cümlesi, nasıl geri alınacağı yazılı değilse bir plan sayılmaz. Her yayından önce şu üç soruya cevap verin:

• Bir önceki sürüme dönmek için hangi adımlar atılacak ve ne kadar sürecek?
• Bu kararı kim verecek?
• Yeni sürümle girilen veriler, eski sürüme dönülünce ne olacak?

Çoğu modern yayın düzeninde önceki sürüme dönmek birkaç dakikalık bir iştir. Zor olan kısım genellikle verilerdir; bu yüzden bir sonraki madde ayrı bir başlık olarak ele alınmalıdır.

5. Veritabanı değişikliklerini iki adımda yapın

Kodu geri almak kolaydır; silinmiş bir sütunu ya da adı değiştirilmiş bir tabloyu geri almak değildir. Dağıtıcı örneğindeki sorun da bir sütunun adının değişmesiydi.

Daha güvenli yol, değişikliği iki yayına bölmektir. İlk yayında yeni alan eklenir, eski alan yerinde kalır ve uygulama bir süre ikisine birden yazar. Her şeyin yeni alanı kullandığından, raporların ve entegrasyonların da ona geçtiğinden emin olunduktan sonra, ayrı bir yayında eski alan kaldırılır.

Bu yaklaşım biraz daha fazla iş gerektirir, ama ilk yayında bir sorun çıkarsa kod geri alınır ve veri hâlâ eski sürümün anlayacağı biçimde durur.

6. Yayından sonraki yarım saati planlayın

Yayın, değişiklik canlıya çıktığında bitmez. İlk yarım saat içinde, işi bilen biri sistemin en önemli akışlarını kısa bir listeden sırayla denemelidir: bir bayi hesabıyla giriş, bir sipariş oluşturma, siparişin faturaya aktarılması, bir raporun açılması.

Bu liste on dakikadan uzun sürmemeli ve her yayında aynı olmalıdır. Uzun bir test planı değil, "bunlar bozulursa şirket durur" diyebileceğiniz beş altı adımdır. Listeyi geliştirici değil, sistemi her gün kullanan biri hazırlarsa daha isabetli olur.

Aynı yarım saatte hata kayıtlarına da bakılmalıdır. Kullanıcı bir hatayı bildirmeden önce kayıtlarda görünmeye başlar.

7. Kullanıcıya neyin değiştiğini söyleyin

Ekranda bir düğmenin yeri değiştiğinde, kullanıcı bunu bir hata olarak algılayabilir. Haber verilmemiş her değişiklik destek hattına bir telefon olarak döner.

Her yayınla birlikte kısa bir sürüm notu yazın: neyin değiştiği, kimi etkilediği ve yeni bir şey yapmaları gerekip gerekmediği. İki üç cümle yeterlidir. Bayilerin ya da sahadaki ekibin günlük işini değiştiren güncellemeler ise önceden duyurulmalıdır, mümkünse bir ekran görüntüsüyle.

Sürüm notları zamanla başka bir işe de yarar: bir sorun çıktığında "bu ne zaman değişti?" sorusunun cevabı oradadır.

Kısaca

• Değişiklikleri küçük parçalara bölün ve sık yayına alın.
• Canlıyla aynı sürüm, ayar ve entegrasyonlara sahip bir deneme ortamı kullanın.
• Cuma akşamı, ay sonu ve yoğun günlerde yayın yapmayın.
• Geri dönüşün adımlarını, süresini ve kararı kimin vereceğini önceden yazın.
• Veritabanı değişikliklerini iki ayrı yayına bölün.
• Yayından sonra kısa ve sabit bir deneme listesi çalıştırın, hata kayıtlarına bakın.
• Her yayına iki üç cümlelik bir sürüm notu ekleyin.

Bu alışkanlıkların hiçbiri büyük bir yatırım gerektirmez; çoğu bir kez konuşulup yazıya geçirildiğinde düzen hâline gelir. Kazanç ise güncellemeden korkmayan bir şirkettir. Güncellemeden korkmayan şirket de yazılımını güncel ve güvenli tutar.

Yazılım bakım ve destek işlerimizde küçük değişiklik taleplerini de aynı düzen içinde planlayıp yayına alıyor, her sürüme kısa bir sürüm notu ekliyoruz.