Üçüncü taraf kütüphanelerinizi nasıl güncel tutabilirsiniz?


28

Diyelim ki 10 kütüphaneye bağlı bir projem var ve projemin bagajında ​​bu kütüphanelerin herhangi bir versiyonunu kullanmakta özgürüm. Bu yüzden en yeni sürümlerle başladım. Ardından, bu kitaplıkların her biri ayda bir kez güncelleme alır (ortalama). Şimdi, bagajımı tamamen güncel tutmak, her üç günde bir kütüphane referansının güncellenmesini gerektiriyor.

Bu belli ki çok fazla. Genellikle sürüm 1.2.3, sürüm 1.2.2 için bir değiştirme alternatifi olsa da, test yapmadan asla bilemezsiniz . Birim testleri yeterli değil; bir DB / dosya motoruysa, eski sürümlerle oluşturulmuş dosyalarla düzgün çalıştığından emin olmalısınız ve bunun tersi de olabilir. GUI ile ilgisi varsa, görsel olarak her şeyi kontrol etmeniz gerekir. Ve bunun gibi.

Bununla nasıl başa çıkıyorsun? Bazı olası yaklaşımlar:

  • Kırılmadıysa, tamir etmeyin . Sürece kitaplığın geçerli sürümü ile kalın Eğer uygulamanızda, kitaplık firması güncellemeleri yayınlar ne sıklıkta olursa olsun kullanıldığında onunla ihbar şey yanlış yok. Küçük artımlı değişiklikler sadece atıktır.
  • Değişimin küçük kalması için sık sık güncelleyin. Her durumda bir günü güncellemek zorunda kalacağınız için, sık sık güncellemek daha iyi olur; bu nedenle, birkaç sürüme atlamak ve olası sorunların birikmesine izin vermek yerine, kolayca düzeltilebilecekleri herhangi bir sorunu farkedebilmeniz için erken fark edin.
  • Arada bir şey var. Tatlı bir yer var mı?

1
+1: Acaba "böcek avı" gibi, bir projede "Güncelleme Sprint" iterasyonuna sahip olabilirsiniz. Cevaplar hakkında merak
ediyorum

Yanıtlar:


25

Şok oldum - ve gerçekten dehşete düştüm - "mecbur kalmadıkça güncelleme yapma" diyen cevapların sayısında. Bunu yaptım ve kısa vadede daha kolay olsa da, uzun vadede cehennem gibi yanıyor. Daha sık, daha küçük güncellemeler, zaman zaman büyük olanlardan daha yönetmek için çok daha kolaydır ve yeni özelliklerin, hata düzeltmelerinin ve benzerlerinden daha kısa sürede yararlanabilirsiniz.

Kütüphane değişikliklerinin, bir şekilde kod değişikliklerinden daha zor test edildiğine dair bir fikrim yok. Aynısı - kod tabanında bir değişiklik yapıyorsunuz ve bunu yapmadan önce ve serbest bırakmadan önce daha derinlemesine doğrulamalısınız. Ancak bunu yapmak için zaten işlemleriniz olmalı, çünkü kod değişiklikleri yapıyorsunuz!

İki ila dört hafta uzunluğundaki yinelemelerde çalışıyorsanız, her bir yinelemeden biraz daha gevşemiş olduğunda, başlangıçtan sonra en kısa sürede yapılması gereken kitaplıkları yineleme görevi başına bir kez güncellemenizi öneririm. son teslim tarihi ve proje değişimi absorbe etme kapasitesine sahip. Oturmak için birisini (veya bir çiftlemeyi programlıyorsanız) bir araya getirin, hangi kütüphanelerin güncellendiğine bakın ve her birini bir araya getirmeyi ve yeniden denemeyi ve test etmeyi deneyin. Belki de her yineleme için bir günden bir güne kadar bütçe. İşler işe yararsa, değişiklikleri kontrol edin (kitaplıkları kaynak kontrolünde tuttuğunuzu farz ediyorum; yaptığımız gibi; değişimin kontrollü bir şekilde nasıl yayılacağından emin değilim). Eğer otomatikleştirilmiş testleriniz varsa, testler tamamen manuel olmaktan çok daha kolay olacaktır.

Şimdi, asıl soru, eğer bir güncelleme kırılırsa ne yaparsınız - düzeltmek için zaman harcıyor musunuz veya dışarıda bırakıyor musunuz? İkincisine yaslanmayı öneririm; Bir saat içinde sabitlenebilirse, yapın, ancak bir güncelleme bütünleşmek için önemli çalışmalar yapacaksa, o zaman kendi geliştirme görevi olarak yükseltin, tahmin edilmesi, önceliklendirilmesi ve diğerleri gibi planlanması. Büyük olasılıkla, çok önemli bir düzeltme veya iyileştirme getirmediği sürece, önceliğin düşük olacağı ve buna asla başaramayacağınız ihtimaller. Ancak, bir sonraki yinelemeli güncelleme günü sona erdiğinde, sorun kendiliğinden çözülmüş olabilir; Olmasa bile, en azından şimdi güncelleme yolunda bir barikat olduğunu biliyorsunuz ve bu sizi şaşırtıyor.

