Ответ 1
Предварительно протестированные комментирует
До (TeamCity, менеджер сборки):
Концепция проста, система сборки выступает в качестве контрольно-пропускного пункта между вашим фиксатором, входящим в магистраль, и только после того, как система сборки определяет, что ваша фиксация не нарушает работу, позволяет ли она вносить изменения в контроль версий, где другие разработчики будет синхронизировать и интегрировать это изменение в свои локальные рабочие копии.
После (используя DVCS, например Git, это исходный репозиторий):
Мой рабочий процесс с Hudson для предварительно протестированных коммитов включает три отдельных репозитория Git:
- мое местное репо (локальное),
- канонический/центральный репо (происхождение)
- и мой "всемирно читаемый" (внутри брандмауэра) репо (public).
Для предварительно протестированных коммитов я использую постоянно изменяющуюся ветку, называемую "pu" (потенциальные обновления), на всемирно читаемом репо.
Внутри Hudson я создал задание, которое опросит читаемый мир репо (public) для изменений в ветке "pu" и начнет создавать сборки, когда будут перенесены обновления.мой рабочий процесс для перехода от начала к происхождению:
* hack, hack, hack
* commit to local/topic
* git pup public
* Hudson polls public/pu
* Hudson runs potential-updates job
* Tests fail?
o Yes: Rework commit, try again
o No: Continue
* Rebase onto local/master
* Push to origin/master
Используя этот предварительно протестированный бизнес-процесс фиксации , я могу разгрузить большинство моих требований к тестированию для кластера систем сборки вместо того, чтобы запускать их локально, то есть я могу потратить большую часть своего времени на написание кода, а не на ожидание тесты для завершения на моей собственной машине между итерациями кодирования.
(Вариация) Частная сборка (Дэвид Гагеот, Альгодейл)
Тот же принцип, что и выше, но сборка выполняется на той же рабочей станции, что и для разработки, но на клонированном репо:
Как не использовать CI-сервер в долгосрочной перспективе и не страдать от потери времени, теряемого на локальных сборках?
С Git, его кусок пирога.
Сначала мы git клонируем рабочий каталог в другую папку. Git делает копию очень быстро.
В следующий раз нам не нужно клонировать. Просто скажите Git получить дельт. Чистый результат: мгновенное клонирование. Впечатляет.Как насчет последовательности?
Выполнение простого "git pullиз рабочего каталога поймет, используя дайджесты deltas, изменения, которые уже были перенесены в общий репозиторий.
Нечего делать. Впечатляет снова.Конечно, хотя сборка работает во втором каталоге, мы можем продолжать работать над кодом. Не нужно ждать.
Теперь у нас есть частная сборка без обслуживания, без дополнительной установки, не зависящей от IDE, выполняется с одной командной строкой. В общем хранилище нет более строгих построек. Мы можем перерабатывать наш сервер CI.
Да. Ты хорошо слышал. Weve просто построил безсерверный CI. Каждая дополнительная функция реального CI-сервера для меня является шумом.
#!/bin/bash
if [ 0 -eq `git remote -v | grep -c push` ]; then
REMOTE_REPO=`git remote -v | sed 's/origin//'`
else
REMOTE_REPO=`git remote -v | grep "(push)" | sed 's/origin//' | sed 's/(push)//'`
fi
if [ ! -z "$1" ]; then
git add .
git commit -a -m "$1"
fi
git pull
if [ ! -d ".privatebuild" ]; then
git clone . .privatebuild
fi
cd .privatebuild
git clean -df
git pull
if [ -e "pom.xml" ]; then
mvn clean install
if [ $? -eq 0 ]; then
echo "Publishing to: $REMOTE_REPO"
git push $REMOTE_REPO master
else
echo "Unable to build"
exit $?
fi
fi
Дмитрий Ташкинов, у которого есть интересный вопрос о DVCS и CI, спрашивает:
Я не понимаю, как "Weve просто построил безсерверный CI" вместе с состоянием Мартина Фаулера:
"После того, как я создал собственную сборку правильно синхронизированной рабочей копии, я могу, наконец, перенести свои изменения в магистраль, которая затем обновляет репозиторий. Однако моя фиксация не завершает мою работу. На этом этапе мы снова создаем, но это время на интеграционной машине на основе кода магистрали. Только когда эта сборка будет успешной, мы можем сказать, что мои изменения выполнены. Всегда есть шанс, что я что-то пропустил на своей машине, и репозиторий не был должным образом обновлен".
Вы игнорируете или сгибаете его?@Dmitry: Я не игнорирую и не изгибаю процесс, описанный Мартин Фаулер в записи ContinuousIntegration.
Но вы должны понимать, что DVCS добавляет публикацию в качестве ортогонального измерения в ветвление.
Безсерверный CI, описанный Дэвидом, является просто реализацией общего процесса CI, подробно описанного Мартином: вместо того, чтобы иметь CI-сервер, вы нажимаете на локальную копию, где выполняется локальный CI, затем вы нажимаете "действительный" код на центральный репо.@VonC, но идея заключалась в том, чтобы запустить CI NOT локально, особенно, чтобы не пропустить что-то в переходе между машинами.
Когда вы используете так называемый локальный CI, он может пройти все тесты только потому, что он локальный, но потом выйдет на другой компьютер.
Так это целая? Я вообще не критикую здесь, вопрос мне трудный, и я пытаюсь понять.@Dmitry: "Так же это целое"?
Это один уровень интеграции, который может помочь избавиться от всех основных проверок (например, проблема с форматом, стиль кода, определение основного статического анализа,...)
Поскольку у вас есть этот механизм публикации, вы можете связать этот тип CI с другим CI-сервером, если хотите. Этот сервер, в свою очередь, может автоматически нажимать (если это все еще быстро) на "центральное" репо.Дэвиду Гэгеот не нужен этот дополнительный уровень, уже находящийся в стадии развертывания (ПК- > ПК), и ему нужен только тот базовый тип уровня CI. Это не мешает ему устанавливать более полный сервер системной интеграции для более полного тестирования.