Когда уместно начать использовать следующую ревизию инструмента при собачьем кормлении?

В частности, я работаю над инструментом, который интегрирует DVCS и систему сборки, но я представляю себе проблему, с которой я столкнусь, возникнет для любого, кто разрабатывает «мета» инструмент (компилятор, VCS, система сборки, тестовый прогон и т. Д.), Который они хочу развиваться через "собачий корм" .

Мой вопрос: в процессе выпуска в стиле scrum с использованием ветвящегося рабочего процесса , в какой момент я начинаю использовать более новую версию инструмента в цикле разработки инструмента?

Я ищу процесс для создания баланса между:

• постоянно использую developверсию инструмента: я обнаружил, что нарушаю свою собственную разработку по мере внесения изменений.

• постоянно используйте masterверсию инструмента: любые проблемы, которые я обнаруживаю с помощью собачьей упряжки, - это проблемы, которые уже были выпущены.

Первое, что нужно сделать, - это провести очень тщательные автоматические регрессионные тесты в автономном режиме. Сделайте прохождение этих тестов минимальным требованием к тому, что вы официально используете.

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

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

Координировать это с командой сложно, но я полагаю, что это в основном вопрос о том, чтобы позволить кому-либо инициировать запасной вариант и сообщить причины. В управлении версиями, один из способов обозначить это будет что-то вроде last_known_goodветки, где-то между developи masterв вашем рабочем процессе. Ничто не выталкивается туда, пока вы успешно не соберете сборку.

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

Если вам нужно подождать, пока мастер-версия будет иметь такой уровень доверия, пусть будет так.

Git также является таким инструментом и, очевидно, также занимается собаками. Но он делает это в разной степени в разных средах. Общедоступные серверы работают только с релизом, в то время как разработчики обычно работают либо с next(это название git проекта для «разработки»), либо pu(даже больше, чем разработкой). Любой разработчик , который блокируется какой - то проблемой может вернуться nextили masterили последнего выпуска , когда они заблокированы чем - то и главное хранилище не влияет, так что проблемы могут быть очищены путем ссылки на него.

Модель ветвления похожа на приведенную выше с немного другими именами. masterэто то, из чего сделаны большие выпуски, maintветвь релиза для следующего выпуска, nextпохожа на разработку с небольшим отличием в том, что функции могут быть объединены с мастером отдельно после того, как они уже в следующем, а не во всем следующем слиянии.

Есть дополнительная ветка pu. Это создается путем слияния всех ветвей элементов, которые рассматриваются для интеграции вместе next(ветвь отбрасывается и воссоздается каждый раз). IIRC публикуется только в том случае, если он проходит тестовый набор. Последний раз, когда я смотрел, сопровождающий Junio ​​запускал сценарии для его регулярного создания вручную, но такие сценарии могли запускаться при непрерывной интеграции каждую ночь, и я считаю, что Геррит даже создает его автоматически.

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

Основываясь на принятом ответе , я собираюсь расширить рабочий процесс ветвления, чтобы поддерживать ветки, подобные следующим:

• master: сливается с release-*закрытием
• dogfood: ветви от master; включает исправления, выявленные во время кормления собак; сливается с developмомента, когда программное обеспечение считается «стабильным» для внутреннего использования; глава этой ветви может быть перенесен в прошлое, если это необходимо
• develop: ветви от master; включает текущие изменения, исправления, слияния dogfoodи feature-*ветви
• feature-*: ветви от develop; включает в себя изменения для конкретной новой функции
• release-*: ответвления от того, dogfoodкогда программное обеспечение считается «стабильным» для внешнего использования; включает в себя обновления документации и небольшие исправления до слияния сmaster