Bu uzunlukta tekrarlamalar yapmıyorsanız, güncellemeler için bir tür bağımsız zamanlama hazırlarım - ayda bir. Aylık bir durum incelemesi ya da bir mimarlık kurulu toplantısı gibi bağlayabileceğiniz başka bir proje ritmi var mı? Maaş günü? Pizza gecesi? Dolunay? Her neyse, geleneksel bir sürüm döngüsünden çok daha kısa bir şey bulmanız gerekir, çünkü her 6-18 ayda bir her şeyi bir seferde güncellemeye çalışmak acı verici ve moral bozucu olacaktır.

Söylemeye gerek yok, yayınlanmadan önce dalları dengeleme yaparsanız, bu politikayı onlara uygulamazsınız. Orada, yalnızca kritik düzeltmeleri almak için kitaplıkları güncelleştirirsiniz.


3
+1. Devs’in “kırılmadıysa düzeltmedi” politikasını uyguladığı bir proje üzerinde çalıştım. Sonra, daha sonradan daha sonraki bir sürümde düzeltilen, daha sonra jvm'ye bağlı olan, 3. parti kütüphanesinde (nispeten küçük fakat yeni bir özellik için gerekliydi) bir sorun bulduk. Daha sonra jvm ile, sırayla yükseltilmesi gereken diğer 3. parti kütüphanelerle ilgili sorunlar bulduk. Ayrıca, artık Solaris için 32 bit jvm'ye sahip olmadığı için donanımımızı yükseltmemiz gerekti. Bir karışıklıktı ve işleri basit tutmakla kolayca önlenebilirdi.
firtydank

+1 "Kısa vadede daha kolay olsa da, uzun vadede cehennem gibi yanıyor". Her iki yaklaşımı da deneyimledim ve birçok küçük güncelleme sıkıntı gibi görünse de, yükseltme yapmıyor ve 2 kütüphaneli 10 kütüphaneyi yükseltmek zorunda kalmak, genellikle makul bir sürede mümkün olmuyor. Eski ve eskimiş kütüphanelere dayanan bir sisteme sahip olursunuz, diğer kütüphaneleri kullanamazsınız, çünkü yükseltemezsiniz kütüphanenin daha yeni bir sürümünü gerektirir ve bir noktada bazı sorunları çözme yeteneğini kaybedersiniz herşey.
Michał Kosmulski

@firtydank Bu gerçeği çözmek için ne yaptığınızı merak ediyorum, yeni politikalar uyguladınız mı? Organizasyondaki işlevsel değişiklik neydi?
buddyp450

10

Ben değerlendiririm.

  • Öncelikle o kütüphaneye karşı yükselttiğimiz hataları araştırıyorum ve düzeltilip düzeltilmediklerini görüyorum.
  • İkincisi, kütüphanede yararlanabileceğimiz herhangi bir hata düzeltmesini arıyorum (belki de olası bir köşe durumu olabilir).
  • Üçüncüsü, lib / API'deki gelişmeleri araştırıyorum ve sonra kodumuzu değiştirerek bunun yararını kullanmamın faydasını araştırıyorum. Geçmişte yükseltme lib'lerinde sık sık yeni özelliklerini kullanmadan gerçekten çok aptalca davrandım!

Daha sonra, mevcut lib ile kalmaya karşı bütün bunları tartıyorum.

Her zaman sınama - umarım birim / entegrasyon sınamalarınız büyük gerileme olmamasını sağlar.


7

Üçüncü şahıs kütüphanelerdeki en büyük sorun, üretime geçmeden önce bunları güncellerken SİZİN başvurunuzu tekrar test etmeniz gerektiğidir. Bu nedenle, bir kitaplığın güncellenmesini gerektiren rapor edilmiş bir hataya sahip değilseniz, tam bir kalite güvence döngüsü yapacak vaktiniz olmadıkça bunlara dokunmayın.

Bu genellikle yeni bir sürüm çıkarıldığında yapılır.

Bununla birlikte, geliştirme dalındaki kütüphaneleri güncellemenizi ve bunu otomatik olarak yapmanızı sağlayan sürekli derleme için bir test takımınız olduğunu öneririm. Bu, kırıldığında erken keşfetmenizi sağlar, böylece projeye hata raporları gönderebilirsiniz.


