Каковы причины использования сценариев сборки и непрерывной интеграции?

Question

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

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

Какие преимущества мы получаем, используя пользовательские сценарии сборки и такие вещи, как непрерывная интеграция? Вам «нужны» юнит-тесты для этого?

Я также могу упомянуть, что мы разрабатываем на наших локальных машинах, и когда код работает, мы просто обновляем svn checkout на рабочем сервере.

Answer 1

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

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

Также является обычной практикой проведение теста на дым на новой интегрированной сборке.

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

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

Answer 2

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

Это также означает, что как только вы делаете начинаете писать модульные тесты, вы получаете от них еще больше пользы.

Если в данный момент у вас нет скриптов / серверов сборки, как вы строите то, что отправляете? Просто на случайной коробке разработчика?

Также см. ответы на этот связанный вопрос .

Answer 3

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

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

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

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

Answer 4

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

Одно это должно привести к более стабильной версии продукта. Это поможет вам найти проблемы с вашим решением и базой кода раньше, чем когда вы уже развернули / выпустили его. Типичным примером могут быть компоненты, которые были GAC'ами на компьютере разработчика, но отсутствуют в развернутом продукте.

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Мы не используем его для тестирования, мы используем его для резервного копирования нашего процесса тестирования.