В проекте, над которым я сейчас работаю, мы используем как Subversion, так и CVS.Разработчики обычно разрабатывают код и регистрируются в CVS / Subversion.
Когда кодирование завершено и все проверено, мы помечаем хранилище с помощью метки теста и проводим формальное тестирование с использованием кода, проверенного с помощью метки TEST.
Мы не помечаем, используявместо усечения мы используем предыдущий тег:
- 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.
В любой момент усечение репозитория может включать любое количество изменений, сделанных людьми.В некоторых случаях люди регистрируют изменения кода, которые «находятся в процессе выполнения» и являются неполными.Это совершенно нормально для кого-то проверить что-то и пойти на двухнедельный отпуск.
В качестве примера приведен пример состояния файла ревизии в нашем хранилище
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, если усечение никогда не бывает стабильным (чего не должно быть).
Возможно, я не очень разбираюсь в CM, но как можно выпустить что-то, что построено из Trunc?Я предполагаю, что мои вопросы
- Как CI используется в ситуациях, когда усечение включает в себя неполные артефакты
- Если теги используются для всех доставок, среда CI не будет перестраиватьодин и тот же код каждый раз, когда он работает?Снимки с тегами никогда не меняются - и, следовательно, среда CI не имеет смысла?
- Полезен ли CI, если мы не строим из trunc?В чем именно заключается преимущество построения из Trunc?
- Единственный способ, которым я думаю, может быть полезен для нас, если он способен обнаружить, был ли применен новый тег LIVE и создан из этого.Это возможно?
- Существуют ли какие-либо другие сценарии, в которых нам было бы полезно пропустить?
Спасибо