3

Kısmen, svn satıcı şubelerinde açıklandığı gibi . Açıklanan prosedür, açık kaynaklı üçüncü taraf kütüphanelerini uzun süre kullanmaya devam ettiğinizde ve ihtiyaçlarınızı ayarlamak için değişiklikler yaptığınızda çok faydalıdır.


2
Lütfen sadece bağlantı bırakma. Bağlantılar kaybolma eğilimindedir. Lütfen en azından neye bağlandığınızı özetlemeyi düşünün. Eğer bu bağlantı koparsa, bu ne kadar faydalı olurdu .. belki birkaç yıl sonra?
Tim Post

Ve yukarı oy :)
Tim Post

2

Bir projenin tüm kütüphanelerini yayınlanmadan hemen önce veya hemen sonra güncellemeyi düşünüyorum. Ancak, 10 veya 15'ten fazla kütüphaneye güvenirseniz, bu durumda bir çeşit güncelleme kontrol mekanizması çok yardımcı olabilir. Bunun avantajı, kütüphanelerinizi test etmek için zaman ayırmış olmanız ve herhangi bir sorunu tek seferde çözebilmenizdir. Ayrıca her bir kütüphaneden gelen güncellemeleri sürekli takip etmek zorunda kalmazsınız, güncellemeleri takip etmek için belirli bir günü kontrol etmeniz yeterlidir.

Ayrıca bir dev dalında bile her türlü otomatik güncelleme özelliğine karşı gelirdim. Ortada bir kütüphane otomatik olarak kendini güncellediğinden dolayı proje kırdığı bir şey üzerinde çalışmam çok üzücü olurdu, ya da birdenbire başka bir şey tarafından değiştirilmiş bir API kullanmaya başladığım için amortisman uyarıları aldım.


2

Sormak zorundasın, güncellemeden gerçekten ne istiyorsun? Güvenlik düzeltmelerinin çoğu aslında sabitleme biçimindeki önemsiz yamalardır:

  • Rasgele kodun bir arabellekte kullanılmayan bir alana kopyalanabildiği bir hata nedeniyle kapalı
  • Sarkan işaretçiler veya tanımsız ancak belirleyici davranışları tetikleyen başka bir şey
  • Bir tür DoS'a izin veren hatalar
  • Yanlışlıkla özel verilerin aranmasını kolaylaştıran hatalar
  • Matematik gafları
  • Yapmaması gereken şeylere dokunan bakıcılar (Debian SSL bug, kimse?)

Son beş yıldaki CVE'lerin çoğuna bakarsanız, bunları düzelten yamalar genellikle oldukça önemsizdir, açık kütüphaneler kullanıyorsanız, umarım öyledir.

Öyleyse, muhtemelen istediğiniz, ancak muhtemelen kendiniz düzelttiniz, gerçek hata düzeltmeleri var. Kırılmazsa, tamir etmeyin.

Sonunda, yeni özelliklere sahipsin .. ve belki de kullanımdan kaldırılmış özelliklere sahipsin. Bu sürüm notlarını incelemelisiniz ve dikkatlice farklılık göstermelisiniz. Diğer pek çok şeyin bağlı olduğu bir API'yi kırsalar bile onları kullanabilir misiniz? Evet ise, ameliyat zamanı. Hayır ise, kiraz istediğiniz şeyi seçin ve devam edin.

Bazıları benimle aynı fikirde olmayabilir, ancak kaynak kodu olmayan bir kütüphaneyi kullanmayı reddediyorum.


Şüphesiz ben açık kaynak kitaplıkları tercih ederim ama ben de bazı ticari kütüphaneler kullandıkları maliyeti böylece kaynağı olmadan 100 $ veya kaynakla $ 10k, ... gibi
Joonas Pulakka

2

Kütüphanelerdeki şeyler, ne için kullanıldığı, kodunuzda ne kadar yaygın oldukları, yükseltmeyi gerçekleştirmenin maliyeti (zaman ve para açısından) gibi şeylere bağlı olarak değişir.

İdeal olarak her zaman en son zamanlara sahip olursunuz, ancak yeni sürüm geriye dönük olarak uyumlu değilse ne olacak? Değişikliği dikkatle ele alana kadar bu güncellemeyi gelecek sürümlerde rafa kaldırmanız gerekebilir. Davranışta bazı ince değişiklikler olabilir (örneğin, "Y yöntemini çağırmadan önce X özelliğini ayarlamanız gerekir veya yavaş bellek sızıntısı alırsınız" gibi), test sırasında doğrulaması zor olabilir.

Öte yandan, yeni sürüm bazı ciddi güvenlik düzeltmelerine sahip olabilir, bu yüzden bunu da hesaba katmalısınız.

