Как обнаружить конфликтные / перезаписанные файлы в Hudson или Cruise Control

Question

Допустим, два разработчика интерфейса работают над одним файлом только для изменения свойства css, не зная друг друга. Они оба работают в своей собственной ветке в управлении исходным кодом.

Первый измененный файл css разработчика был развернут в тестовой системе, и он все еще находится на стадии тестирования.

До того как первое изменение разработчика было одобрено и развернуто в рабочей среде, измененный файл css второго разработчика был развернут в тестовой системе и переписал первую версию разработчика.

Есть ли какая-либо функция, которая отслеживает состояние каждого файла <в процессе тестирования, в тестовом прохождении, в процессе тестирования, в случае неудачи теста, в состоянии готовности к выполнению теста и т. Д.> В тестовой системе в Hudson или Cruise Control.

А также есть ли в Хадсоне или Круиз-контроле какая-либо функция, которая предупреждает или защищает такого рода случаи перезаписи / слияния / конфликта для этого небольшого случая css cahnge.

С наилучшими пожеланиями

Answer 1

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

Answer 2

Звучит как чепуха.Вы развертываете две разные ветви в одной и той же тестовой среде.Прежде чем перезаписывать развертывание из второй ветви, убедитесь, что тесты для первой ветви выполнены успешно.Я бы сделал это вручную или лучше, я бы создал ветку интеграции (обычно магистральную или текущую ветку выпуска), чтобы интегрировать и использовать эту ветку только для выполнения тестов.Вот.Проблема, которую вы описываете, звучит как проблема исправления ошибок.Стандартная процедура должна заключаться в том, что кто-то заявляет об ошибке до ее исправления.Первый, претендующий на это, имеет честь это исправить.Таким образом, вы не столкнетесь с проблемой двух людей, исправляющих одну и ту же ошибку.Если об ошибке ранее не сообщалось, сначала сообщите об этом, а затем заявите о ней, прежде чем исправлять.Звучит как накладные расходы?Да, но это называется управлением проектами и помогает сэкономить время (и, следовательно, деньги) в долгосрочной перспективе.Если этот тип формального общения слишком важен для вас, вы можете создать чат для разработчиков, где они найдут что-то нуждающееся в исправлении.Но чаты работают только для небольших команд, и когда все команды работают в одном часовом поясе.