То, что вы обсуждаете в своем вопросе, - это на самом деле 3 разных понятия:
Непрерывная интеграция в своей основе вносит небольшие изменения и часто синхронизирует эти изменения с «глобальной истиной». Вместо того, чтобы оформлять заказ и удерживать его в течение недели, разработчик должен поработать над задачами, которые могут быть выполнены в течение дня, чтобы его код никогда не был слишком далеко не синхронизирован с основным хранилищем.
Чтобы достичь этого, не причиняя боли своей команде (т.е. проверяя источник, который не создает или нарушает существующую функциональность). Разработчик должен убедиться, что его код не «нарушает сборку». Если это делается вручную, это добавляет дополнительные издержки к процессу разработки (представьте себе проект, который занимает много времени для сборки и / или имеет много взаимозависимостей, где изменение одной строки кода может неожиданно повлиять на приложение).
Чтобы смягчить эту ситуацию, мы используем другие методы, чтобы устранить эти издержки.
Мы используем автоматические сборки для извлечения источника и его сборки, при необходимости запускаем автоматические тесты, которые проверяют, что приложение работает должным образом (этот шаг полезен только как набор тестов).
Дальнейший шаг непрерывной доставки решает вашу проблему с базой данных и другими проблемами. Идея заключается в том, чтобы обеспечить некоторый уровень управления версиями для базы данных и других факторов среды, чтобы мы могли как можно быстрее подтвердить, что приложение работает в среде, максимально приближенной к рабочей .
builds
иbuild
потому что я не знал, какой из них использовать.