Bağımlılıklar ne zaman güncellenmelidir?

İki farklı kod temeli (Android ve Node.js web uygulaması) olan iki büyük bağımlılıkla ilgili kriz yaşadık. Android deposunun Google Play Services kitaplığının dört ana sürümünün güncellenmesini gerektiren Flurry'den Firebase'e geçiş yapması gerekiyordu . Benzer bir şey, bizim üretim yığımızın (sedirin) kullanımdan kaldırıldığı ve sedir-14'e yükseltilmesi gereken Heroku'da barındırılan Düğüm uygulamamızla oldu. PostgreSQL veritabanımızın ayrıca 9.2'den 9.6'ya güncellenmesi gerekiyordu.

Bu uygulamaların bağımlılıklarının her biri neredeyse iki yıl boyunca bayat kaldı ve bazıları kullanımdan kaldırıldıklarında ve 'gün batımı' dönemine ulaştığımızda, onları güncellemek veya değiştirmek büyük bir baş ağrısı oldu. Geçtiğimiz ay boyunca 30 saatten fazla bir süre boyunca tüm çatışmaları ve hatalı kodları çözmek için harcadım.

Belli ki iki yıl boyunca işleri bekletmek çok uzun. Teknoloji, özellikle Heroku gibi bir platform sağlayıcı kullanıyorsanız, hızla hareket eder. Tam teşekküllü bir test odasına ve Travis CI gibi bir güncelleme işlemine sahip olduğumuzu varsayalım. Örneğin, bir yükseltme işleminden sonra bir işlev kaldırılmışsa ve kullanıyorduysanız testleriniz başarısız olur.

Bağımlılıklar ne sıklıkta güncellenmeli veya bağımlılıklar ne zaman güncellenmeli? Güncelledik çünkü buna zorlandık, ama bir çeşit önleyici yaklaşım daha iyi olacak gibi görünüyor . Küçük sürümler çıktığında güncelleme yapmalı mıyız? Büyük versiyonlar? Güncellemeler varsa her ay? Ne pahasına olursa olsun yaşadıklarım gibi bir durumdan kaçınmak istiyorum.

PS - kişisel Rails projelerimden biri için , örneğin güvenlik açıklarından haberdar olmanız için bağımlılıklarınızı takip eden Gemnasium adında bir servis kullanıyorum . Harika bir hizmet, ancak bahsettiğim projeler için bağımlılıkları manuel olarak kontrol etmek zorunda kalacağız.

Genelde aşağıdaki durumlarda bağımlılıkları yükseltmelisiniz:

1. Gereklidir
2. Bunu yapmak için bir avantaj var
3. Bunu yapmamak dezavantajlıdır

(Bunlar karşılıklı olarak dışlayıcı değildir.)

Motivasyon 1 ("mecbur olduğunuzda") en acil iticidir. Bağlandığınız bazı bileşen veya platformlar (örneğin Heroku) bunu talep eder ve sıraya girmelisiniz. Gerekli güncellemeler çoğu zaman diğer seçeneklerin dışında kalır; PostgreSQL sürümüne yükseltme yapmaya karar veriyorsunuz. Şimdi sürücülerinizi, ORM versiyonunuzu vb. Güncellemeniz gerekiyor.

Yükseltme, çünkü siz veya ekibiniz bunu yapmanın bir avantajı olduğunu daha yumuşak ve daha isteğe bağlıdır. Bir karar daha fazlası: "Yeni özellik, yetenek, performans, ... çabaya değer ve çıkma neden olur mu?" Olden Times'da, isteğe bağlı yükseltmelere karşı güçlü bir önyargı vardı. Manuel ve zorlardı, onları sanal alanda denemenin iyi bir yolu yoktuya da sanal ortam, ya da çalışmazsa güncellemeyi geri almak için ve güncellemelerin "elma arabasını üzmediğini" doğrulayan hızlı otomatik testler yapılmamıştır. Günümüzde önyargı daha hızlı, daha agresif güncelleme döngüleri yönünde. Çevik yöntemler şeyleri denemeyi sever; otomatik montajcılar, bağımlılık yöneticileri ve repolar kurulum sürecini hızlı ve çoğu zaman neredeyse görünmez kılar; sanal ortamlar ve her yerde kullanılan sürüm kontrolü dalları, çatalları ve geri almaları kolaylaştırır; ve otomatikleştirilmiş testler bir güncellemeyi daha sonra kolayca denememize izin veriyor ve önemli ölçüde değerlendirdi: "İşe yarıyor mu? Önyargı toptancıları "kırılmadıysa düzeltmeyin" den "erken güncelleme, sık sık güncelleme" olarak değiştirdi

