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

Я работал над SCM семь месяцев, выбрал Visual SVN в качестве сервера и черепаху svn в качестве клиента. На данный момент я завершил свой семимесячный путь по управлению конфигурацией приложений ERP. Я хочу знать, следую ли я лучшим практикам: есть следующие сомнения:

Project -------> Branches, trunk, tags.
  1. Нужно ли создавать ветку для конкретной задачи (пока я не слежу за этим процессом)

  2. Добавлен базовый проект в ветвление, и после нескольких коммитов в один и тот же день создайте приложение, если какие-либо проблемы сборки отслеживают проблему, отслеживая журналы приложения и закрывая проблемы.

  3. Если было совершено больше задач, основной выпуск, например. 1.0, 2.0, если младший 1.1, 2.1, 2.2 и т. Д., И добавление снимка кода проекта основной версии в теги.

  4. Разрешить разработчикам делать коммиты в ветке, создавать контрольную копию на тестовом сервере, создавать приложение, обновлять последние коммиты до контрольной копии на тестовом сервере с помощью svn update и строить приложение.

Я следую этому механизму, пожалуйста, дайте ваши ценные комментарии и предложения, если этот процесс неправильный. .


person Gopinath    schedule 14.06.2011    source источник


Ответы (1)


По первому вопросу:

Нужно ли создавать ветку под конкретную задачу.

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

В любом случае: есть вопрос о переполнении стека: Лучшая стратегия ветвления при непрерывной интеграции? что обсуждают эту тему.

person Ralph    schedule 15.06.2011