В проекте, над которым я сейчас работаю, мы используем Subversion и CVS. Разработчики обычно разрабатывают код и проверяют CVS/Subversion.Непрерывная интеграция с Subversion и CVS
Когда кодирование завершено и все проверено, мы помещаем репозиторий с помощью тестовой метки и выполняем формальное тестирование с использованием кода, извлеченного с использованием метки TEST.
Мы не маркируют с помощью TRUNC вместо этого мы используем предыдущий тег:
- Tag RELEASE.0.1 as PROJ-ABC-LIVE.1.3
- Tag revision 12 as PROJ-ABC-LIVE.1.3 (new changes not part of RELEASE.0.1)
выше гарантирует, что только файлы из последней версии + новые ревизии помечены с новой этикеткой выпуска и, таким образом, исключая все, что не было проверено.
После завершения тестирования и внесения дополнительных изменений в код (в результате тестирования) код затем помечен тегом LIVE. Тег LIVE - это код, который выгружается и развертывается на сервере LIVE.
В любой момент, trunc репозитория может содержать любое количество изменений, внесенных людьми. В некоторых случаях люди будут проверять изменения кода, которые «находятся в процессе», и являются неполными. Совершенно нормально, если кто-то что-то проверит и отправится на двухнедельный отпуск.
В качестве примера здесь является статусным пример файла пересмотра в нашем хранилище
1.4
1.5
1.6 PROJ-ABC-TEST.0.1
1.7
1.8 PROJ-ABC-TEST.0.2
1.9 PROJ-ABC-LIVE.1.3
1.10
1.11
Когда мы делаем релиз, мы бы проверить все с тегом PROJ-ABC-LIVE.1.3 и доставить, что, как официальный выпуск. Изменения 1.10 и 1.11 не включены, поскольку в настоящее время в trunc входят новые изменения.
Мне сложно понять, как в этом случае будет использоваться что-то вроде Дженкинса или Хадсона. Что именно он сделает для нас, если мы это представим.
Если мы представим его, не будет ли он каждый раз создавать один и тот же выпуск? Мы строим только теги, поэтому, если я представляю Jenkins/Hudson, мне нужно будет настроить его для создания по тегу. Разве это не просто построить PROJ-ABC-LIVE.1.3 каждый раз, когда он запускается? Если это невозможно, используйте последний тег.
Большинство примеров, которые я видел о том, как используется CI, заключается в том, что большинство людей строят из trunc каждый раз, когда в репозитории происходит изменение (фиксация). Как это будет работать, если люди регистрируют неполные артефакты? Я действительно не понимаю, в чем преимущество построения из TRUNC, если trunc никогда не будет стабильным (что не должно быть).
Возможно, я не очень осведомлен о CM, но как можно отпустить что-то, что создано из Trunc? Я думаю, мои вопросы
- Как CI используется в ситуациях, когда TRUNC включает неполные артефакты
- Если теги используются для всех поставок не будет среда CI заново строить тот же код каждый раз, когда он работает? Меченые снимки никогда не меняются - и, следовательно, среда CI не имеет никакой цели?
- Является ли CI полезным, если мы не строим из trunc? В чем именно заключается преимущество построения от Trunc?
- Единственный способ, который, по моему мнению, может быть нам полезен, если он способен определить, был ли применен новый LIVE-тег и что из него построить. Это возможно?
- Есть ли другие сценарии, где это может быть полезно для нас, что я пропустил?
Благодаря
Постоянный сервер интеграции предназначен для обеспечения стабильности программного обеспечения. Если какой-либо разработчик совершает что-либо, в любом состоянии, в багажнике, и вы считаете, что это нормально, то я не понимаю, зачем вам нужен сервер CI: он будет только подтверждать, что багажник никогда не стабилен, и вам все равно об этом. Возможно, вам стоит подумать, что ваш способ сделать это неправильно, а не думать, что сервер CI бесполезен. –
На самом деле это отличный вопрос. Лично я очень долго занимался тегами с инструментами CI. К сожалению, я пока не нашел решения. Вот мой вопрос по той же проблеме: http://stackoverflow.com/questions/9180648/building-tags-using-continuous-integration – altern