Болевые точки непрерывной интеграции

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

То есть мы отбрасывали ветки функций и запросы на извлечение (в git) и стремились фиксировать ветку mainline как минимум каждый день.

У нас есть комплексный блок и функциональный набор тестов как для передней, так и для задней части, который автоматически запускается Jenkins при нажатии на git.

Мы настроили приложение переключения функций и решили использовать его для более длительной работы функций.

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

  1. Задержки из-за процесса Vetting/ Manual QA часто были достаточно маленькими, поэтому мы не думали, что они требуют настройки переключения функций, например, добавления дополнительного поля в форму или изменения некоторых меток полей. Однако по разным причинам этот билет будет заблокирован (например, какой-то непредвиденный аспект задачи, требующий ввода UX).

    Это означало бы, что магистраль оказалась в скомпрометированном состоянии, пока мы ждали внешних зависимостей, чтобы разблокировать задачу. Часто мы говорили: "Мы не можем ничего развернуть до четверга, потому что тогда мы сможем получить обзор IA"

    Ответ здесь, вероятно, гораздо более жесткий, какие задания запускаются. Однако часто было трудно полностью предвидеть каждого потенциального блокиратора. Может быть, если задача заблокирована, необходимо добавить дополнительный dev, чтобы добавить переключатель функций или отменить коммиты? Сложная ситуация.

  2. Проблемы с проверкой кода при интеграции в основной ветке

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

  3. Общие вопросы проверки кода

    Мы немного использовали phabricator для проверки кода после фиксации, но обнаружили, что он помечает каждую фиксацию (некоторые очень незначительные) для проверки кода, а не показывает нам список изменений для каждой задачи разработчика. Так что пересмотр кода обременителен по сравнению с запросами git pull. Есть ли способ лучше?

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

2 ответа

Решение
  1. Не могли бы вы автоматизировать процесс проверки и / или запустить его перед интеграцией. Если вы автоматизируете процесс проверки, например, для добавления формы / кнопки и т. Д., Вам просто необходим набор тестов для запуска пост-интеграции, чтобы убедиться, что ваша основная линия не повреждена.

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

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

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

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

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

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

Вам нужно что-то большее, чем это?

Другие вопросы по тегам