Зачем моей команде разработчиков сервер сборки?

Есть несколько причин для использования серверов сборки. В произвольном порядке и навскидку:

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

   Ваш сервер сборки может копировать вашу целевую среду (операционную систему и т. д.), и меньше шансов, что что-то будет работать на рабочих столах разработчиков и сломается в производстве.

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

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

4. Развертывание продукта упрощается — разработчику или тестировщику не нужно запоминать несколько ручных шагов. Его можно легко автоматизировать.

5. Связь между разработчиками и QA упрощается. Персонал QA может отправиться в известное место, чтобы получить последние сборки с правильными версиями.

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

Чтобы избежать проблемы «но это работает на моем ящике».

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

Вы можете использовать виртуальный сервер, чтобы избежать (больших) дополнительных затрат, если вам это нужно.

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

Это должно резюмировать, почему так важно иметь сервер сборки:

http://www.codinghorror.com/blog/2006/10/the-build-server-your-projects-heart-monitor.html

Это панель непрерывного тестирования качества; он показывает вам статистику о том, как обстоят дела с качеством вашего программного обеспечения, и показывает ее вам сейчас. (Юнит, Кобертура)

Это гарантирует, что разработчикам не будут мешать другие разработчики, нарушающие сборку, и побуждает разработчиков писать лучший код. (FindBugs, PMD)

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

Две основные причины, к которым могут относиться нетехнические люди:

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

• Это делает состояние проекта очень очевидным. Я показал своему руководству панель мониторинга состояния сборки, и теперь они смотрят на нее постоянно.

Еще кое-что. Что-то вроде Hudson очень просто настроить — вы можете просто запустить его где-нибудь в углу на некоторое время, а затем показать его позже.

Это мой главный аргумент:

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

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

Вам также не нужно говорить о сборке сервера как о "лезвии, которое стоит руку за ногу". Первый сервер сборки, который я настроил, был настольным компьютером, который стоял без подключения к сети в углу. Он служил нам очень хорошо в течение более чем 3 лет.

Когда у вас есть машина для сборки, вы можете начать добавлять некоторые функции (Hudson великолепен) и реализовывать все, что упоминалось в других постах.

Как только ваша сборочная машина станет незаменимой для вашей организации (и все увидят ее преимущества), вы сможете попросить новый блестящий клинок, если хотите :-)

Самое простое, что вы можете сделать, чтобы убедить вашего работодателя иметь сервер сборки, — это сказать им, что они смогут выпускать быстрее и лучшего качества.

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

Лучшее качество достигается за счет того, что сервер сборки автоматически запускает инструменты обнаружения ошибок каждый раз, когда кто-то проверяет изменения в системе контроля версий. Вы не указываете, какой язык разработки является основным в вашей организации, но такие инструменты, продвинутые, но коммерческие и простые, но бесплатные, существуют практически для всех языков. На ум приходят Lint, FxCop, FindBugs и PMD.

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