Check Out for Continuous Integration

Question

Что вы обычно делаете, проверяя код из программного обеспечения для управления версиями для непрерывной интеграции или ночной сборки? Вы 1) вытащили последний код или 2) потянули какой-то тэг (т. Е. FUNCTIONAL), который представляет последний код разработчика, который нужно протестировать?

Я думаю, ответ на это зависит от того, как люди обычно используют свои хранилища управления конфигурацией. Вы намерены хранить только код, который является «полным». Если это так, если разработчик работает над заданием на неделю или около того, он/она не сможет ничего проверить, пока задача не будет полностью выполнена. Однако, если сервер непрерывной интеграции просто вытащил известный тег вместо того, чтобы вытащить последний код, это позволит разработчикам проверять код очень часто, поскольку они работают над сохранением истории их работы. Затем, когда они были довольны изменениями, они могли пометить свой новый код тегом FUNCTIONAL.

Просто хотелось узнать лучшие практики.

Благодаря

Answer 1

Так что мы обычно делаем, это есть «строить» ветвь, сервер CI строит прочь. Мы объединяем все, что мы хотим включить в ночную сборку в ветку сборки, и она будет строиться там.

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

Answer 2

Основные рекомендации я бы потушить для CI (больше как правила большого пальца):

1. Имейте это вытащить код из ГОЛОВЫ/MASTER. Сделайте свой HEAD/MASTER самым последним, насколько это возможно, и как можно более .
2. Никто не может совершить поломку кода HEAD/MASTER. Если это произойдет, то означает, что кто-то сломал сборку.
3. Тот, кто нарушает сборку, должен быть , зафиксированный, чтобы исправить его, как только возможно.
4. Имейте свой CI для запуска сборок на основе на основе фиксации. Итак, как только кто-то нарушит код HEAD, CI получит его и сломает сборку. Большинство серверов CI , которые я видел, поддерживают этот modus operandi.
5. Вы также можете создать свой CI до сгенерировать ночные сборки и пометить код при создании пакетов . Это также хорошая практика , и вы можете видеть, что собирается на многих играх CI из open-source проектов по всему миру.

Некоторые из моих опытов: Наш CI достает код с HEAD/MASTER. Мы используем git здесь, поэтому нашим разработчикам всегда очень легко работать с филиалами и поддерживать их синхронизацию - но они только получают фиксированный код для HEAD/MASTER.

Answer 3

Правильный ответ основан на том, как вы организуете свой код.

Если магистраль всегда должна быть стабильной/рабочей, тогда вы просто строите ее.

Если у вас есть филиал, который является «золотой» ветви, а затем ...

В нашем магазине, у нас есть три вида ветвей:

• MAINLINE // всегда работоспособна, всегда " готов отпустить раз QA сделано»
• выпущено ветви // золотой, выпущенный и релиз-возможность в любое время
• ветви развития // где неаккуратно операция делается

(Конечно, для этого хорошо подходит хороший vcs. Мы используем perforce, у которого есть замечательное разветвление.)

Мы делаем наше непрерывное здание с линии магистрали и выпуска.

НТН