Заставить разработчиков работать с последней успешной сборкой с SVN

Question

Если вы работаете с Subversion, как вы можете организовать, чтобы разработчики могли легко проверить последнюю работающую сборку и поработать над ней, вместо работы с потенциально сломанной HEAD?

Идея, лежащая в основе вопроса, заключается в следующемследующим образом.Когда над проектом одновременно работает много разработчиков, может случиться так, что кто-то нарушит сборку или некоторые тесты.Непрерывная интеграция помогает рано находить эти вещи, но это не предотвращает временную поломку выпуска HEAD.Поэтому я хочу дать всем возможность легко проверять и работать с последней версией, о которой известно, что она работает, и обновлять ее до HEAD только тогда, когда это необходимо для фиксации.Создание тега с помощью SVN, по-видимому, не является подходящим способом сделать это, поскольку в SVN тег по сути является новой веткой и может перемещаться после каждой успешной сборки.Как бы вы это сделали?

Answer 1

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

ЭтоТем не менее, вы можете получить свою сборку для обновления общедоступного пакетного файла / сценария в случае успеха, который используется вашими разработчиками и выполняет проверку определенной ревизии ствола (ревизия, с которой была запущена ваша успешная сборка).Таким образом, при успешной сборке вы должны обновить команду checkout, чтобы она выглядела примерно так:

svn co https://<ServerPath>@RevisionNumber

Где RevisionNumber, либо сохранялась при запуске проверки сервера, либо получалась путем вызова svn info и извлеченияRevision: значение

Answer 2

Если ваш CI-сервер уведомляет всех разработчиков, то есть не только тех, кто нарушил сборку при сбое сборки, ваши разработчики могут избежать извлечения разбитой головы, наблюдая за неудачной электронной почтой сборки и удерживая ее до тех пор, пока электронная почта «сборки исправлена»из.Если разработчик крайне нуждается в обновлении (возможно, после отпуска), он может вернуться к последней хорошей редакции.Большинство программного обеспечения CI поддерживает это.Я точно знаю, что Дженкинс предоставляет ссылку «последняя успешная сборка».Если вы хотите, чтобы веб-страница показывала это, как предложил @forsvarir, вы можете легко поцарапать эту страницу.

Answer 3

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

Но на самом деле это проблема практики разработки. Разработчики не должны делать код, который «нарушает сборку», и много написано о наказаниях, которые должны быть выплачены тем, кто это делает:)

Но, конечно, локальная сборка может быть успешной, в то время как сборка из кода, интегрированного обратно в транк, может дать сбой. Вот почему такие продукты, как TeamCity, имеют концепцию «персональной сборки», при которой незавершенная работа может быть построена на соединительной линии и зафиксирована только после успешной сборки.

Короче говоря, ваша проблема известна и признана, и для ее решения существует комбинация инструментов и методов. Но практика не включает в себя запрет на извлечение кода на основе результатов сборки.

Answer 4

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

Answer 5

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