Участвуя в разработке высоконагруженной системы, разработчики сталкиваются со множеством интересных задач, неактуальных для небольших проектов. К примеру, имея большое количество активных пользователей, не все могут позволить себе приостановить работу системы на время релиза новой версии, что делает жизнь разработчиков гораздо увлекательнее даже в относительно простых проектах. А что если система состоит из большого набора веб-приложений, сервисов, постоянно взаимодействующих друг с другом, имеет публичный API, и т.д.? В докладе Виктор покажет, как можно обновить приложение незаметно для пользователей, определит основные факторы, которые могут помешать релизу без остановки приложения, а также даст практические советы по реализации.
4. Доступность системы
Downtime – метрика, которая определяет
период, в течение которого система не
выполняет свои основные функции
Uptime – метрика, которая определяет
период, в течение которого система
доступна и выполняет свои функции.
4
20. Обновляйтесь в период
минимальной нагрузки
20
Меньше пользователей могут заметить нестабильность в работе
системы и проблемы, в случае из возникновения.
21. Основной сценарий и запасной
план
21
Список всех необходимых работ, последовательность их
выполнения, план на случай наступления риска, и т.д.
Определите необходимые ресурсы и назначьте менеджера
релиза.
25. Начните думать о своём коде с
точки зрения релиза
25
Как вы собираетесь это релизить? Установите очередность,
определите, что требуется для обновления (обновить код, базу,
и т.д.)
26. Одна задача — один
компонент
26
Разбейте систему на компоненты, которые можно релизить
независимо — single deployable.
29. Особенности релиза
- Одно основное веб-приложение и
множество неосновных компонентов
- Каждые 2 недели
- Утро субботы
- Практика пилотного релиза
- 1 неделя после релиза – мониторинг
- Приостановка некоторых компонентов на
период обновления системы
29
30. Особенности релиза
- Используется собственное решение для
развертывания новой версии
- Процесс обновления максимально
автоматизирован
- Процесс тестирования конфигурации
автоматизирован
- Балансировка нагрузки и несколько
копий каждого веб-приложения
30
31. Упрощённая схема релиза
31
1
Обновление БД до
обновления
приложения
Обновление всех сервисов и
компонентов, кроме
основного приложения
Обновление основного
приложения для пилотных
пользователей
Обновление основного
приложения для пилотных
пользователей
Обновление БД
после обновления
приложения
2 3 4 5
День релиза
1 неделя
до релиза
1 неделя
после релиза
Развертывание новых
компонентов
Изменения
данных по
запросу
1 Часть релиза
Не включено в релиз
33. Выводы
- Релиз крупного веб-приложения — это
всегда интересная инженерная задача
- Сложно, но возможно!
- Семь раз отмерь — один раз отправь в
релиз
- Результат оправдывает издержки
33