Kısa versiyon: duruma göre alın.


1

Bu salıverme shedüllerine bağlı.

Ancak benim tavsiyem, tüm geliştiricilerin makinelerine bir dizi kütüphane kurmaktı. Bir şey olarak adlandırmak istersen altın standart olarak kabul et, sonra bu sürüm için seni geliştirmeye başla.

Yalnızca sürüm dağıtıldıktan ve sürüm sonrası aşamada olduğunuzda, kitaplıklarınızı, sürümlerini ve özelliklerini yeniden değerlendirin. Bazı önemli iyileştirmeler veya yeni işlevsellik sunuyorlarsa, bir sonraki geliştirme döngüsünün başlamasından önce kurun.

Yeni sürümleri yalnızca yazılımı dağıtmadan önce düzeltilmesi gereken önemli bir sorun veya hata varsa kurun.

Bu, bazı sürümleri kaçıracağınız anlamına gelecektir, ancak uygulamanızı geliştirmeye konsantre olmanızı sağlayacak bazı başağrısı ve sürüm oluşturma sorunlarını kurtarması gerekir.


1

Subversion Externals

Bu özelliğin harika yanı, istediğiniz düzeltmeyi belirtebilmenizdir.

Birçok harici ürününüz varsa güncellemelerin daha yavaş olacağını lütfen unutmayın.


Aslında onları kullanıyorum ve çok kullanışlılar ve çok yavaşlar X-) Fakat yeni sürüme ne zaman güncelleme yapmam gerektiğini çözmüyorlar .
Joonas Pulakka

Çok yavaş olabilirler, evet. Genellikle dış kütüphaneleri güncellediğimde: (büyük bir sürüm VEYA beni etkileyen bir hata düzeltmesi mevcut) VE yinelemenin ilk yarısındayım.

1

Şu anda böyle bir şey kuruyorum:

  • Başvurumun her bir uzantısı için 1 adet ticari repo
  • 3. parti kütüphanelerin belirli sürümlerini toplayan mercurial repo
  • Grafik kaynakları / çalışmalar için bir SVN deposu (ancak başka bir şeyle değişebilir)
  • 3. pary repo'nun belirli bir versiyonunu ve bazı temel uzantıların bazılarını kullanmak için merkür alt subpoları özelliğini kullanan uygulamam için ticari bir repo

Şimdi "temel" olmayan bir uzantı üzerinde çalışmam gerektiğinde (uygulama deposuna alt rapor olarak dahil edilmiştir), uzantı klasöründeki repoyu klonladım ve CMake'in tüm uygulama için projeler ve çözümler üretmesine izin verdim.

Bu şekilde yapabilirim:

  • Bir klondaki 3. tarafları değiştirin, uygulamanın çalışıp çalışmadığını kontrol edin, 3. kişi deposuna bastırın, ardından uygulama deposunun alt rapor sürümünü yeni 3. taraf repo sürümüne güncelleyin
  • uzantıları üzerinde bağımsız olarak çalışın, tümü bilen ya da sadece belirli olanları seçin
  • Projeleri birbirine bağlamakla ilgili endişelenmenize gerek yok, bu Cmake tarafından sadece tüm proje repoları ile taranan projeler alt raporları taranarak yapılır.

Bu organizasyonla ilgili henüz çok fazla tecrübem yok, ancak bunun oldukça faydalı olduğunu düşünüyorum.


1

Yazılımınız güvenlik açısından kritikse, en kısa zamanda güncellemelisiniz, mazeret yok. Bir grafik kütüphanesinde küçük bir hatanın bütün programınızın korunmasız kalmasını istemezsiniz.

Aksi takdirde, lib olgunlaştığında, "Eğer kırılmadıysa, düzeltmeyin." benim için. Er ya da geç, daha sonraki bir sürümün bir özelliğine ihtiyacım olabilir ve güncelleme yapmaktan başka çarem kalmayabilir, ancak o zamana kadar bu gayreti haklı çıkarmak zordur. Öte yandan, Grails veya ExtJS gibi nispeten yeni bir lib veya çerçeveyle çalıştığımda, bu ürünler henüz tamamen olgun hissetmediği için en son sürümden haberdar oluyorum, bu yüzden güncelleme beni kurtarıyor. bu hatalardan birine rastlamak daha sonraki sürümlerde düzeltildi.


1

Kullandığım Nuget üçüncü taraf kütüphanelerimi güncel tutmak için .

Bir arkadaşım, iş arkadaşınız veya blog bana üçüncü parti DLL dosyalarımdan birinin güncel olmadığını bildirdiğinde, NuGet güncellemeyi çok kolaylaştırır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.