Какие преимущества дают инструменты непрерывной интеграции в индивидуальном проекте?
-
22-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Если вы работаете над индивидуальным проектом, будете ли вы использовать инструменты CI для сборки из репозитория?Я использовал Hudson и Cruise Control в командной среде, где важно начинать работу, как только кто-то что-то проверяет.
Я думаю, что ценность контроля версий по-прежнему очевидна, но нужно ли мне выполнять сборку после каждого коммита, ведь я бы просто собирал на своей локальной машине, и никто больше не делал коммитов?
Решение
Ну, я планирую использовать инструмент непрерывной интеграции в проекте, и я уникальный разработчик. Необходимость приходит потому, что
- Одна цель состоит в том, чтобы сделать его кроссплатформенным, а наличие инструмента интеграции поможет вам подразумевать (базовое) проверить ваше приложение на нескольких платформе, как только вы нажмете свои изменения в репозитории интеграции (или в центральном, или что-то в этом роде, которое будет использоваться в качестве авторитетного).
- Проект построен в течение длительного времени, поэтому мне нужно будет работать с командой позже. Я не планирую набирать кого -либо до 2012 года, чтобы непрерывная интеграция могла ждать на данный момент, пока 1. станет приоритетом.
Кроме кроссплатформенного и подготовки к команде, я не вижу необходимости. Главное - иметь какое -то программное обеспечение для управления источником и иметь несколько репозиторий, чтобы сохранить резервные копии. Это поможет вам настроить инструменты сборки вокруг него при необходимости.
Что касается времени сборки, я использую Mercurial и настраиваю репозиторий интеграции, который не является хранилищем командной работы. Итак, продвигайте изменения в командной работе, пока я не почувствую, что пришло время заставить систему интеграции попытаться создать. Затем я перейду от командной работы к репо интеграции, и это запустит сборку. Затем я также добавляю сценарий, который будет тянуть репо командную работу в репо интеграции один раз каждый день.
Здесь я предполагаю, что работаю почти все дни над своим проектом, но это не всегда так. Вы должны установить время сборки, которое относится к тому, как часто вам нужны сборки. В игровой компании, в которой я работал раньше, мы использовали CruiseControle, и каждый час строил полную сборку. Мы также могли бы заставлять сборку, когда захотим, если это необходимо.
Для домашнего проекта один раз в день может быть уже «часто». Основным требованием было бы легко позволить пользователю запускать сборку.
Другие советы
После короткого созерцания я бы предположил, что это может быть даже более Важно для соло -разработчика, чем для команды.
На самом основном уровне сервер CI демонстрирует, что вы можете создать свое приложение с нуля из преданного источника - в сочетании с приличным набором тестов, он должен продемонстрировать, что вы можете создавать и работать с нуля.
Поскольку одна из вещей, которые я пытаюсь сделать, это убедиться, что моя сборка включает в себя развертываемый пакет, вы также знаете, что вы можете получить что -нибудь для развертывания (чисто и из известного состояния/версии).
Фактически, теперь, когда вы делаете файл | Новый проект, вы, вероятно, должны включить создание или добавление в свой репозиторий и настройка своего скрипта CI Build и развертывания (даже если это только для того, чтобы застегнуть кучу вещей для развертывания XCOPY)
Addendum (2016) - В настоящее время моя система CI также будет неотъемлемой частью моего процесса развертывания, поэтому ее стоимость увеличилась, и я абсолютно не буду выполнять какого -либо поставленного проекта без него. Автоматизированное развертывание кнопок снимает много напряжения из процесса, а каким -то образом форма или сформирование сервера сборки является неотъемлемой частью этого.
Когда я один принимаю коммит, я просто создаю и тестирую до фактически совершая.Обычно я использую целевой файл makefile, например:
make sense
Он настраивает, собирает, запускает все тесты (с поддержкой valgrind), запускает проверки и т. д.Поскольку я знаю, что буду единственным, кто будет давить, мне не нужна сила чего-то вроде Хадсона.
Кроме того, в среде, где у вас есть несколько веток, питающих основной репозиторий, если все следуют принципу «всегда получать», прежде чем вы фиксируете или отправляете, CI-сервер может быть немного перегружен.Хорошо написанное правило, согласно которому автор того, что сломало последнюю сборку, покупает пиццу в пятницу, обычно обеспечивает бесперебойную работу :)
Если попадет в ситуацию, когда проект четко разделен на подсистемы, имеющие своих лидеров, вы Действительно нужно подумать об использовании чего-то вроде Hudson.Кто-то может провести локальное тестирование, проиграть гонку с другой подсистемой и в конечном итоге выпустить что-то токсичное.
Кроме того, если вы поддерживаете ответвление быстро развивающегося проекта (например, свой собственный набор исправлений для ядра Linux), вам действительно следует рассмотреть возможность использования чего-то вроде Hudson, даже если вы работаете в этом проекте «один».Это особенно актуально, если вы выполняете ветку/повторную базу непосредственно из основной ветки.
Я бы не сказал, что это просто хороший бонус, я бы сказал, что он жизненно важен для высококачественной разработки программного обеспечения для нас сольных художников. Большинство из нас позволят своим стандартам качества немного скользить, если в спешке, если они думают, что это достаточно легко исправить позже. Если вы совершаете программное обеспечение в этом состоянии, у вас, по сути, есть бесполезная кодовая база, хранящаяся в вашем управлении источником.
Если придерживаться должным образом (то есть, вы не пропускаете тесты и убедитесь, что они строится каждый раз, когда вы совершаете) CI заставляет вас придерживаться стандарта более высокого качества, чем если бы вы просто совершили его в любом случае.
Важно, если вы хотите сократить время ожидания, чтобы увидеть, все ли все еще идет хорошо. Хотя вы можете заставить свою IDE компилировать для вас вещи, как только вы сохраняете, он не автоматически запускает модульные тесты, поэтому у меня есть мой сервер CI запустить модульные тесты и отчеты о покрытии чехлов и другой качественный анализ моего кода, как только Я толкаю это.
Единственный триггер, который я должен сделать, - это продвинуть мои текущие изменения в управлении версиями, и я могу вернуться к кодированию. И хотя я думаю о кодировании, система CI занята, пробивая длинные отчеты о качественных качествах, которые я буду смотреть сразу от времени, когда мой мозг выйдет в затишье.
У меня есть отдельная VMware Machine на том же ноутбуке, которая выполняет сборки для кода, который я нажимаю. Для этого я просто получаю изображение VMware Linux Linux и устанавливаю Jenkins, используя Apt-Get и сделаю несколько незначительных изменений конфигурации.
