Что на самом деле делает CruiseControl? я не могу понять это Для чего я это использую? кто-то сказал мне, что он отслеживает ваши даты сборки и если это успех или ошибка, но действительно, зачем мне это нужно? Я предполагаю, что он может отправить вам электронное письмо, если есть ошибка сборки, но кроме этого (при условии, что она длинная, и я делаю ночные или вечерние сборки), есть ли что-то, для чего я могу ее использовать? как любитель или на небольшой проект с <= 5 чел?
2 ответа
4
Преимущества систем непрерывной сборки чаще всего превозносятся для проектов с несколькими разработчиками, но у них есть некоторые преимущества для небольших команд или индивидуальных разработчиков.
Сначала давайте рассмотрим типичный вариант использования: большой проект с большим количеством коммиттеров. Возможно, что иногда сборка будет нарушена. Возможно, чья-то локальная среда не совпадает с сервером, и они фиксируют код, который компилируется только на их компьютере, или кто-то не проверяет компиляцию своего кода, потому что он спешит, или чья-то проверка не обновлена, когда они редактировать и фиксировать.
В любом случае, сборка теперь сломана. Ошибка должна быть исправлена, но, возможно, неясно, кто на самом деле ее вызвал, и время имеет существенное значение! Когда люди обновляются до головы, у них больше не будет кода, который компилируется, что усложняет им работу.
Мониторинг состояния сборки может помочь избежать многих из этих событий. Как только нарушающий код поступит в репозиторий, сборка не удастся, но они сразу узнают об этом, чтобы люди не проверили это. Поскольку это текущая голова, легче просто вернуться. Даже если люди в конечном итоге получат этот код, по крайней мере, они будут знать, кто его вызвал, и кто его совершил.
Возможно даже (в зависимости от скорости сборки) иметь возможность проверять сборку как зацепку перед фиксацией, предотвращая попадание плохого кода в центральную кодовую базу.
Так что это дает меньшим командам или одиноким разработчикам?
Что ж, возможно, все еще было бы полезно знать, ломается ли сборка, в зависимости от того, каковы ваши рабочие практики с написанием и тестированием кода. В небольших командах, если, в частности, существовало географическое разделение, было бы полезно узнать, что сборка сломана и кто, когда и что сломал ее.
Есть и другие вещи, которые вы могли бы использовать для. Если он настроен, то у вас есть сервер, на котором всегда есть копия последней сборки. Если сервер был подключен к Интернету, у вас теперь есть простой способ опробовать последнюю версию вашего программного обеспечения (например, ночные Firefox и тому подобное). Люди за пределами вашего проекта могут также интересоваться, строится ли код на их платформе или проходит определенные тесты.
Наконец, взгляните на информационную панель CI для Chromium, чтобы понять, какую информацию вы можете получить. Мы можем видеть статус сборки на каждой платформе, фиксации и их влияние на это, статистику покрытия кода, загружать последние сборки, а для сборки, которая не удалась, мы можем видеть, какой тест провалился и что было сообщение об ошибке. Довольно круто!
0
Обычный сценарий использования CruiseControl (и других систем Continous Build [CI], таких как Hudson, Anthill, ...), заключается в регулярной проверке (SCM) центральной системы управления запросами (каждую минуту?) или получить информацию от репо, если есть изменения. Затем CI должен создать код.
В дополнение к этому можно запускать тесты, развертывать артефакты (например, в репозитории Maven или на демонстрационном сервере) в каждой сборке. У вас может быть несколько сборок, например одна, которая будет запускаться при каждом изменении в вашем SCM, и одна, которая будет запускаться каждую ночь во время обеденного перерыва. "Настоящая" сборка CI просто скомпилирует код и выполнит модульные тесты, в то время как "большая" сборка может запустить интеграционные тесты и другие задачи, которые занимают много времени.
ИМХО преимущество системы CI состоит в том, чтобы иметь по крайней мере одну среду здания, которая отличается от машин разработки. Например, среда может быть изменена, чтобы имитировать среду ваших клиентов. Еще одной приятной особенностью является уведомление о сбоях сборки, как только они произойдут. Таким образом, легче понять, когда происходит сбой сборки и как ее исправить.
Вы также можете настроить сборки на компьютере CI, которые должны запускаться вручную, и автоматизировать процесс развертывания (если ваше приложение и клиенты позволяют это). Или создайте сборку, которая создает исполняемый файл для тех, кто не является разработчиком, и для тестирования их необходимо создавать версии снимков вашего приложения.
Система CI довольно универсальна, и ее хорошо иметь даже в небольших командах. Любителю, возможно, не понадобится такой инструмент, но если в нем участвуют как минимум 2 разработчика, хорошо иметь CI!