Niedawno rozmawiałem ze współpracownikiem o wersjonowaniu aplikacji internetowych.
Nie sądzę, żebyś go w ogóle potrzebował, a jeśli chcesz tylko sprawdzić poprawność psychiczną, aby potwierdzić, że twoje najnowsze wydanie jest na żywo, myślę, że data (RRMMDD) jest prawdopodobnie wystarczająca.
Czy jestem poza bazą? Czy brakuje mi sensu? Czy powinienem używać numerów wersji aplikacji internetowej?
Odpowiedzi:
Jeśli odsprzedajesz tę samą aplikację sieciową wielu klientom, absolutnie powinieneś ją zaktualizować.
Jeśli jest to witryna internetowa, która kiedykolwiek była instalowana tylko w jednym miejscu, potrzeba jest mniej poważna, ale prawdopodobnie nie zaszkodzi. Będziesz mniej podatny na problemy związane ze strefą czasową i tym podobne. Diagnozowanie problemu w wersji biblioteki 1.0.2.25 jest o wiele ładniejsze niż polowanie na kompilację biblioteki 3 listopada 2010 11:15
Jeśli możesz zautomatyzować numer wersji w bibliotekach DLL aplikacji, nie zaszkodzi. Pomoże ci to śledzić wersje.
Zasadniczo aplikacje internetowe są wydawane tylko w jednym miejscu, w którym je hostujesz, więc nie jest to tak ważne, jak powiedzmy aplikacja komputerowa. Może pomóc w wycofywaniu, śledzeniu błędów (tj. W której wersji była ta wersja) i śledzeniu różnicy między serwerami programistycznymi, pomostowymi i produkcyjnymi, jeśli dotyczy.
Chciałbym zautomatyzować to - jest to rodzaj rzeczy, którą możesz skonfigurować raz i użyć, jeśli / kiedy będziesz jej potrzebować.
Twoi użytkownicy nie dbają o numery wersji, ponieważ i tak zawsze mają najnowszą i najlepszą wersję, ale jesteś winien sobie (i zespołowi), aby dokładnie wiedzieć, która wersja działa na żywo. W końcu twoje źródło programowania nie synchronizuje się z kodem na żywo i wtedy zdecydowanie musisz wiedzieć. Oznacz więc swoje wydania w drzewie svn / git i oznacz aplikację internetową tym znacznikiem.
Oprócz tego, co powiedzieli inni, dodam, że przechowywanie wersji jest również ważne z marketingowego punktu widzenia. Nowa wersja jest czymś nowym, co może być sprzedawane potencjalnym lub obecnym klientom. Dzięki temu klienci wiedzą, że coś jest „nowe” i widzą, że wszystko idzie do przodu. Zapewnia ładne grupowanie nowych funkcji. I wygląda bardziej profesjonalnie.
Mówię, że w przypadku niczego poza trywialną aplikacją internetową należy ją zaktualizować. Działają tu dwa, nieco odmienne pojęcia:
Niezależnie od sytuacji uważam, że pliki powinny mieć indywidualne numery wersji (lub wersji). Idealnie byłoby to obsługiwane automatycznie przez system kontroli wersji. Jak stwierdzili inni, łatwiej jest odwoływać się do numeru wersji pliku niż do jego daty i godziny.
Jeśli masz (lub możesz mieć) więcej niż jedną instalację aplikacji na żywo, powinna być wersjonowana jako całość. Jest to również dobra praktyka, jeśli masz oddzielne środowiska programistyczne i testowe (jak prawdopodobnie powinieneś). Każdy numer wersji aplikacji (lub wydania) odnosi się do zbioru pojedynczych plików o określonych numerach wersji. Chociaż radzenie sobie z tym wszystkim stanowi dodatkowe obciążenie, łatwiej jest sprawdzić konkretną wersję niż poszczególne pliki o określonych numerach wersji.
To przywodzi mi na myśl językoznawstwo. Mówi się, że jeśli nie możesz wyrazić czegoś w języku, nie możesz o tym myśleć (w tym języku). Myślę o niemieckim słowie „Schadenfreude”. O wiele łatwiej jest pomyśleć (i mówić) o pojęciu „odczuwania radości z powodu nieszczęścia innej osoby”, odwołując się do tego słowa, niż do jego definicji. To jest powód, dla którego słowo wkradło się w języku angielskim.
Podobnie numery wersji ułatwiają mówienie (i myślenie) o aplikacji i jej plikach w określonych stanach. Jeśli jesteś zespołem jednoosobowym, pracującym nad jedną aplikacją, prawdopodobnie nie ma to wielkiej różnicy. Ponieważ jednak sprawy stają się bardziej skomplikowane, lepiej jest mieć te etykiety dostępne do użycia.
Powinieneś zaktualizować swoją aplikację internetową z identyfikatorem kompilacji z serwera kompilacji i mieć ten identyfikator dołączony do wszystkich raportów błędów.
Pozwoli ci to cofnąć się w czasie na wypadek, gdybyś musiał naprawić błąd zgłoszony w starszej wersji, która nie jest obecnie produkowana.
Z twojego pytania jasno wynika, że masz na myśli prostą aplikację internetową
Dostępne tylko przez interfejs GUI sieci, a nie przez interfejs API sieci (usługi) . Jeśli masz użytkowników uzyskujących dostęp do aplikacji za pomocą interfejsu API, musisz go zaktualizować. Jeśli zmienisz interfejs API, zepsujesz klientów, więc musisz zachować inną wersję interfejsu API w tym samym czasie.
W tej chwili działa tylko jedna instancja . Nawet jeśli masz tylko gościa internetowego, jeśli masz więcej instalacji, musisz wiedzieć, który klient uruchamia daną wersję.
Z dopuszczalnym czasem przestoju na aktualizację wersji na żywo. Prawdopodobnie ogromny problem to baza danych . Ważne zmiany w nowszych wersjach wynikają ze zmian w podstawowej strukturze danych. Jeśli w tym czasie działa tylko jedna wersja, prawdopodobnie będziesz musiał wyłączyć starą wersję, zaktualizować bazę danych i włączyć nową wersję. Co powoduje przestoje aplikacji. Można to zaakceptować w zależności od liczby i rodzaju użytkowników.
Jeśli twoja aplikacja internetowa składa się z wielu modułów, zarówno na kliencie, jak i na serwerze, każdy moduł powinien być wersjonowany. Każda kombinacja wersji modułów zarówno na kliencie, jak i serwerze powinna mieć unikalny identyfikator, który powinien być obecny we wszystkich komunikatach o logowaniu i błędach.
Korzystając z tej konwencji, zawsze będzie możliwe odtworzenie stanu, w jakim znajdowała się aplikacja internetowa w danym momencie.
Moim zdaniem, ponieważ obecnie aplikacje internetowe są tworzone przy użyciu dynamicznych języków po obu stronach, po stronie serwera i klienta, nie powinno być żadnego powodu do przeładowywania zaktualizowanej aplikacji internetowej, chyba że użytkownik uruchomi ponownie przeglądarkę lub ręcznie przeładuje stronę.
Tylko zaktualizowane części lub moduły w aplikacji internetowej powinny zostać ponownie załadowane bez wpływu na ogólny stan aplikacji.
Dlaczego możesz zapytać Cóż, wymuszając to, aplikacja internetowa będzie z założenia bardziej solidna, poprawna i prawdopodobnie łatwiejsza w utrzymaniu. Jeśli aplikacja internetowa zawsze wymaga jednoczesnej aktualizacji serwera / klienta, prawdopodobnie nie jest budowana we właściwy sposób.
Tak, powinieneś go zaktualizować! W systemie kontroli wersji powinien znajdować się znacznik (taki jak subversion, git, mercurial itp.), Który pasuje do numeru wersji.
Tag pozwala ci wrócić i zrobić gałąź. Na przykład: obecna wersja produkcyjna ma błąd, ale nie można go naprawić, ponieważ kod na komputerze po prostu nie jest gotowy do uruchomienia. Jeśli jednak masz go otagowany w swoim RCS, możesz rozgałęzić się pod tym tagiem i naprawić błąd w dokładnej wersji kodu uruchomionego w produkcji.
Osobiście uważam, że i tak powinieneś dokonywać wersji, ale jedną wielką zaletą tworzenia wersji aplikacji sieciowych, która jest specyficzna dla stron internetowych, jest to, że może znacznie łatwiej zarządzać zmianami w treści statycznej.
Załóżmy na przykład, że masz plik mysite.css, który ma daleką przyszłą datę ważności (co na ogół chcesz zrobić, aby był buforowany w przeglądarce na każdej stronie). Jeśli następnie zmienisz styl w tym pliku, nikt, kto był na Twojej stronie, nie zobaczy go, chyba że zrobi coś, aby usunąć ten plik z pamięci podręcznej.
Jeśli przechodzisz wersję swojej witryny, możesz zmienić wszystkie odwołania css w swojej kompilacji na coś takiego jak mysite.css? V = 1234, co pozwoli ci zachować datę ważności w dalekiej przyszłości i nie martwić się o przyszłe zmiany, jak w następnej kompilacji „mysite.css? v = 1235.
Tak, powinieneś. Z przyczyn dystrybucyjnych wskazanych tutaj przez inne odpowiedzi.
Ale rozumiem, dlaczego zadajesz pytanie. Podejście do aplikacji internetowych zależy od kosztów. Jest to przeciwieństwo tradycyjnego podejścia do obkurczania, w którym koszty obejmują nośniki fizyczne, dystrybucję, instalację, wydruk dokumentacji, szkolenie i wsparcie techniczne. Wszystko, co można wykluczyć, należy wykluczyć.
Żeby było jasne, zakładam, że mówisz o widocznym dla użytkownika numerze wersji i nie rezygnujesz z kontroli wersji w fazie rozwoju. (jeśli uważasz, że nie potrzebujesz kontroli wersji podczas programowania, to się mylisz, potrzebujesz kontroli wersji).
W przypadku projektu z jednym hostem nie jest to absolutnie konieczne, ponieważ jeśli pojawią się jakiekolwiek pytania, zawsze możesz spojrzeć na hosta i potwierdzić, co naprawdę działa. Jest to jednak miłe, ponieważ może się przydać raz lub dwa razy. To naprawdę zależy od Ciebie, czy uważasz, że będzie to przydatne, czy nie.
W przypadku projektu z wieloma hostami nie jest to tak naprawdę opcjonalne. Różne hosty ostatecznie będą miały różne wersje i będziesz musiał być w stanie odróżnić je na końcu użytkownika.