Я очень удивлен, что это не дубликат, но я не могу найти другой.
Хорошо, вот сделка. Это два отдельных, но связанных вопроса.
Для управления сборкой важен тот факт, что у вас должна быть автоматическая, повторяемая сборка, которая перестраивает всю коллекцию программного обеспечения с нуля и полностью соответствует вашей доставляемой конфигурации. Другими словами, вы должны эффективно создавать кандидата на выпуск каждый раз. Многие проекты на самом деле этого не делают, но я видел, как это сжигает людей (читай "сожгли это") слишком много раз.
Непрерывная интеграция говорит о том, что этот процесс сборки следует повторять каждый раз, когда происходит значительное изменение в коде (например, регистрация), если это вообще возможно. Я выполнил несколько проектов, в которых это превращалось в сборку каждую ночь, потому что код был достаточно большим, чтобы его сборка занимала несколько часов, но в идеале нужно настроить процесс сборки так, чтобы какой-то автоматический механизм - например, муравей скрипт или make file --- перестраивает только те части, на которые повлияло изменение.
Вы решаете проблему предоставления определенной версии, сохраняя точную конфигурацию всех затронутых артефактов для каждой сборки, чтобы вы могли применить повторяемый процесс сборки к той конфигурации, которая была у вас. (Вот почему это называется «управление конфигурацией».) Обычные инструменты контроля версий, такие как git или subversion, предоставляют способы идентификации и именования конфигураций, чтобы их можно было восстановить; например, в SVN вы можете создать тег для конкретной сборки. Вам просто нужно хранить немного метаданных, чтобы вы знали, какую конфигурацию вы использовали.
Возможно, вы захотите прочитать одну из книг «Прагматический контроль версий», и, конечно, материал по CI и круиз-контролу на сайте Мартина Фаулера имеет важное значение.