Архитектура хранилища Subversion для отдельных сред Dev / Test / Prod - PullRequest
Новая
       52

Архитектура хранилища Subversion для отдельных сред Dev / Test / Prod

4 голосов
/ 15 июля 2010

Мне было поручено создать систему subversion для сред dev / test / prod, и мне было интересно, есть ли у кого-нибудь опыт работы с подобной средой или предложениями.

Мы строим и настраиваем ряд систем, которые представляют собой комбинацию сценариев и сложных файлов конфигурации для сторонних продуктов. Из-за этого невозможно реструктурировать компоновку файлов конфигурации и путей, потому что мы не контролируем сторонний системный код (то есть, если система хочет файл конфигурации в определенном месте, вот где это должно быть).

Мы работаем с методологией dev / test / prod, но она немного сложнее. Существует полная физическая среда для каждого этапа. В связи с этим каждому этапу необходимо внести некоторые изменения, чтобы он работал в этой среде. Вся разработка должна происходить на сервере разработки, тестирование на тестовом сервере, после чего у нас есть производственные серверы.

При такой настройке невозможно извлечь копию проекта на свою рабочую станцию, внести некоторые изменения, протестировать их и зафиксировать их обратно. Этот материал будет работать только на сервере dev / test / prod (т.е. он привязан к определенным именам хостов и диапазонам IP-адресов).

Итак, на мой взгляд, есть 2 варианта:

Вариант 1

У обычной структуры ствола / веток / тегов. Затем создайте сценарий как часть сборки, который внесет все изменения, специфичные для сред dev / test / prod.

Например, вы будете отправлять весь код в транк как обычно, а затем, когда вы довольны им, вы копируете его в тег выпуска. Затем в тестовой среде вы проверяете последний тег. Это включает в себя сценарий «установки».

Затем скрипт запускается вручную (или через SVN-хук), и он обнаружит, что вы находитесь на тестовом сервере, и внесет соответствующие изменения.

Проблема с этим способом в том, что svn diffs и т. Д. Будут показывать изменения в файлах, которые получают изменения. Преимущество в том, что это (довольно) просто.

Вариант 2

Сделать ветки test / prod и ствол как разработку: 

project
  trunk
  branches
    test
    prod
 tags
    v1.0
    v1.1

Идея в том, что сервер разработчика указывает на trunk. Когда мы довольны изменениями, мы делаем новый тег. Затем мы объединяем его с branches/test. В нем уже будут изменения, необходимые для работы на тестовом сервере. Затем мы сделаем то же самое для prod после завершения тестирования.

Из того, что я вижу, преимущество этого подхода состоит в том, что нет необходимости в причудливых сценариях ловушек, и у нас могут быть более сложные различия между dev / test и dev / prod, которые SVN сможет лучше обрабатывать путем слияния

Просто ищем какой-то вклад, предложения, опыт и т. Д. Мы привязаны к Subversion, и дополнительные инструменты, к сожалению, не нужны.

Спасибо (извините за длину)!

Ответы [ 2 ]

0 голосов
/ 18 ноября 2011

Вариант 2 кажется хорошей архитектурой.Занимался поиском и обсуждением с другими разработчиками

0 голосов
/ 15 июля 2010

Честно говоря, я думаю, что любой вариант вполне жизнеспособен.

Тем не менее, я немного предпочитаю ваш первый выбор, причина в том, что как только вы начинаете получать «известные различия» между определенными ветвями, вы должны начать использовать интеллектуальную силу », это разница между тестом и продуктом, которая должна быть ? "

С опцией 1 вы всегда определенно работаете и строите одну и ту же ветку, один и тот же код, так что вы просто не получите ничего от этого дрейфа. Каждый раз, когда кто-либо вносит изменение, он сразу же видит (если захочет), будет ли это влиять на конкретные среды до того, как они сливаются с ним.

Так что это в основном аргумент, чтобы все было просто. Это тот же аргумент, если вы маркируете свое программное обеспечение в соответствии с вашим клиентом. Любой метод жизнеспособен, но я склоняюсь к варианту 1.

...