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

Question

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

1. Сборка займет несколько дней (даже недель в плохое время) и BVT.
2. Люди не могли зафиксировать код, как они будут, они не будут работать.
3. Люди будут фиксировать все коды в огромной пачке, поэтому написать общее сложно.

Я хочу знать, придерживается ли ваша команда такой же политики, и если нет, как вы справляетесь с этой ситуацией.

Спасибо

Answer 1

1. Выберите ревизию.
2. Проверьте код этой ревизии.
3. Сложение.
4. ???
5. Profit.

Answer 2

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

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

«Усилия по разработке» (как сборка с его настройками) никогда не должны блокировать другие усилия по разработке (ежедневные коммиты).

Answer 3

Шаг 1: svn copy / trunk / your / project / идет / здесь / temp / build

Шаг 2: Поместите ваши источники в / temp / build

Шаг 3: Выполнить сборку в / temp / build. Если вы столкнулись с ошибками, исправьте их в / temp / build и соберите снова

Шаг 4. В случае успеха svn move / temp / build / builds / product / buildnumber

Таким образом, разработчики могут регистрироваться всякий раз, когда они хотят, и их не беспокоит ежедневная / еженедельная / ежемесячная / годовая сборка

Answer 4

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

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

О, и вы будете смотреть на ветви совершенно по-новому.

Если вы заинтересовались ртутью, зайдите на этот сайт: http://hginit.com

Answer 5

Мы создаем ветку для каждого тикета или новой функции, даже если тикет маленький (например, исправление занимает всего 2 часа).

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

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

Разработчики всегда могут кодировать, создавая собственную ветку из ствола в любое время. Обратите внимание, что мы небольшая команда, в которой всего 12 разработчиков.

Answer 6

Я работал над проектами с похожей политикой. Причина, по которой нам нужна такая политика, заключается в том, что мы не использовали ветки. Если разработчикам разрешено создавать ветку, то они могут делать любые необходимые коммиты в этой ветке и никому не прерывать - политика становится «не объединяться с основной» в течение периода еженедельной сборки.

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

Использование меток, как предложил VonC, также является хорошим подходом. Однако вам необходимо учитывать, что происходит, когда помеченному файлу требуется исправление для ночной сборки - что, если разработчик зарегистрировал изменение в этом файле с тех пор, как он был помечен, и что изменения разработчика не следует включать в еженедельную сборку ? В этом случае вам все равно понадобится ветка. Но разветвление от метки тоже может быть хорошим подходом.

Я также работал над проектами, которые превращают ветки в сумасшедшие, и это становится беспорядком, пытаясь выяснить, что происходит с каким-то конкретным файлом. Изменения могут быть зафиксированы в нескольких ветвях за один и тот же период времени. В конце концов конфликты слияния должны быть разрешены. Это может быть довольно головной болью. В любом случае, я предпочитаю использовать ветки.

Answer 7

Звучит разочарование. Есть ли причина, по которой вы, ребята, не занимаетесь Непрерывная интеграция ?

Если это звучит слишком экстремально для вас, определенно потратьте некоторое время на изучение работы ветвления в SVN. Я думаю, вы могли бы убедить команду либо развиваться на ветвях и сливаться с стволом, либо фиксировать «формальную сборку» для определенного тега / ветви.

Answer 8

Ух ты, это ужасный способ развиваться.

В прошлый раз, когда я работал в действительно большой команде, у нас было около 100 разработчиков в 3 часовых поясах: США, Великобритания, Индия, поэтому мы могли эффективно работать в течение 24 часов.

Каждый разработчик проверяет дерево сборки и работает над тем, над чем он должен работать. В то же время будут происходить непрерывные сборки. Сборка создаст свою копию из представленного кода и создаст его. Любые сбои вернутся к самому последнему отправителю (ям) для кода для этой сборки.

Результат:

• Множество сборок, большинство из которых скомпилировано нормально. Затем эти сборки запустили сценарии автоматического дымового тестирования, чтобы обнаружить любые неожиданные ошибки, не обнаруженные во время тестирования, до принятия.
• Сбои сборки, обнаруженные рано, исправлены рано.
• Ошибки обнаружены рано, исправлены рано.
• Разработчики ждут только минимального времени для отправки (они должны ждать, пока любой другой разработчик, который отправляет, завершит отправку - это требование сделано для того, чтобы серверы сборки имели точку, в которой они могли бы получить дерево исходных текстов для новой сборки ).

У большинства разработчиков было две машины, поэтому они могли работать над второй ошибкой, выполняя свои тесты на другой машине (тесты были очень графическими и вызывали всевозможные проблемы с фокусировкой, поэтому вам действительно требовалась другая машина для другой работы). ).

Высокопроизводительная, непрерывная разработка без простоев, как в вашем сценарии.

Если честно, я не думаю, что смогу работать на месте, которое вы описываете. Разрушение души было бы таким непродуктивным способом.

Answer 9

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

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

Answer 10

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