Преимущества сервера сборки?

См. Непрерывная интеграция: преимущества непрерывной интеграции :

В целом я считаю, что наибольшее и наиболее широкое преимущество непрерывной интеграции Интеграция снижает риск. Я все еще вспоминаю тот ранний программный проект, о котором я упоминал в первом абзаце. Вот они и подошли к концу (как они надеялись) долгого проекта, но не имели реального представления о том, сколько времени пройдет, прежде чем они будут завершены.

...

В результате проекты с непрерывной интеграцией, как правило, имеют значительно меньше ошибок, как в производстве, так и в процессе. Однако я должен подчеркнуть, что степень этого преимущества напрямую зависит от того, насколько хорош ваш набор тестов. Вы должны обнаружить, что создать набор тестов, который будет иметь заметную разницу, не так уж и сложно. Однако обычно требуется некоторое время, прежде чем команда действительно доберется до того низкого уровня ошибок, на который у нее есть потенциал. Достичь этого - значит постоянно работать над тестами и улучшать их.

Если у вас есть непрерывная интеграция, это устраняет одно из самых больших препятствий для частого развертывания.Частое развертывание ценно, потому что оно позволяет вашим пользователям быстрее получать новые функции, быстрее получать обратную связь по этим функциям и, как правило, более активно сотрудничать в цикле разработки. Это помогает разрушить барьеры между клиентами и разработкой - барьеры, которые, как я считаю, являются самыми большими препятствиями на пути к успешной разработке программного обеспечения.

По моему личному опыту, настройка сервера сборки и реализация процесса CI действительно меняют способ ведения проекта. Процесс создания сборки превращается в обычную повседневную вещь, потому что вы делаете это буквально каждый день. Это позволяет вам ловить вещи раньше и быть более проворными.

Также обратите внимание, что настройка сервера сборки - это только часть процесса CI, который включает в себя настройку тестов и, в конечном итоге, автоматизацию развертывания (очень полезно).

Еще одно побочное преимущество, о котором часто не упоминают, заключается в том, что инструменты CI, такие как CruiseControl.NET , становятся центральным издателем всех номеров версий для всех веток, включая внутренние RC. Затем вы можете заставить свою команду всегда выпускать сборку, созданную с помощью инструмента CI, даже если это пользовательская версия продукта.

Мы обнаружили, что автоматическая пометка VCS для точного кода, создающего версию, очень полезна при возврате к конкретной версии для воспроизведения проблемы.

Раннее предупреждение о сломанном или несовместимом коде означает, что все конфликты выявляются в кратчайшие сроки, что позволяет избежать хаоса в последнюю минуту в дату выпуска.

• Когда ваш начальник говорит: «Мне нужна копия последней версии кода как можно скорее», вы можете получить ее менее чем за 5 минут.

• Вы можете легко сделать сборку доступной для внутренних тестировщиков, и когда они сообщат об ошибке, они могут легко сказать вам, что «это была ночная сборка 1 апреля», чтобы вы могли работать с той же версией исходного кода.

• Вы будете уверены, что у вас есть автоматизированный способ создания кода, который не полагается на библиотеки / переменные среды / сценарии и т. Д., Которые настроены в средах разработчиков, но которые трудно воспроизвести другими, которые хотят работать с кодом.

Интеграция - это слепое пятно
Интеграция часто не пользуется уважением - «мы просто бросаем двоичные файлы в инсталлятор». Если это не работает, это вина установщика.

Стабильная среда сборки
Предотвращает такие оправдания, как «Эта ошибка иногда возникает при сборке на машине Джо». Предотвращает случайное использование старых зависимых библиотек при сборке на машине Майка.

Настоящая догадка
У вас, штатных тестировщиков и пользователей, есть настоящий опыт работы с клиентами. У ваших разработчиков есть четкие рекомендации по воспроизведению ошибок.

• Непрерывная интеграция выявляет любые проблемы в общей картине, поскольку разные команды/разработчики работают над разными частями кода/приложения/системы
• Модульные и интеграционные тесты, выполняемые с каждой сборкой, идут еще глубже и выявляют проблемы, которые могут быть не видны на рабочей станции разработчика
• Бесплатные кофе/конфеты/пиво. Когда кто-то ломает сборку, он/она делает это для других членов команды...

Я думаю, если вы сможете убедить членов вашей команды, что БУДУТ ошибки и проблемы интеграции, которые не будут выявлены во время разработки, этого должно быть достаточно.

И, конечно, вы можете сказать им, что команда будет выглядеть древней в современном мире, если вы не запустите непрерывные сборки :)