Нещодавно в мене відбулося обговорення з колегою з приводу версій веб-додатків.
Я не думаю, що вам це взагалі не потрібно, і якщо ви просто хочете перевірити обґрунтованість, щоб підтвердити, що ваш останній реліз вийшов у прямому ефірі, я думаю, що побачення (YYMMDD), ймовірно, є досить хорошим.
Я не в базі? Я пропускаю точку? Чи слід використовувати номери версій веб-додатків
Відповіді:
Якщо ви перепродаєте одну і ту ж веб-програму для кількох клієнтів, ви абсолютно повинні її версії.
Якщо це веб-сайт, який коли-небудь встановлюється лише в одному місці, то потреба є менш гострою, але все-таки вона не може зашкодити. Ви були б менш сприйнятливі до проблем із часовим поясом і до того ж. Діагностувати проблему у бібліотечній версії 1.0.2.25 набагато приємніше, ніж вишукувати збірку бібліотеки 3 листопада 2010 р. 11:15
Якщо ви можете автоматизувати номер версії на DLL-файлах програми, це не може зашкодити. Це допоможе вам відслідковувати версії.
Як правило, веб-додатки випускаються лише в одному місці, де ви розміщуєте його, тому це не так важливо, як, наприклад, настільний додаток. Це може допомогти з відкатами, відстеженням помилок (тобто, у якій версії це було) та відстеженням різниці між розробниками, постановочними та виробничими серверами, якщо це застосовно.
Я б розібрався в автоматизації цього - це та річ, яку ви можете налаштувати один раз і використовувати її, якщо / коли вам це потрібно.
Ваші користувачі не цікавляться номерами версій, так як вони завжди мають найновіший і найкращий випуск, але ви зобов'язані самі (та ваша команда) знати, яка версія працює в прямому ефірі. Врешті-решт джерело вашої розробки синхронізується з прямим кодом, і тоді ви обов'язково повинні знати. Тож позначте свої випуски у своєму svn / git дереві та позначте веб-додаток цим тегом.
На додаток до того, що сказали інші, я додам, що версія також важлива з маркетингової точки зору. Нова версія - це щось нове, яке можна продати потенційним або існуючим клієнтам. Це дозволяє клієнтам знати, що щось є «нове» і бачити, що все рухається вперед. Він забезпечує приємне групування нових функцій. І це виглядає більш професійно.
Я кажу, що для будь-якого іншого, окрім тривіального веб-додатка, слід його оновлювати. Тут є два, трохи різні поняття:
Незалежно від ситуації, я вважаю, що файли повинні мати індивідуальні номери версій (або версій). В ідеалі, це дозволило б управляти системою управління версіями. Як заявили інші, простіше посилатися на номер версії файлу, ніж його дата та час.
Якщо у вас (або можливо, у вас) більше однієї інстальованої програми, вона повинна бути розроблена в цілому. Це також є хорошою практикою, якщо у вас є окремі середовища для розробки та тестування (як ви, мабуть, повинні). Кожен номер версії програми (або випуску) відноситься до колекції окремих файлів за певними номерами версій. Хоча вирішення всього цього є додатковим тягарем, легше перевірити конкретний випуск, ніж окремі файли за певними номерами ревізії.
Це змушує мене думати про поняття в лінгвістиці. Кажуть, що якщо ти не можеш щось виразити мовою, ти не можеш думати про це (цією мовою). Я думаю про німецьке слово "Schadenfreude". Набагато простіше думати (і говорити) про це поняття «відчувати радість через чуже нещастя», посилаючись на це слово, ніж на його визначення. Саме тому слово прокралося до вживання в англійській мові.
Аналогічно, номери версій полегшують говорити (і думати) про вашу програму та її файли в конкретних станах. Якщо ви одна особа, яка працює над однією програмою, це, ймовірно, не має великого значення. Однак, оскільки справи ускладнюються, вам краще мати ці етикетки для використання.
Вам слід версії веб-програми з ідентифікатором збірки на сервері збирання та мати цей ідентифікатор, включений у всі звіти про помилки.
Це дозволить вам піти назад у часі, якщо вам доведеться виправити помилку, повідомлену про старішу версію, яка наразі не присутня у виробництві.
З вашого запитання видно, що ви маєте на увазі простий веб-додаток
Доступний лише через веб-інтерфейс, а не через веб-API . Якщо у вас є користувачі, які звертаються до програми за допомогою API, вам потрібно її версію. Якщо ви зміните API, ви зламаєте клієнтів, тому вам потрібно одночасно підтримувати іншу версію API.
У той час працює лише один екземпляр . Навіть якщо у вас є лише хлопець в Інтернеті, якщо у вас більше встановлення, ви повинні знати, який клієнт працює в якій версії.
З прийнятним простоєм для оновлення живої версії. Можливо, існує величезна проблема - база даних . Важливі зміни з новішими версіями відбуваються із змінами основної структури даних. Якщо на той час працює лише одна версія, можливо, вам доведеться вимкнути стару версію, оновити базу даних і ввімкнути нову версію. Це призводить до простою програми. Це може бути прийнятним залежно від кількості та виду користувачів.
У нас є лише колишній, тому використовуйте лише номер версії для перевірки поваги після випуску повідомлення. Нам не потрібно одночасно відслідковувати багато використовуваних версій.
Якщо ваша веб-програма складається з декількох модулів, як в клієнтському, так і в серверному, кожен модуль повинен бути виконаний у версії. І кожній комбінації версій модулів як для клієнта, так і для сервера повинен бути наданий унікальний ідентифікатор, ідентифікатор, який повинен бути присутнім у всіх журналах реєстрації та повідомлення про помилки.
Використовуючи цю конвенцію, завжди можна буде відтворити стан, у якому веб-додаток знаходився в даний момент.
На мою думку, оскільки веб-сайти в наші дні побудовані з використанням динамічних мов з обох сторін, сервера та клієнта, не повинно бути жодних причин для перезавантаження оновленого веб-додатка, якщо користувач не перезапустить веб-переглядач або перезавантажить сторінку вручну.
Тільки оновлені частини або модулі у веб-додатку повинні бути перезавантажені, не впливаючи на загальний стан програми.
Чому ви можете запитати? Що ж, застосовуючи це, веб-додаток за своєю конструкцією буде більш надійним, правильним та, ймовірно, простішим у обслуговуванні. Якщо веб-додаток завжди вимагає одночасного оновлення сервера / клієнта, він, ймовірно, не будує правильний шлях.
Так, ви повинні його версію! І у вашій системі контролю версій повинен бути тег (наприклад, субверсія, git, mercurial тощо), який відповідає номеру версії.
Тег дозволяє повернутися назад і зробити гілку. Наприклад: у поточній виробничій версії є помилка, але ви не можете її виправити, оскільки код на вашій машині просто не готовий виконувати двері. Якщо у вас є тег у вашому RCS, ви можете розгалужити цей тег і виправити помилку в точній версії коду, який працює у виробництві.
Особисто я вважаю, що ви все одно повинні мати версію, але одна велика перевага веб-додатків для версій, характерних для веб-сайтів, - це те, що вони можуть значно змінити статичний вміст.
Наприклад, скажімо, у вас є файл mysite.css, який має далеко майбутній термін придатності (який, як правило, ви хочете зробити так, щоб він був кешований у браузері на кожній сторінці). Якщо потім змінити стиль у цьому файлі, ніхто, хто раніше був на вашому сайті, не збирається його бачити, якщо вони не роблять щось, щоб очистити цей файл із свого кешу.
Якщо ви розміщуєте сайт, хоч ви могли змінити всі посилання на css у вашій збірці на щось на зразок mysite.css? V = 1234, що дозволить вам зберігати дату майбутнього терміну придатності та не турбуватися про майбутні зміни, як у наступній збірці Буду mysite.css? v = 1235.
Так, слід. З причин розповсюдження, вказаних тут іншими відповідями.
Але я бачу, чому ви ставите це питання. Підхід до веб-додатків залежить від витрат. Протилежний до застарілого підходу, де витрати включають фізичні носії, розповсюдження, встановлення, копію документації, навчання та технічну підтримку. Все, що можна виключити, повинно бути виключено.
Щоб було зрозуміло, я припускаю, що ви говорите про якийсь видимий користувачеві номер версії, і не відмовляєтесь від контролю версій у розробці. (якщо ви думаєте, що вам не потрібен контроль над версіями в розробці, то ви помиляєтеся, вам потрібен контроль версій).
Для одного розміщеного проекту це не обов'язково, тому що якщо виникають запитання, ви завжди можете подивитися на хоста і підтвердити, що насправді працює. Це все-таки приємно, адже це може стати в нагоді один-два рази. Ви справді залежать від того, чи вважаєте ви це корисним чи ні.
Для проектів з декількома розмірами це насправді необов’язково. Різні хости в кінцевому підсумку виявляться з різними версіями, і вам потрібно буде мати змогу розпізнати їх у користувачів.