Korzystanie z repozytorium Apt dla płatnych aktualizacji oprogramowania

Próbuję ustalić sposób dystrybucji aktualizacji oprogramowania dla aplikacji sieci web obsługiwanej / na stronie, która może mieć cotygodniowe i / lub miesięczne aktualizacje. Nie chcę, aby klienci korzystający z produktu na miejscu musieli martwić się o ręczną aktualizację. Chcę tylko, aby pobierał i instalował automatycznie ala Google Chrome. Planuję dostarczyć plik OVF z Ubuntu oraz zainstalowanym i skonfigurowanym oprogramowaniem.

Moją pierwszą myślą o tym, jak rozpowszechniać oprogramowanie, jest utworzenie sześciu repozytoriów / kanałów Apt (nie jestem pewien, czy w tym momencie byłoby lepiej), do których dostęp będzie możliwy za pośrednictwem SSH za pomocą kluczy, więc jeśli klient nie odnowi subskrypcji, możemy wyłączyć jego konto :

1. Beta - Używany wewnętrznie w danych testowych w celu sprawdzenia pakietu pod kątem poważnych wad.
2. Wewnętrzny - Używany wewnętrznie w danych na żywo w celu sprawdzenia pakietu pod kątem wad (etap karmienia psów).
3. Zewnętrzne 1 - Wdrożone do 1% naszej bazy użytkowników (losowo wybrane) w celu sprawdzenia wad.
4. Zewnętrzne 9 - wdrożone do 9% naszej bazy użytkowników (losowo wybrane) w celu sprawdzenia pod kątem wad.
5. Zewnętrzne 90 - wdrożone dla pozostałych 90% użytkowników.
6. Hostowany - wdrożony w hostowanym środowisku.

Na każdym etapie konieczne będzie wylogowanie się, aby przejść do następnego repozytorium w przypadku zgłoszenia problemów.

Moje pytania do społeczności to:

1. Czy ktoś próbował czegoś takiego wcześniej?
2. Czy ktoś może zobaczyć wadę tego rodzaju procedury?
3. Czy jest lepszy sposób?

Ogólnie podoba mi się to podejście. W żaden sposób nie można przeciwdziałać problemom związanym z piractwem, czy to tradycyjnym, czy zautomatyzowanym, i można uniknąć niedogodności związanych z programem licencjonowania.

Możesz mieć problemy z losowymi wyborami. Czy klient został wybrany na wczesnego nabywcę przez cały okres relacji biznesowych? Jeśli nie, w jaki sposób można dokonać przejścia z zewnętrznego 1 na zewnętrzny 9?

Czy zastanawiałeś się nad ogólnymi licencjami i ochroną typu domowego telefonu dla swojego oprogramowania?

Problem, który tu widzę (bez żadnych licencji), polega na tym, że mogę zapłacić za miesiąc, przestać, a następnie po prostu kontynuować działanie w tej wersji. Pewnie, że jest stary, ale wolny. Luka ta zostanie wykorzystana przez co najmniej kilka osób

Jeśli masz już licencję, po prostu miej proste niezabezpieczone repozytoria z oprogramowaniem wymagającym sprawdzenia licencji przed uruchomieniem

Nie wiem wystarczająco dużo o twoim oprogramowaniu i / lub naturze twoich klientów, ale w wielu miejscach aktualizacje nie są instalowane bez testowania. Wiele firm używa klucza licencyjnego, który przekroczy limit czasu. Pozwól im pobrać aktualizację i zainicjować ręcznie. Automatyczne aktualizacje są wygodne, ale czasami użytkownicy nie lubią niespodzianek.

Spójrz na strukturę Sparkle dla OS X, robi to bardzo podobnie do mechanizmu aktualizacji Chrome, ale zapewnia opinie użytkowników, aby mogli pominąć aktualizację lub zrobić to później. Mam na sobie aktualizacje aplikacji i zmieniam funkcjonalność tak, jak potrzebowałem, zawsze najlepiej przynajmniej zapytać użytkownika.

