Управление версиями - лучшая практика
Все это хорошо, но seq предположительно устарел, и большинство из них работают только с числовыми диапазонами.
Если вы заключите цикл for в двойные кавычки, стартовые и конечные переменные будут разыменованы, когда вы будете эхо-строки , и вы можете отправить строку обратно в BASH для выполнения. $i должен быть экранирован, поэтому он НЕ оценивается перед отправкой на подоболочку.
RANGE_START=a
RANGE_END=z
echo -e "for i in {$RANGE_START..$RANGE_END}; do echo \\${i}; done" | bash
Этот вывод также может быть назначен переменной:
VAR=`echo -e "for i in {$RANGE_START..$RANGE_END}; do echo \\${i}; done" | bash`
Единственный «служебный» ресурс, который должен генерировать, должен быть вторым экземпляром bash, поэтому он должен быть подходящим для интенсивных операций.
7 ответов
Мы используем SubVersion, где теги и ответвления являются дешевыми для создания.
Насколько выпуски идут, мы следуем этой конвенции:
(Главная версия). (Незначительный Выпуск). (Выпуск патча). (Пересмотр SVN)
- Выпуск Патча = исправления ошибок
- Незначительный Выпуск = двоичный файл, совместимый/, взаимодействует через интерфейс совместимый
- , Главная версия = включает повреждающиеся изменения.
, который имеет смысл? При необходимости в большей информации добавьте комментарий, и я отредактирую свое сообщение для разъяснения.
Я работал на поставщика заказного программного обеспечения, который в конечном счете превратился в поставщика решений, когда клиенты решили, что не хотели реализовывать свой собственный callcenters и веб-сайты.
В той среде, у каждого крупного клиента была возможность настроить некоторые аспекты того, как система работала. Таким образом, разработка имела основной продукт с компонентами, характерными для всех контрактов, и отдельные ответвления для каждого клиента (некоторым клиентам были нужны незначительные тонкие настройки, другие главная интеграция с другими системами).
Это работало хорошо, пока бизнес не вырос и количество расширенных ответвлений, часто для размещения действительно хромых изменений. Однажды я думаю, что у них было что-то как 15 различных активных версий той же кодовой базы..., которая сделала вещи действительно негибкими и трудными поддерживать.
не делают то, что мы сделали - заставляют Ваши выпуски масштабироваться!
В моей компании, когда выпуск готов, мы создаем ответвление для главных / номеров подверсии, названных чем-то как R_2_1. Первоначальную версию делают, заставляя снимок перейти или маркировать сразу впоследствии, называют R_2_1_0. Когда ошибки файлов QA против выпуска, изменения кода внесены на эти R_X_Y ответвление, и затем R_2_1_1, ответвление создается для маркировки того выпуска. Таким образом, дерево похоже на это:
Mainline
|
|- R_2_1
| |
| |-R_2_1_0 (locked)
| |
| |
| |-R_2_1_1 (locked)
| |
. .
. .
. .
Мы используем SVN и создаем две ветки для каждого выпуска. Один - это тег исходного кода, использованного для сборки этого выпуска, а второй - новый импорт фактически выпущенных двоичных файлов. Это важно, потому что (независимо от того, сколько вы пытаетесь сделать две машины разработчиков одинаковыми или пытаться поддерживать стабильную машину сборки), когда вы неизбежно попытаетесь восстановить сборку X через 6 месяцев, вы обнаружите, что что-то изменился, и полученный двоичный файл немного отличается.
Незначительные исправления вносятся в ветки, скопированные из ветки с исходным кодом выпуска, и сливаются с основной веткой. Затем можно легко сделать второстепенный выпуск, скопировав ветку с исходным кодом выпуска в новую ветку и добавив необходимые исправления.
Основная работа выполняется в ветвях, скопированных из основной ветви, и слился обратно в багажник по завершении. После этого основные релизы могут быть сделаны из ствола.
Ответ, основанный на структуре ITIL (которая более или менее совпадает с другими).
ITIL классифицирует выпуски на 3 группы: основные выпуски программного обеспечения, второстепенные выпуски программного обеспечения и аварийные исправления программного обеспечения.
Из книг ITIL:
• Основные выпуски программного обеспечения и обновления оборудования, обычно содержащие большие области новых функций, некоторые из которых могут сделать промежуточные исправления проблем излишними. Главное обновление или выпуск обычно заменяет все предыдущие мелкие обновления, выпуски и аварийные исправления.
• Незначительные выпуски программного обеспечения и обновления оборудования, обычно содержащие небольшие улучшения и исправления, некоторые из которых, возможно, уже были выпущены как аварийные исправления. Незначительное обновление или выпуск обычно заменяют все предыдущие аварийные исправления.
• Экстренные программные и аппаратные исправления, обычно содержащие исправления небольшого количества известных проблем
Итак, после этого у вас должно быть:
Основные: v1, V2, v3 и т. Д.
Незначительные: v1.1, V2.1 и т. Д.
Аварийная ситуация: v1.1.1, V2.1.1 и т. Д.
Как говорили другие, лучший способ справиться с управлением выпусками - это ветвление. Я настоятельно рекомендую взглянуть на Руководство по ветвлению TFS ( http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785 ), в котором объясняется несколько подходов к созданию структуры ветвей в зависимости от размер ваших проектов и различные способы предоставления вашего программного обеспечения конечным пользователям (основные выпуски, пакеты обновлений, исправления). Большинство из них не относится к TFS, поэтому вы можете применить их к большинству других систем управления версиями.
Я создал аналогичный вопрос , но я хотел добавить к этому: я настоятельно рекомендую использовать что-то вроде Jira для управления циклом выпуска. Вы можете связать коммиты с запросами / проблемами / ошибками, а затем пометить их как часть выпуска.
В частности, , если вы хотите знать, как управлять хорошим циклом выпуска, посмотрите, как это делает фонд Apache, потому что у них это до науки . Например, вот план для выпусков в проекте Mahout .
Наряду с рабочей системой, которая отслеживает проблемы и объединяет их в пакет выпуска, вы захотите начать интегрировать это с вашей непрерывной интеграцией (я использовал как CruiseControl, так и Hudson) и модульными тестами, чтобы ваш цикл сборки управлялся вместе со всем остальным.