Зачем автоматизировать сборки?

Question

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

Почему автоматическая сборка (или почему нет)?

Answer 1

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

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

Для дополнительной поддержки, особенно если вы устали, вы можете отправить эту статью от нашего Джеффа Этвуда или эту от Джоэла Спольски. Из этого последнего:

Вот некоторые из многих преимуществ ежедневные сборки:

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

Разработчики могут чувствовать себя в большей безопасности, чем изменение, которое они сделали, не сломается любая из 1024 версий системы которые производятся, на самом деле без иметь ящик OS / 2 на своем столе, чтобы тест на.

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

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

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

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

Answer 2

Позвольте мне начать с явного срыва Википедии. Имейте в виду, что это общие преимущества непрерывной интеграции, из которых ночные сборки следует рассматривать как частичную реализацию. Очевидно, что ваша система будет более мощной, если вы объединяете ночные сборки с вашим автоматическим (модульным, функциональным и т. Д.) Тестами.

Преимущества:

• когда модульные тесты не выполняются или возникает ошибка, разработчики могут вернуть кодовую базу обратно в состояние без ошибок, не тратя время на отладку
• разработчики постоянно обнаруживают и устраняют проблемы интеграции - избегая хаоса в последнюю минуту в даты выпуска (когда все пытаются проверить свои слегка несовместимые версии).
• раннее предупреждение о неработающем / несовместимом коде
• раннее предупреждение о конфликтующих изменениях
• немедленное юнит-тестирование всех изменений
• постоянная доступность "текущей" сборки для тестирования, демонстрации или выпуска
• немедленная обратная связь с разработчиками о качестве, функциональности или общесистемном влиянии кода, который они пишут
• частая регистрация кода подталкивает разработчиков к созданию модульного, менее сложного кода
• метрики, сгенерированные из автоматического тестирования и CI (такие как метрики для покрытия кода, сложности кода и завершенных функций), фокусируют разработчиков на разработке функционального, качественного кода и помогают развивать импульс в команде

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

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

Answer 3

Я думаю, что ...

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

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

• Код, который вы не можете развернуть, является бесполезным кодом.
• Интеграция изменений кода с изменениями кода других людей в команде.
• Иногда я забываю запустить ALL модульные тесты, прежде чем регистрироваться. Мой CI-сервер никогда не забывает.
• Централизованный статус вашего кода, который может помочь в общении. (Если я проверил неработающий код и кто-то еще должен быть развертыванием ... ну, это восходит к моей любимой причине.)

Answer 4

Потому что,

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

2. Автоматически получает последние файлы Checked-In и компилирует их, поэтому любая ошибка компиляции, вызваннаядругие сообщения.

3. Мгновенное подтверждение по электронной почте при сбое и успешном выполнении сборки.Таким образом, вы получите, кто не смог построить.

4. Может быть интегрирован с Code Standard Tool, таким как FX Cop, Style Cop для .Net.Поэтому при сборке он автоматически проверяет стандарты кодирования.

Answer 5

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

Answer 6

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