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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Одна вещь наверняка состоит в том, что вам нужен очень "чистый" способ развертывания (и отмены развертывания) изменений. Вам также нужен «простой» способ проверки и аудита изменений до их запуска.

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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