Какие преимущества предоставляют инструменты непрерывной интеграции в индивидуальном проекте?

18

Если вы делаете сольный проект - будете ли вы использовать инструменты CI для сборки из репозитория? Я использовал Hudson и Cruise Control в командном окружении, где важно создавать, как только кто-нибудь проверяет.

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

iftheshoefritz
источник

Ответы:

12

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

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

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

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

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

Для домашнего проекта один раз в день может быть уже «часто». Основным требованием было бы легко позволить пользователю принудительно запустить сборку.

Klaim
источник
20

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

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

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

Фактически, теперь, когда вы выполняете File | New Project, вам, вероятно, следует включить создание или добавление в свой репозиторий, а также настройку сценария сборки CI и настройку развертывания (даже если это всего лишь архивирование материала для развертывания xcopy).


Приложение (2016) - в настоящее время моя система CI также будет неотъемлемой частью моего процесса развертывания, поэтому ее ценность возросла, и я абсолютно не буду запускать какой-либо поставляемый проект без него. Автоматическое развертывание с помощью кнопок снимает большую нагрузку с процесса, и, в некотором смысле, форма или форма сервера сборки является неотъемлемой частью этого процесса.

Murph
источник
10
+1 как одинокий разработчик вы больше рискуете «работать на моей машине»
jk.
Понижающие голоса без причины не помогают - что не так с вышесказанным?
Murph
+1, я сталкиваюсь с очень похожей ситуацией здесь - множество проектов, которые достаточно малы, чтобы поддерживать каждый из них только одним разработчиком, и один большой проект, поддерживаемый командой Для небольших проектов мы часто сталкиваемся с проблемой, когда кто-то забывает проверить конкретный файл исходного кода. Для большого проекта это никогда не становилось проблемой, так как если одна из команд забывает добавить новый файл в систему контроля версий, другие сразу же будут жаловаться на это. Я должен добавить, что мы собираемся установить CI-сервер в следующем месяце - начиная с небольших проектов!
Док Браун
7

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

make sense

Это конфигурирует, строит, запускает все тесты (с учетом valgrind), запускает линты и т. Д. Поскольку я знаю, что я буду единственным, кто продвинется, мне действительно не нужна мощь чего-то вроде Хадсона.

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

Если он попадает в ситуацию, когда проект четко разделен на подсистемы, у которых есть свои лидеры, вам действительно нужно подумать об использовании чего-то вроде Hudson. Кто-то может провести локальные тесты, проиграть гонку с другой подсистемой и в итоге выдвинуть что-нибудь токсичное.

Кроме того, если вы поддерживаете форк быстро движущегося проекта (например, свой собственный набор патчей для ядра Linux), вам следует подумать об использовании чего-то вроде Hudson, даже если вы «одиноки» в этом проекте. Это особенно верно, если вы разветвляетесь / перебазируете прямо с магистрали.

Тим Пост
источник
11
Обязательно запомните код вашей «смысловой» цели, иначе вы можете получить make: don't know how to make sense. Stop. Argh!
Алан Пирс
@Alan - Они пошли и испортили все наше веселье в более поздних версиях (по крайней мере, GNU make) ... теперь вы просто получаете "make: *** Нет правил для определения цели". Стоп. "
Тим Пост
1
Предлагаю вам перейти на FreeBSD. :)
Алан Пирс
1

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

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

О нет
источник
Мне удается запустить успешное приложение для работы с собственной базой данных без каких-либо затрат на CI-сервер. Это требует небольшой дисциплины в некоторых областях, но меньше, чем накладные расходы на настройку всего этого.
wobbily_col
0

Это важно, если вы хотите сократить время ожидания, чтобы увидеть, все ли идет хорошо. Хотя вы можете заставить свою среду IDE скомпилировать материал для себя сразу после сохранения, она не запускает автоматически модульные тесты, поэтому мой CI-сервер запускает модульные тесты и отчеты о покрытии тестовых случаев и другой анализ качества моего кода, как только Я толкаю это.

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

У меня есть отдельная машина VMWare на том же ноутбуке, которая выполняет сборки для кода, который я вставляю. Для этого я просто получаю образ VMWare для Linux под ключ и устанавливаю jenkins с помощью apt-get и делаю несколько небольших изменений конфигурации.

Архимед Траяно
источник