Использование 2 SVN репозиториев для сайта - вопрос публикации - PullRequest
0 голосов
/ 07 сентября 2011

Я полный нуб к этому, так что, если есть совершенно очевидный ответ, во что бы то ни стало высмеивайте и указывайте и смейтесь, тогда дайте ответ.

Мы используем Visual Studio 2010 для компиляции нашего опубликованного сайта.У меня есть репозиторий, который я использую для моего исходного кода, и тот, в котором я публикую скомпилированный код.Затем я проверяю репозиторий публикации на тестируемом сервере и, как только он проверяется, я проверяю репозиторий на моем главном сервере.Это нормально и все, но я использую Tortoise SVN и автоматизирую коммит.Проблема в том, что мне действительно нужно стереть опубликованный репозиторий SVN, затем скопировать файлы и зафиксировать.Я просто не могу этого добиться, и он все еще распознает его как хранилище SVN.Предложения?

Ответы [ 4 ]

1 голос
/ 07 сентября 2011

Прежде всего, не помещайте скомпилированный код в ваш исходный репозиторий. Это плохая форма.

Посмотрите на Jenkins как сервер сборки. Дженкинс может использовать команду msbuild.exe для создания .NET проектов с использованием файла .sln, который создает ваш проект.

Когда вы делаете коммит в Subversion, Дженкинс автоматически запускает сборку. Если у вас есть тесты NUnit, Дженкинс выполнит их и даст вам результаты. Вы можете попросить Дженкинса сохранить скомпилированные файлы в своем архиве. Если кто-то хочет установить конкретную сборку, он может напрямую загрузить ее с Jenkins без предварительной проверки в Subversion.

Дженкинс предлагает все эти преимущества:

  • Он показывает вам все изменения в вашем хранилище и что изменилось в каждом коммите.
  • Он может запускать все виды тестов автоматически для вас.
  • Вы можете пометить сборки, выпущенные с помощью плагина "Simple Promotion".
  • Вы можете пометить сборки в Subversion непосредственно в Jenkins, не нуждаясь в командной строке или рабочем каталоге.
  • Он может предупредить разработчиков, если сборка не удалась из-за плохого кода или если тестирование не удалось. Эти оповещения могут быть отправлены через электронную почту, мгновенные сообщения, телефонные текстовые сообщения, Twitter и многими другими способами. Все, что нужно, это правильный плагин, который Jenkins позволяет легко установить.
  • Jenkins может выступать в качестве репозитория релиза, который позволяет легко найти релиз, что находится в релизе и почему.
  • Jenkins интегрируется с Bamboo, ViewVC и Sventon. Это веб-браузеры для хранилищ. Таким образом, Дженкинс показывает не только измененный файл, но и то, что изменилось в файле.

Jenkins прост в использовании и установке. Загрузите его и попробуйте.

0 голосов
/ 29 сентября 2011

Проблема в том, что мне действительно нужно стереть опубликованный репозиторий SVN, затем скопировать файлы и зафиксировать.

Вы не нуждаетесь в стирании в репо. Просто сделайте коммит для производственного репо с экспортированным HEAD из dev-repo (ловушка после фиксации для сообщения коммита)

А метки, да, являются более естественным и пуленепробиваемым способом.

0 голосов
/ 07 сентября 2011

Наличие репозитория для опубликованного кода действительно ничего вам не дает. IMO, вам лучше иметь кучу zip-файлов (по одному на выпуск) с указанием даты и ветки SVN в названии. НУЖНО иметь файл changelog .txt в zip, а также проверить это в репозитории.

0 голосов
/ 07 сентября 2011

Если у вас нет жестких и быстрых требований, которые заставляют вас использовать два отдельных репозитория, я бы посоветовал взглянуть на функциональность SVN-тегов и ветвления.

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html

...