Ücretli Yazılım Güncellemeleri için Uygun Bir Depo Kullanma


9

Haftalık ve / veya aylık güncellemeleri olabilecek barındırılan / yerinde bir web uygulaması için yazılım güncelleştirmelerini dağıtmanın bir yolunu belirlemeye çalışıyorum. Yerinde ürünü kullanan müşterilerin manuel olarak güncelleme konusunda endişelenmelerini istemiyorum Sadece Google Chrome'u otomatik olarak indirip yüklemelerini istiyorum. Ubuntu ve kurulu ve yapılandırılmış bir yazılımla OVF dosyası sağlamayı planlıyorum.

Yazılımın nasıl dağıtılacağına dair ilk düşüncem, anahtarlar kullanılarak SSH üzerinden erişilecek altı Apt deposu / kanalı oluşturmaktır (bu noktada hangisinin daha iyi olacağından emin değilim), böylece bir müşteri aboneliğini yenilemezse hesaplarını devre dışı bırakabiliriz :

  1. Beta - Paketi büyük kusurlar açısından kontrol etmek için dahili olarak test verilerinde kullanılır.
  2. Dahili - Pakette kusur olup olmadığını kontrol etmek için canlı verilerde dahili olarak kullanılır (köpek maması aşaması).
  3. Harici 1 - Hataları kontrol etmek için kullanıcı tabanımızın% 1'ine (rastgele seçilmiş) dağıtılır.
  4. Harici 9 - Hataları kontrol etmek için kullanıcı tabanımızın% 9'una (rastgele seçilmiş) dağıtıldı.
  5. Harici 90 - Kullanıcıların kalan% 90'ına dağıtıldı.
  6. Barındırılan - Barındırılan ortama dağıtılır.

Sorunların bildirilmesi durumunda her bir aşamada bir sonraki veri havuzuna geçmek için bir işaret kapanacaktır.

Topluluğa sorularım:

  1. Daha önce böyle bir şey deneyen var mı?
  2. Herkes bu tür bir prosedürün bir dezavantajı görebiliyor mu?
  3. Daha iyi bir yol var mı?

3
Sadece merak ediyor, ancak birisinin deponuzdan güncellemeyi indirmesini ve ardından P2P ağları üzerinden yeniden yayınlamasını neyin durduracak? Ayrıca müşterilerinizin depolarınızı sources.list dosyasına eklemelerini isteyecek olursanız, kendi güvenlikleri için Apt-Pinning'den bahsetmek isteyebileceğinizi de unutmayın. Aksi takdirde biri repo'nuza kötü amaçlı bir libc ekleyebilir ve müşterileriniz otomatik olarak güncelleyebilir.
Jeff Welling

Yanıtlar:


1

Genel olarak, yaklaşımı seviyorum. Korsanlıkla ilgili sorunlar, ister geleneksel dağıtım üzerinden isterse otomatik olsun, yine de karşılanamaz ve bir lisanslama düzeninin rahatsızlığından kaçınabilirsiniz.

Rasgele seçimlerle ilgili sorunlar yaşayabilirsiniz. Bir müşteri iş ilişkinizin tüm süresi boyunca erken benimseyen olarak mı seçildi? Değilse, harici 1'den harici 9'a nasıl bir düşüş gerçekleştirilebilir?


Benim planım her ay rastgele bir seçim yapmaktı ve dış 1 grupta bir dönem olsaydınız, birkaç dönem için grup dışındaydınız.
Scott Keck-Warren

Hangi kullanıcının hangi yükseltmeye sahip olduğunu ve kimin düzeltilmesi gerektiğini tahmin edemediğinden, bununla ilgili sorunlarla karşılaşabilirsiniz. Diyelim ki harici 1'de bir hata var ve bir kullanıcı harici 1'den düştü, düzeltmeyi harici 90'a kadar itmeniz gerekiyor. Belki de sadece erken benimseyen olmak isteyen müşterilere sorabilirsiniz?
thiton

0

Yazılımınız için genel lisanslama ve ev tipi telefon koruması hakkında düşündünüz mü?

Burada gördüğüm sorun (herhangi bir lisans olmadan) bir ay boyunca ödeme yapabilir, durdurabilir, sonra sadece bu sürümde çalışmaya devam edebilirim. Tabii eski, ama özgür. Bu boşluk en azından bazı insanlar tarafından kullanılacaktır

Zaten lisansınız varsa, çalıştırmadan önce lisansı kontrol etmenizi gerektiren yazılımla basit korumasız depolara sahip olmanız yeterlidir


2
Geri dönüşünüz için teşekkür ederiz. İnsanların bunu kullanmasını sağlamak için acıyı azaltmak için planım, yazılımın 30 gün boyunca tam özellik modunda çalışmasını sağlamak, daha sonra müşterinin "sakat bırakılmış" "modu. O zamandan sonra ürün için ödemeyi durdurmayı seçerse ve güncellemeleri veya harika teknik desteğimizi alamazlar. :-)
Scott Keck-Warren

