Преимущества сервера сборки? - PullRequest
11 голосов
/ 09 апреля 2010

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

Каковы наиболее существенные преимущества использования Build Server для вашего проекта?

Ответы [ 8 ]

17 голосов
/ 09 апреля 2010

Есть больше преимуществ, чем просто поиск ошибок компилятора ранее (что важно):

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

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

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

3 голосов
/ 09 апреля 2010

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

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

...

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

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

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

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

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

2 голосов
/ 09 апреля 2010

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

1 голос
/ 18 августа 2015

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

Сначала очистите DLL Hell. Когда кто-то строит на своей локальной машине, он может указывать на любую справочную папку. Многие проекты создавались с неправильными версиями DLL от тех, кто не обновлял свою локальную папку. На сервере сборки он всегда будет построен из одного и того же источника. Все, что вам нужно сделать - это получить последние ссылки.

Вторым важным для нас был способ поддержки проектов с небольшим знанием о них. Любой разработчик может взять исходный код и при необходимости исправить его. Им не нужно возиться с часами установки или поиска ссылок. У нас есть зарубежная команда, которая работает в основном над проектом, но если есть срочные решения, которые мы должны сделать в течение нескольких часов в США, мы можем взять последние и построить, чтобы не беспокоиться о сломанном источнике или о том, что не было зарегистрировано. Закрытые проверки сохраняют время всех остальных в вашей команде.

1 голос
/ 09 апреля 2010

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

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

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

1 голос
/ 09 апреля 2010

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

1 голос
/ 09 апреля 2010
  • Когда ваш начальник говорит: «Мне нужна копия последнего кода как можно скорее», вы можете получить его им в течение <5 минут. </p>

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

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

...