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

Ответ 1

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

Поскольку,

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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