@TheLQ: Bunu bir sorun olarak görmüyorum: Depolara erişiminiz zaten sizin için ödediğiniz şey. Ödemeyi durdurursanız, güvenlik sorunlarını ve hatalarını gideren veya özellik ekleyen güncellemeler almazsınız. Bu bana çok aklı başında bir iş modeli gibi geliyor.
greyfade

0

Yazılımınız ve / veya müşterilerinizin doğası hakkında yeterince bilgim yok, ancak birçok yerde güncellemeler test edilmeden yüklenmiyor. Birçok şirket zaman aşımına uğrayan bir lisans anahtarı kullanır. Güncellemeyi indirmelerine ve manuel olarak başlatmalarına izin verin. Otomatik güncellemeler uygundur, ancak bazen kullanıcılar sürprizlerden hoşlanmaz.


0

OS X için Sparkle çerçevesine bir göz atın, Chrome güncelleme mekanizmasına çok benzer bir şey yapar, ancak güncellemeyi atlayabilmeleri veya daha sonra yapabilmeleri için kullanıcı geri bildirimleri sağlar. Bana uygulamalar güncelleme vardı ve en azından kullanıcıya sormak her zaman en iyisi olduğu gibi gerekli işlevselliği değiştirmek.

Apt fikrini seviyorum, bu şekilde yapmak mantıklı, bu noktada basit ve gerçekten, gerçekten iyi test edilmiş.


0

Neredeyse tam olarak tanımladığınız şeyi yapan bir şirket biliyorum. (Tanımladığınızdan daha az katman var ve nasıl doğrulandıklarını bilmiyorum.)

Sahip oldukları en büyük sorun, bazı müşterilerin cihazlarından internet erişimini engellemesidir. Bu, müşterilerin yalnızca yükledikleri sürüme kilitlendikleri anlamına gelir. Belki bu iyi. Bence bazı müşterilerle güvenlik duvarı kuralları açmayı tartıştılar. Diğerleri manuel olarak yeni sürüme geçirildi.


0

Yapacak olsaydım IP adresine göre yapardım. Bu yüzden indirmeye geldiklerinde ip adreslerinin bu sunucuya bağlanmak için izin verilenler listesinde olması gerekir, aksi takdirde indiremezler. Eğer özel ipleri yoksa ama iş istasyonları için ise sunucu tabanlı ise konuştuğunuz gibi görünmüyor gibi berbat, o zaman orada kendi apt sunucusu inhouse ve sonra bu indirme ile kurmak daha iyi olabilir haftada bir kez cron işi ya da ftp üzerinde bir şey üzerinden bir kopya ve orada iş istasyonları gerçekten size kadar indir.


0

Bu iyi tecrübeli bir yaklaşımdır.

Dikkate alınması gereken bazı tuzaklar:

  • Her zaman yüzde 1, yüzde 9, yüzde 90 gitmek istemeyebilirsiniz. Müşterileriniz homojen olmayabilir, yani bölgelere, cihaz türüne vb. Göre uzmanlaşmaya başlamak isteyebilirsiniz, bu durumda küresel olarak yüzde 1, 9, 90 oranında bir dağıtım artık mantıklı değildir.

  • Kullanıcılarınızın yüzde 90'ı için tek bir depoya sahip olmak etkin nokta tanıtır - bu sunucu isteklerin çoğunu yaşayacaktır, bu da trafik dalgalanması durumunda ilk ölecek ve kullanıcılarınızın yüzde 90'ı için bir kesintiye neden olacaktır. Artıklık elbette yardımcı olur, ancak bu genel olarak daha fazla masraf getirir.

  • Belirli özelliklerin tüm kullanıcıların yüzde 90'ına dağıtılmaya hazır olduğu bir iş akışınız olabilir, ancak genel bir güncelleme, yüzde 90'lık benimsenmeye hazır olmayan özelliklerin üretime çarpmasına neden olarak geliştirici iş akışınızda darboğazlara neden olur. Sabit bir dağıtım bu sorunları etkili bir şekilde ele alamayacak ve sizi uygulama düzeyinde ele almaya zorlayacaktır.

Bunu düzeltmenin bir yolu, üretim depolarının birden çok kopyasını farklı sunucularda tutmak , önüne yapılandırılabilir bir yük dengeleyici yerleştirmek ve daha sonra üretim depolarınızı sürekli olarak sürekli olarak güncellemektir. Başka bir deyişle, tüm depoları eninde sonunda aynı olmasını isteyin, ancak trafiği bir sunucudan okuyan kullanıcıların yüzdesi değiştirilebilir olacak şekilde yapılandırın.

Bunun faydası, yük dengeleyicinizi kullanarak isteklerin dağıtımını yapılandırabilmenizdir, yatay olarak daha iyi ölçeklendirebilirsiniz (tüm özellikler yüzde 100 benimsenmeye hazırsa tüm sunucularınız orantılı olarak aynı repo'yu sunmaya başlayabilir) ve ekibin iş akışı ve bölgeye özgü güncelleme gereksiniminiz varsa, sonunda diğer özelliklerden endişe etmeden belirli özelliklerin hemen kullanılabilir olmasına izin verebilirsiniz.

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.