Motivasyon 3 en yumuşak olanıdır. Kullanıcı hikayeleri kendilerini "tesisat" ile ilgilenmez ve asla bahsetmezler ve alt yapısını mevcut olanın arkasındaki N sürümünden daha fazla tutmazlar. Versiyonun kaymasının dezavantajları (kabaca, eğrinin arkasına düşme ile ilgili teknik borç) sessizce yerleşir, sonra sık sık kendilerini kırılma yoluyla ilan eder. "Üzgünüz, bu API artık desteklenmiyor!" Çevik ekiplerde bile, belirli bir sprint veya serbest bırakmanın tamamlanmasında çok önemli görülmediğinde, artımlılığı motive etmek ve bileşenlerin tazeliğini "zirvede tutmak" zor olabilir. Eğer hiç kimse güncellemeleri savunmazsa, istemeden gidebilir. Bu tekerlek kırılmaya hazır olana kadar veya hatta kırılana kadar gıcırtılı olmayabilir.

Pratik bir bakış açısıyla, ekibinizin sürüm kayması sorununa daha fazla dikkat etmesi gerekiyor. 2 yıl çok uzun. Sihir yok. Bu sadece "şimdi bana öde veya daha sonra öde" meselesi. Ya sürüm kayması sorununu aşamalı olarak ele alın ya da her birkaç yılda bir daha fazla sarsıntı yaşayın ve sorun yaşayın. Artımlılığı tercih ediyorum, çünkü platformların bir kısmı sarsıldı. Artık çalışmayacağınız bir anahtar API veya platform, gününüzü, haftanızı veya ayınızı gerçekten mahvedebilir. Bileşen tazeliğini yılda en az 1-2 kez değerlendirmeyi seviyorum. İncelemeleri açıkça planlayabilir veya görece metronomik, genellikle Python, PostgreSQL ve node.js. gibi ana bileşenlerin yıllık güncelleme döngüleri tarafından tetiklenmelerini sağlayabilirsiniz. Bileşen güncellemeleri ekibinizi çok güçlü bir şekilde tetiklemiyorsa, tazminat büyük sürümleri kontrol eder, doğal yaylalarda ya da her k bülteninde çalışabilir. Hangisi daha düzenli bir kadansta sürüm kaymasını düzeltmeye dikkat ediyor.

Kütüphaneler güncellenmeleri gerektiğinde güncellenmelidir. Bu, güncelleme hiçbir değer getirmezse, yapmamalısınız demektir.

Özel bir durumda, eski bir teknoloji yığından yenisine geçiyordunuz ve bunun için bağımlılıklarınızı güncellemek zorunda kalıyordunuz. O an bağımlılıkları güncellemek için doğru zamandır.

Bağımlılıklarınızı zaman içerisinde güncellemiş olsaydınız, “şu anda başınız ağrıyor” diye, geri dönüş değeri için çok fazla çalışma zamanı (kodlama) yatırmanız gerekecekti. Son güncellemeyi yaptığınızda (şu anda yaptığınız, ancak 4 yerine 1 ana sürümü güncellerken), muhtemelen bir yerlerde başınız ağrıyordur (sonuçta, ana sürüm değişikliklerin kırılması anlamına gelir). Bu yüzden doğru yolda olduğunuzu düşünüyorum.

Bununla birlikte, göç etmeyi çok zor buluyorsanız ve çok fazla refactor yapmak zorunda kalırsanız, kod tabanınızda sorun olabilir. Android projelerinin kod yapısı açısından genel bir mimariye sahip olmaması oldukça yaygındır. Dagger 2 gibi iyi bir bağımlılık enjeksiyon çerçevesi ve SOLID gibi birkaç yazılım mühendisliği ilkesi , aynı davranışı / gereksinimleri korurken kod uygulamasını değiştirmeyi kolaylaştıracaktı.

