В среде разработки программного обеспечения, где я работаю, у нас есть группа разработчиков, работающих в одной и той же (Java) кодовой базе (в настоящее время использующей SVN). Я замечаю, что люди хотят часто фиксировать то, что они построили, не «разбивая сборку». Поэтому именно по этой причине я смотрю на такие инструменты, как Git и Mercurial, которые делают разветвление и особенно слияние намного проще.Идея рабочего процесса непрерывной интеграции
Одна из вещей, которые я вижу, заключается в том, что если разработчик совершает «плохой код», тогда код нарушается для всех. Как идея избежать этого, мне хотелось бы иметь репозиторий промежуточной единственной функции, который просто является текущим «мастером», ТОЛЬКО одним набором изменений для этой единственной новой функции. Такой репозиторий «промежуточная единая функция» затем может быть автоматически протестирован (качество кода, модульное тестирование, ручная проверка кода и т. Д.), Прежде чем стать частью основной базы кода.
Итак, рабочий процесс, который я имею в виду, выглядит примерно так :.
- Разработчик создает новую функцию и ежедневно ее фиксирует.
- По прошествии некоторого времени разработчик завершает работу и отправляет весь набор изменений для интеграции в «основной» репозиторий.
- Система непрерывной интеграции принимает текущий «мастер», применяет набор изменений и проверяет код (конфликты слияния, PMD, Findbugs, ...), запускает модульные тесты, проверяет стиль кодирования и т. Д.
- Если система CI решает «плохой код», разработчик уведомляется о причинах, и разработчик должен устранить указанные проблемы. В этом случае основной репозиторий не изменяется.
- Если система CI решила «достаточно хорошо», код достигнет «ведущего разработчика» или «рецензента кода», который проверяет выбранное решение и утверждает или отклоняет его.
- Утвержденный набор изменений затем включается в основной репозиторий и доступен для всех разработчиков для переустановки/слияния.
У меня есть некоторые вопросы по поводу этого вида процесса:
- ли вы, что это будет хорошо работать на практике (то есть это хорошая идея или действительно Braindead один)?
- С кем-то из вас раньше работали? Каковы были про и кон?
- Есть ли сценарий «готовый к запуску»/procedure/tool/..., который позволяет запустить такой рабочий процесс (или вариант этой идеи) за минимальное время?
Спасибо.
Справка:
Я работал разработчиком около 13 лет назад в компании, где они строят подобный рабочий процесс внутри и у них были два ночных сборках:
- В «производство 'версия: Основная кодовая база
- «старшая версия: основная база кода со всеми новыми версиями всех измененных файлов.
Поскольку это была вся SCCS (модель блокировки-редактирования-разблокировки), на основе которой не было возможности «совершать часто», у вас были взаимоблокировки для изменения кода и всех других видов неприятных эффектов. То, что я ищу, это в основном хорошие вещи о том, что я использовал тогда, используя гораздо лучшие инструменты сегодняшнего дня.
Я прочитал страницу и, кажется, что если вы «совершить» изменение, то система сразу начинает работать. Как это работает, если вы хотите «совершать часто», но только хотите начать, когда думаете, что закончили. Если вы используете Test Driven Development, вы начинаете с выполнения (и совершения) тестов, которые преднамеренно «разбивают сборку», чтобы показать функции, которые все еще необходимо добавить. –
Вы не добавляете модульные тесты, которые ломают сборку, они могут терпеть неудачу с отдельными тестами, но сборка по-прежнему действительна, иначе вы никогда не сможете запускать тесты, ну конечно же, в моей среде. Это зависит от правил, которые вы настраиваете, чтобы определять, что такое «сломанная сборка» или нет. – redsquare
@niels - Я бы категорически не согласился с тем, что вы совершили сломанные тесты. Всегда выполняйте рабочий код и тесты. Не предварительно заполняйте пустые или ожидающие проверки. Используйте только действующий код, который используется. – Harmon