Рабочий процесс Mercurial с выборочным развертыванием функций и непрерывной интеграцией - PullRequest
3 голосов
/ 02 марта 2011

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

у нас есть система, которая отслеживает проблемы и запросы на улучшение. большинство из них - довольно маленькие ошибки и улучшения, над которыми работал один разработчик за один или два дня до недели. я хочу, чтобы деловые люди и ИТ-менеджеры договаривались о приоритетах заявок, над которыми работают разработчики. после завершения эти изменения фиксируются и передаются в центральный репозиторий и помечаются как dev complete в системе создания билетов. тогда команды qa и business должны иметь возможность выбирать из заявок, помеченных как dev complete, и включить их в наш продукт для следующего выпуска на основе приоритетов, количества qa и доступности qa *. 1003 *

Первоначально я думал, что смогу реализовать это, если разработчики будут вносить изменения в новую именованную ветку для каждого тикета. при этом ветвь для каждого выбранного тикета может быть объединена по умолчанию, и может быть выполнена сборка и развертывание в qa (и, в конечном счете, в производстве).

проблема с этим - постоянная интеграция. мне кажется, я могу только настроить teamcity статически, чтобы создать определенную ветку в нашем центральном хранилище. Возможно, это ограничение версии Teamcity, на которой мы находимся. в настоящее время используется 5.0.3, но обновление является опцией (и кое-что мы, вероятно, сделаем в любом случае). может быть, есть какой-то хитрый способ заставить его собрать его из наконечника и, следовательно, из заголовка ветви, в которой произошел коммит, инициирующий сборку? если разработчики фиксируют и выдвигают разные ветки для всего, и эти ветви не объединяются по умолчанию, пока не пройдет какое-то время - достаточно позже, чтобы qa теперь ждала эти изменения для сборки, и, если есть неработающая сборка, стоимость выше - нет конкретной ветки, в которой мы могли бы выполнять непрерывную интеграционную сборку.

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

Ответы [ 2 ]

1 голос
/ 02 марта 2011

Используя Jenkins (ранее Hudson), разработчики могут легко продублировать существующее задание (например, задание, которое создает новейший заголовок в ветви «по умолчанию») и внести небольшое изменение (например, задание, которое создает новейший заголовок в ветвь «джим»). (Хотя прочитайте мой комментарий выше о том, почему именованные ветви, вероятно, не являются правильным выбором для того, что вы делаете). Предположительно, у teamcity есть нечто подобное.

Другой путь заключается в том, чтобы сделать так, как вы сказали, и просто заставить строителя всегда строить «наконечник» независимо от ветви. Вы, вероятно, можете добиться этого, просто введя «tip» в качестве имени ветви. Это не спецификатор ветки, но teamcity, скорее всего, просто выполняет команду «hg update -C -r BRANCHNAME», и «tip» там будет отлично работать.

0 голосов
/ 15 марта 2011

Я пришел к выводу, что направление, в котором я пытался идти, просто не сработало. придется сделать это по-другому.

...