Помогите мне улучшить рабочий процесс непрерывного развертывания - PullRequest
36 голосов
/ 13 сентября 2010

Я разрабатывал рабочий процесс для отработки в основном автоматизированного цикла непрерывного развертывания для проекта PHP. Я хотел бы получить некоторые отзывы о возможных технологических или технических узких местах в этом рабочем процессе. , предложения по улучшению и идеи о том, как лучше автоматизировать и повысить удобство использования для моей команды.


Основные компоненты :

  • Hudson CI сервер
  • Git и GitHub
  • PHPUnit модульные тесты
  • Selenium RC
  • Sauce OnDemand для автоматизированного кросс-браузерного облачного тестирования с Selenium RC
  • Puppet для автоматизации развертываний тестового сервера
  • Gerrit для просмотра кода Git
  • Gerrit Trigger для Hudson

РЕДАКТИРОВАТЬ : я изменил графику рабочего процесса, чтобы учесть вклад ircmaxwell путем: удаления расширения PHPUnit для Selenium RC и запуска этих тестов только как часть этапа контроля качества; добавление этапа контроля качества; перемещение тестирования пользовательского интерфейса после проверки кода, но до слияния; перемещение слияния после этапа контроля качества; перемещение развертывания после слияния.

Этот график рабочего процесса описывает процесс. Мои вопросы / мысли / проблемы следуют.

Continuous Deployment Workflow

Мои проблемы / мысли / вопросы :

  • Общая сложность использования этой системы.

  • Время вовлечения.

  • Трудность с использованием Gerrit.

  • Трудность с использованием Puppet.

  • Мы будем развертывать Amazon EC2 экземпляров позже. Если мы собираемся сейчас настроить Debian пакеты с Puppet и развернуть их на Linode, есть ли вероятность, что рабочее развертывание на Linode может сломаться на EC2? Должны ли мы вместо этого делать наши сборки и развертывания на EC2 с самого начала?

  • Еще один вопрос: EC2 и Puppet. Мы также рассматриваем возможность использования Scalr в качестве решения. Будет ли так много смысла избегать накладных расходов на Puppet для одного этого и инвестировать в Scalr? У меня есть второстепенное (ха!) Беспокойство здесь о стоимости; Selenium тесты не должны запускаться , что часто, что EC2 экземпляры сборки будут работать 24/7, но за что-то вроде пятиминутной сборки, платя за час использования EC2 кажется немного большим.

  • Возможные узкие места процесса при слияниях.

  • Можно ли переместить "A"?

Кредиты : Части этого рабочего процесса вдохновлены потрясающим постом Digg по непрерывному развертыванию . Приведенный выше рисунок рабочего процесса вдохновлен проектом Android OS .

Ответы [ 4 ]

10 голосов
/ 13 сентября 2010

Сколько человек работает над этим?Если у вас есть только 10 или 20 разработчиков, я не уверен, что будет разумно использовать такой сложный рабочий процесс.Если вы управляете 500, конечно ...

Мое личное чувство - ПОЦЕЛУЙ.Сохраняйте это простым, глупый ... Вы хотите, чтобы процесс был и эффективным, и более важным: простым.Если это сложно, либо никто не собирается делать это правильно, либо по прошествии времени детали будут проскальзывать.Если вы сделаете это просто, это станет второй натурой, и через несколько недель никто не станет подвергать сомнению этот процесс (ну, в любом случае, его семантика) ...

И другие личные чувства всегда запускают все вашиUNIT тесты.Таким образом, вы можете пропустить все дерево решений в своей блок-схеме.В конце концов, что дороже, несколько минут процессорного времени или мозговых циклов, чтобы понять разницу между частичным прохождением теста и массивным провалом теста.Помните, что сбой - это сбой, и нет никакой практической причины, по которой код должен когда-либо показываться рецензенту, который может провалить сборку.

Теперь тесты Selenium обычно довольно дороги, поэтому я могу согласитьсяотталкивать их до тех пор, пока рецензент не одобрит.Но вам нужно подумать об этом ...

О, и если бы я это реализовывал, я бы поставил там формальный этап контроля качества.Я хочу, чтобы люди-тестеры смотрели на любые изменения, которые были сделаны.Да, Selenium может проверить вещи, о которых вы знаете, но только человек может найти вещи, о которых вы не задумывались.Обратитесь к своим выводам в новых тестах Selenium и Integration, чтобы предотвратить регрессию ...

3 голосов
/ 14 сентября 2010

Важно, чтобы ваши тесты были чрезвычайно быстрыми , т. Е. Нет ввода-вывода и возможность запуска параллельно и распределенных тестов. Не знаю, насколько это применимо к php, но если вы сможете протестировать модули кода в памяти db и смоделировать среду, вам будет лучше.

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

2 голосов
/ 07 сентября 2012

Все переключения между функциями имеют эффект замедления, а вместе с этим - увеличения количества изменений (и, следовательно, риска), которые переходят в развертывание.

Ручные ворота качества по определению являются признанием того, что качество не было встроено с самого начала. Единственная причина, по которой код должен быть рассмотрен позже, заключается в том, что есть мнение, что качество уже недостаточно хорошее.

В настоящее время я пытаюсь удалить формальную проверку кода из наших конвейеров именно по этой причине. Это вызывает задержки обратной связи и цитирование Мартина Фаулера:

"Смысл непрерывной интеграции в том, чтобы обеспечить быструю обратную связь. Ничто не высасывает кровь из операций КИ, кроме сборки, которая занимает много времени."

Вместо этого я хотел бы сделать так, чтобы код проверял то, что запрашивают авторы, если это требуется, или иным образом выполняется во время кодирования членами команды, возможно, в виде парного программирования XP.

Я думаю, что ваша цель должна состоять в том, чтобы после слияния кода с управлением исходными кодами абсолютно не требовалось никакого дополнительного ручного вмешательства.

1 голос
/ 14 сентября 2010

Я не знаю, относится ли это к PHP, но вы можете заменить хотя бы часть проверки кода статическим анализом.

Качество проверок кода зависит от качестварецензенты, в то время как статический анализ опирается на лучшие практики и шаблоны, и является полностью автоматическим.Я не говорю, что проверки кода должны быть отменены, я просто думаю, что это может быть сделано в автономном режиме.

См.

http://en.wikipedia.org/wiki/Static_code_analysis

http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

...