Предварительно протестированные коммиты
До (TeamCity, менеджер сборки):
Концепция проста: система сборки выступает в качестве барьера между входом в ваш коммит, и только после того, как система сборки определит, что ваш коммит не сломал вещи, он позволяет ввести коммит в управление версиями, где другие разработчики синхронизирует и интегрирует эти изменения в свои локальные рабочие копии
После (с использованием DVCS, такого как Git, который является хранилищем исходного кода):
Мой рабочий процесс с Hudson для предварительно протестированных коммитов включает три отдельных репозитория Git:
- мой локальный репо (локальный),
- канонический / центральный репо (происхождение)
- и мое «читаемое» (внутри брандмауэра) хранилище (общедоступное).
Для предварительно протестированных коммитов я использую постоянно меняющуюся ветку "pu" (потенциальные обновления) в читаемом мире репо.
Внутри Хадсона я создал задание, которое опрашивает общедоступный репозиторий (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 clone» рабочего каталога в другую папку. Git делает копию очень быстро.
В следующий раз нам не нужно клонировать. Просто скажи мне, что надо получить дельты. Чистый результат: мгновенное клонирование. Впечатляет.
А как насчет последовательности?
Выполнение простого «git pull» из рабочего каталога, используя дайджесты дельты, позволит понять, какие изменения уже внесены в общий репозиторий.
Нечего делать. Впечатляет снова.
Конечно, пока сборка выполняется во втором каталоге, мы можем продолжать работать над кодом. Не нужно ждать.
Теперь у нас есть частная сборка без обслуживания, без дополнительной установки, не зависящая от IDE, которая запускается с одной командной строкой. Нет больше неработающей сборки в общем хранилище. Мы можем перезапустить наш CI сервер.
Да. Вы хорошо слышали. Мы только что создали 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 , спрашивает:
Я не понимаю, как "Мы только что создали CI без сервера" соответствуют состоянию Мартина Фаулера:
«После того, как я сделал свою собственную сборку должным образом синхронизированной рабочей копии, я, наконец, могу зафиксировать свои изменения в основной строке, которая затем обновляет репозиторий. Однако моя фиксация не заканчивает мою работу. В этот момент мы строим снова, но это время на машине интеграции, основанной на основном коде. Только когда эта сборка завершится успешно, мы можем сказать, что мои изменения сделаны. Всегда есть вероятность, что я что-то пропустил на своей машине, и хранилище не было должным образом обновлено. "
Вы игнорируете или сгибаете это?
@ Дмитрий: я не игнорирую и не сгибаю процесс, описанный Мартином Фаулером в его записи ContinuousIntegration .
Но ты долженпонимать, что DVCS добавляет публикацию в качестве ортогонального измерения к ветвлению .
CI без сервера, описанный Дэвидом, является просто реализацией общего процесса CI, детально описанного Мартином: вместо того, чтобы иметь CI-сервер, вы отправляете локальную копию, где работает локальный CI, а затем «валидный» код в центральное хранилище.
@ VonC, но идея состояла в том, чтобы запускать CI NOT локально, особенно чтобы не пропустить что-то при переходе между машинами.
Когда вы используете так называемый локальный CI, он может пройти все тесты только потому, что он локальный, но позже выйдет из строя на другом компьютере.
Так это интеграция? Я вообще не критикую здесь, вопрос сложный для меня, и я пытаюсь понять.
@ Дмитрий: "Так это целочисленность"?
Это один уровень интеграции, который может помочь избавиться от всех основных проверок (таких как проблема с форматированием, стиль кода, обнаружение базового статического анализа, ...)
Поскольку у вас есть этот механизм публикации, вы можете при необходимости связать этот вид CI с другим сервером CI. Этот сервер, в свою очередь, может автоматически выдвигать (если это все еще ускоренная перемотка вперед) к «центральному» репо.
Дэвид Гаге не нуждался в этом дополнительном уровне, поскольку уже достиг цели в плане архитектуры развертывания (ПК-> ПК) и нуждался только в этом базовом уровне CI.
Это не мешает ему настроить более полный сервер системной интеграции для более полного тестирования.