Непрерывный деплоймент на практике
| October 21, 2011 | Posted by admin under Практики, Статьи |
Автор: Mike Bria
http://www.infoq.com/news/2010/01/continuous-deployment-trenches
Непрерывный деплоймент описывается Ash Maurya как “процесс, по которому программное обеспечение выпускается несколько раз в день: минуты в противовес дням, неделям или месяцам”. Непрерывный деплоймент набирает популярность в движении за уменьшение количества одновременно выполняющейся работы в Lean ” (“eliminate work-in-progess”) . Некоторые считают это увлекательным и логически целесообразным, другие с трудом представляют, как этого можно добиться. Ash Maurya помогает восполнить этот пробел, описывая свой опыт непрерывного деплоймента.
Вот что говорит Maurya насчет того, почему не сработал предыдущий процесс с однонедельным циклом релизов:
Процесс выпуска релиза занимал полдня, а иногда и день. Выделение до 20 процентов времени в неделю на выпуск релиза очень расточительно для маленькой команды. Это не считая усилий по координации, необходимых для приоритезации постоянно меняющегося состава релиза.
Его переход к непрерывному деплойменту начался со статьи Eric Reis 5 step continuous deployment primer. Далее его рассказ посвящен тому, что Maurya считает наиболее сложным аспектом: просто “освоиться с постоянными релизами.”
Мы пошли простым путем – делали небольшие изменения и маниакально проверяли процесс релиза. Я начал полагаться на функциональные тесты (а не на unit тесты), что позволяло мне тестировать изменения так, как это сделал бы сам пользователь. Я определил набор событий, которые могли бы сигнализировать когда что-то идет совсем не так (например, в системе нет пользователей) и создал систему оповещения о них в реальном времени (используя nagios/ganglia). Наша уверенность росла, и мы начали вносить (commit) все бОльшие изменения, состоящие из нескольких частей. Каждый раз мы дополняли набор наших тестов и скриптов для мониторинга системы. После нескольких итераций наш уровень страха стал ниже, чем был на поэтапных (staged) релизах. Поскольку мы вносили меньше кода за релиз, мы могли точнее связывать появление проблем с произошедшей выкладкой.
Maurya описывает следующие принципы/практики непрерывного деплоймента:
- “Вытягивание против выталкивания фичи (features)“: фундаментальная мантра Lean. Позвольте отклику от заказчика “вытянуть” новые фичи в ваше поле зрения.
- “Небольшие куски кода“: для Maurya это означает двухчасовую сессию кодирования (2 hour coding sessions), которая оканчивается коммитом кода (check-in). Это вызывает автоматическую сборку.
- “Предпочитайте функциональные тесты unit тестам, когда это возможно“: Muarya использует Selenium
- “Всегда тестируйте путь активации пользователя (User Activation flow)“: вы должны быть уверены, что “критический путь для удовлетворения пользователя” работает
- “Используйте авто-МАГИЧЕСКИЕ обновления“: пользователи должны иметь возможность получать обновления настолько незаметно, насколько это возможно. Maurya описывает, как он делает это для OSGI-приложения
- “Встраивайте оповещения и мониторинг“: для получения сообщений о любом ненормальном поведении системы Maurya использует nagios и ganglia
- “Встраивайте диагностику уровня приложения“: приложение, которое само может проверять свое состояние и находить вещи, которые люди и тесты не смогли бы обнаружить
- “Допускайте неожиданные ошибки только раз“: найдите время, чтобы понять корневые причины и сделать реальные исправления
Если вы заинтересовались, прочитайте отчет Maurya’s full experience report , который здесь кратко описан.
