Как вы подходите к управлению выпусками веб-приложений (SaaS)?

Question

Каков наилучший подход к выпуску новой версии размещенного веб-приложения и как часто вы обычно выпускаете ее?Выбираете ли вы произвольную дату, скажем, каждую неделю, месяц и т. д.выпустить накопленный набор исправлений (возможно, используя подход, аналогичный Подход Джоэла к датам выпуска)?Ожидание гораздо дольше, похоже, сводит на нет часть основного преимущества размещенного приложения.С другой стороны, вы не хотели бы постоянно внедрять новые функции, которые могут сбить пользователя с толку (т. е. если при каждом входе в систему что-то меняется).

До недавнего времени мой опыт был в основном связан с установленными серверными или настольными приложениями.Мне любопытно посмотреть, какой тип управления выпусками люди используют с размещенным приложением.

Answer 1

Подход Google, вероятно, лучший для конечного пользователя, но он достигается ценой сложности.

Они выпускают новые версии (а иногда и отдельные изменения) на довольно постоянной основе (так часто, как ежедневно, в зависимости от проекта). Но вот что важно: только небольшая часть пользователей получает новую версию.

Google имеет большое количество пользователей для своих крупных продуктов, поэтому целесообразно ввести такие правила, как " 5% пользователей должны видеть эту функцию ".

Затем они могут проанализировать результаты и спланировать свой следующий выпуск, возможно, еще для 15% пользователей.

Answer 2

Столько, сколько инженеры хотят определить рутину для жизни, она действительно будет зависеть от требований бизнеса, стоящих за системой. Это также действительно зависит от характера обновлений и т. Д.

Обновления контента и HTML не должны быть серьезной проблемой. Изменения в приложении ДОЛЖНЫ быть серьезными, и перед отправкой вживую необходимо пройти установленные процедуры тестирования на сайте предварительного просмотра.

Одно можно сказать наверняка: вам нужно иметь очень " clean " способ развертывания (и отмены развертывания) изменений. Вам также нужен & Quot; easy & Quot; способ просмотра и аудита изменений, прежде чем они вступят в действие.

Используя сочетание " git " и " rsync " позволяет нам полный контроль над процессом. Все изменения в нашем проекте разрабатываются в ветке, которая была отделена от & Quot; Production & Quot; ветка. Прежде чем какие-либо изменения вступят в силу, & Quot; Production & Quot; ветвь должна быть полностью объединена. Актом запуска является просто объединение соответствующей ветки в " Production " и rsyncing его на живых серверах. Git делает это действительно легко.

Это гарантирует, что вступающие в силу изменения не могут конфликтовать с другими изменениями в процессе.

С момента внедрения этой системы наша процедура развертывания значительно увеличилась в эффективности и ясности. И, кстати, наши развертывания варьируются от нескольких раз в день до одного раза в несколько месяцев. Все это зависит. Я бы предпочел цикл 1-2 релиза в неделю для активного проекта.

Answer 3

Выпуск рано и часто - это то, что я делаю, и что мы делаем, где работаем Мы также ведем блог о наших обновлениях всякий раз, когда мы делаем их. Возможно, вам будет проще, если вы свернете все свои обновления в одно обновление за раз (для контроля качества, необходимости отката и т. Д.) Как можно лучше. С точки зрения пользователя, я не думаю, что есть много проблем с большим количеством обновлений. Пока они не плохие обновления. Я думаю, что есть проблема, если вы подождете целый год или шесть месяцев и свернете все свои обновления в один большой выпуск. Это то, что убило проект, над которым я работал (популярный читатель, о котором вы, наверное, слышали). Люди думали, что мы мертвы, и восприятие стало реальностью. Мы заброшены. Так что я полностью за график выпуска пожарных рукавов.

Answer 4

Каждых двух недель должно быть достаточно, но это очень сильно зависит от вашего рынка.

Answer 5

В Planbox (SaaS-версия гибкого управления проектами) мы выпускаем новые версии каждый день.Мы можем это сделать, потому что большая часть логики нашего приложения и вся логика представления находятся во внешнем интерфейсе (Javascript).Даже HTML генерируется с помощью Javascript с использованием механизма шаблонов.Но серверная часть (PHP) и ее REST API редко меняются.Это позволяет нам выпускать новые версии клиента в любое время, не нарушая совместимости.

Если вы сможете перейти на такую ​​архитектуру, вы сэкономите массу времени и повысите эффективность.