Podoba mi się trafny pomysł, warto to zrobić w ten sposób, jest to proste i naprawdę, bardzo dobrze przetestowane w tym momencie.

Znam firmę, która robi prawie dokładnie to, co opisałeś. (Mniej poziomów niż opisałeś i nie wiem, jak się uwierzytelniają).

Największym problemem, jaki mieli, było to, że niektórzy klienci blokowali dostęp do Internetu ze swojego urządzenia. Oznacza to, że ci klienci są po prostu zablokowani do zainstalowanej wersji. Może to w porządku. Myślę, że rozmawiali o otwarciu reguł zapory ogniowej z niektórymi z tych klientów. Inne zostały po prostu zaktualizowane ręcznie.

Gdybym to zrobił, zrobiłbym to na podstawie adresu IP. Więc kiedy przychodzą, aby pobrać, ich adres IP musi znajdować się na liście dozwolonych, aby połączyć się z tym serwerem, w przeciwnym razie nie będą mogli pobrać. To jest do bani, jeśli nie mają dedykowanego adresu IP, ale jest mało prawdopodobne z tego, co brzmi jak mówisz, jeśli jest oparty na serwerze, jeśli jest przeznaczony dla stacji roboczych, możesz lepiej skonfigurować je z własnym własnym serwerem apt, a następnie pobrać kopia za pośrednictwem zadania cron lub coś ponad ftp i tak dalej raz w tygodniu, a następnie stacje robocze pobierają stamtąd naprawdę do ciebie.

To dobre, wyrafinowane podejście.

Niektóre pułapki do rozważenia:

• Nie zawsze możesz chcieć iść 1 procent, 9 procent, 90 procent. Twoi klienci mogą nie być jednorodni, co oznacza, że ​​możesz zacząć specjalizować się, powiedzmy, według regionu, typu urządzenia itp., W którym to przypadku dystrybucja o 1, 9, 90 procent na całym świecie nie ma już sensu.

• Posiadanie jednego repozytorium dla 90 procent użytkowników wprowadza hotspotting - ten serwer będzie otrzymywać większość żądań, co oznacza, że ​​jako pierwszy umrze w przypadku gwałtownego ruchu, powodując awarię dla 90 procent użytkowników. Redundancja oczywiście pomaga, ale to ogólnie wiąże się z większymi wydatkami.

• Być może masz przepływ pracy, w którym pewne funkcje są gotowe do dystrybucji do 90 procent wszystkich użytkowników, ale globalna aktualizacja spowoduje, że funkcje nie będą gotowe do przyjęcia w 90 procentach do produkcji, wprowadzając wąskie gardła w twoim obiegu pracy. Stała dystrybucja nie będzie w stanie skutecznie poradzić sobie z tymi problemami, zmuszając Cię do obsługi tego na poziomie aplikacji.

Jednym ze sposobów rozwiązania tego problemu jest przechowywanie wielu kopii repozytoriów produkcyjnych na różnych serwerach, umieszczenie przed nim konfigurowalnego modułu równoważenia obciążenia , a następnie ostrożne aktualizowanie repozytoriów produkcyjnych stopniowo. Innymi słowy, traktuj wszystkie repozytoria jako ostatecznie chcące być takie same, ale skonfiguruj ruch tak, aby odsetek użytkowników czytających z serwera był zmienny.

Korzyścią jest to, że możesz dowolnie konfigurować dystrybucję żądań za pomocą modułu równoważenia obciążenia, możesz lepiej skalować w poziomie (wszystkie twoje serwery mogą zacząć obsługiwać to samo repo proporcjonalnie, jeśli wszystkie funkcje są gotowe do przyjęcia w 100 procentach) oraz, w zależności od tego, w jaki sposób zespół ma obieg pracy i potrzebujesz aktualizacji specyficznych dla regionu, możesz w końcu zezwolić na dostępność niektórych funkcji od razu, nie martwiąc się o inne funkcje.