Предотвращение разрывов сборки - использование сборки перед фиксацией - PullRequest
3 голосов
/ 07 октября 2010

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

Ответы [ 2 ]

3 голосов
/ 07 октября 2010

В сборке Microsoft TFS есть то, что называется «стробированные регистрации», что обеспечивает это, выполняя частную регистрацию (называемую полкой), которая в случае успешной сборки преобразуется в обычную регистрацию.

http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx

TeamCity имеет концепцию «отложенной фиксации»

http://www.jetbrains.com/teamcity/features/delayed_commit.html

Я могу искренне рекомендовать TeamCity!

0 голосов
/ 07 октября 2010
  1. Получите LART и побейте разработчиков, которые ломают сборку.
  2. Иметь статус сборки на большом большом экране, где все могут видеть его с красным / зеленым фоном и именем последнего человека, совершившего коммит.
  3. Пусть сервер сборки отправит электронное письмо всей команде разработчиков с разработчиком, который нарушил сборку.

Честно говоря ... почему люди так зациклены на том, чтобы "заставить разработчиков делать X". Скажите им, что это процесс, и уволите их, если они не будут следовать ему.


РЕДАКТИРОВАТЬ: потому что следующее было слишком долго для комментария.

Я работаю в команде из 12 или около того разработчиков. Некоторые считают это большим, некоторые считают его маленьким

У нас есть большой экран (32-дюймовый телевизор с плоским экраном на 6-футовой подставке), который каждый может увидеть, который сообщает нам всевозможную информацию, включая (в самой большой рамке на экране) состояние «коммита» .

Наш процесс заключается в обновлении из SVN и локальном выполнении коммита сборки (около 2-3 минут) перед фиксацией. Если это пройдет, отправьте его. Если нет, то исправьте это локально и повторите. Поскольку мы делаем TDD, это обычно происходит, только если что-то, что вы извлекли из SVN, сломало что-то, над чем вы работали.

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

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

Кому интересно, если сборка сломается в CI, если она исправлена ​​быстро, чтобы не помешать работе команды?

...