Ayrıca, yeniden düzenleme yaptığımızdan, bu tür bir işi yaparken çok yardımcı olacağı için Ünite Testi hakkında biraz bilgi edinin.

Paket yönetim araçlarını kullanıyorsanız (örn. Npm, NuGet) ve kapsamlı bir otomatik test takımına sahipseniz, bağımlılıkların yükseltilmesi düşük çaba gerektiren bir faaliyet olmalıdır, sadece paketi yükseltin, test takımınızı çalıştırın ve herhangi bir sorun olup olmadığını görün. Eğer varsa, sorunu araştırmak ve düzeltmek için geri alma ve iş öğesini kaldırma.

Yükseltme bağımlılıklarının maliyeti düşük olduğu sürece, güncel tutmaya değer:

• Yükseltme ile ilgili sorunlar varsa, yukarı yönde değişiklik yapılması gerektiğinde daha erken değil, daha önce bilmek istersiniz.
• Bağımlılık yükseltmelerini son dakikaya bırakmak çoğu zaman bu yükseltmeleri sıkışma zamanında yaptığınız anlamına gelir (örn. Güvenlik açısından kritik bir hataya cevap olarak). Bağımlılıklarınızın üstesinden gelmek, bu çabayı ne zaman harcadığınızı kontrol etmeniz ve bu yükseltmeleri meşgul olmadığınız zamanlarda gerçekleştirebilmeniz anlamına gelir.
• Daha yeni sürümler verimlilik iyileştirmelerine sahip olabilir, örneğin daha iyi belgeler, API kullanımı daha kolay, düzeltmeler (bunun tersi de mümkün olsa da).

Yükseltme bağımlılıkları çok az çaba gerektirmiyorsa (örneğin, yükseltmeyi manuel olarak test etmeniz gerektiğinden veya bilinen sorunlar / ihlaller olduğundan), diğer görevlerinize göre artıları ve eksileri tartmanız gerekir. Eski bağımlılıklar bir tür düşük faizli teknik borçtur ve buna göre ele alınmalıdır.

Bağımlılıklarınızın eski sürümlerini bilerek kullandığınız bir sürüm yapmamalısınız, bu sürümler desteklenmeyen alternatifler değilse.

Örneğin, eğer V1’deyseniz ve hala destekleniyorsa, v1’in en son sürümünü kullanabilirsiniz.

Güncel olmamanız gereken tek zaman şudur:

C: Bir süredir serbest bırakmadınız.

B: V1’de uzun süredir desteklenmiyorsunuz

Güncellemeler bir sebepten dolayı piyasaya sürülmüş olmalı, gemide almanız gereken güvenlik düzeltmeleri içerir.

Bağımlılığınızın yeni bir sürümü çıkarsa, aynı zamanda bir sürüm de yapmalısınız.

Söz konusu kütüphaneye bir dereceye kadar bağlı olması gerektiğini düşünüyorum, ancak kendime benzer bağımlılık baş ağrılarım oldu.

Sağduyu, bana büyük bir sürümün muhtemelen yükseltme zamanı geldiğini ve ciddi bir kusura işaret eden veya önemli bir yararı içeren küçük bir sürümün yerini alacağını söylüyor.

Bazen bakım gerektiren her uygulama üzerinde çalışma lüksüne sahip değiliz, hatta kritik bir görevi yerine getirmekten vazgeçebiliriz, ancak sonunda sizi ısırırlar ve önlenmenin bir onsu çoğu zaman sert bir tedavi sağlar!

Yazılımın, değişimde harcadığınız işi telafi etmek için kullanacağınız bir avantaj sunduğunda, kütüphaneler güncellenmelidir.

Küçük kütüphane sürüm yükseltmeleri bile uygulamalardaki tutarsızlıkları kırabilir veya ekleyebilir. Bu açıdan bakıldığında ufak bir değişiklik yoktur.

Eski libleri kullanmakta utanılacak bir şey yok. Değişim gerektiğinde acı verici olabilir ama işin bir parçası.