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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

См.

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

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