Настройка сложной среды сцены с помощью инструментов с открытым исходным кодом - PullRequest
2 голосов
/ 03 июля 2011

Я некоторое время искал серии трубок и не нашел хороших ответов на этот вопрос, как правило, из-за отсутствия понимания со стороны читателей вопроса о том, каковы варианты использования, поэтому я собираюсь быть мучительно подробно. Например, этот вопрос: Создайте «метку» в subversion, указывающую, какие файлы должны быть в следующем выпуске (ответ с 5 голосами кажется близким, но не совсем там), и этот вопрос: Использование тегов Subversion Развертывание на сервере разработки / постановки / тестирования аналогично моему, за исключением тех, кто пытается ответить, похоже, не совсем понимает тонкости.

Я создаю более сложную промежуточную среду для быстро растущего проекта. Текущая среда состоит из основной производственной ветви вместе со строительными ветвями. Сборки не являются проблемой, так как мы можем просто пометить ревизию заголовка ветки сборки, когда она «сделана», и объединить ее с производством. Более тонкий элемент - это возможность настроить автоматизированный процесс, который помечает произвольный набор файлов с произвольной ревизией для каждого файла с меткой, чтобы вы могли синхронизироваться с этой меткой на промежуточных серверах. Теперь в мире SCM метка перегружена, поэтому я прямо укажу, что в этом случае я использую метку в Perforce (http://www.perforce.com/perforce/doc.current/manuals/cmdref/label.html) смысл слова, означающего имя для набора файлов, где файлы выбраны произвольно ревизии и набор изменчив.

Итак, приведем простой пример. Предположим, у меня есть файлы A и B. Версией заголовка файла A является версия 13 этого файла, а версией заголовка файла B является версия 4. В настоящее время в производстве у нас есть A @ 10 и B @ 2. Изменения в файле A были QAd и были определены, что он готов к исправлению. Первое изменение в файле B (редакция 3) готово к исправлению, но деловая сторона определила, что над головным изменением (редакция 4) нужно потрудиться немного больше, чтобы оно не исправлялось и было перенесено на более позднюю дату , Таким образом, для исправления в производстве нам нужно пометить B @ 3 и A @ 13 для выпуска. Так что здесь все говорят: «О, хорошо, используйте теги в». Так что все хорошо для ночного патча 20110703. Но в сценической среде мы также хотим иметь возможность тестировать файлы не обязательно с заголовками в состоянии, которое лучше всего описать как «если бы мы пометили ветку прямо сейчас, это то, на что это было бы похоже» в течение дня (неделя, месяц и т. д.). Не поймите меня неправильно. Я не хочу делать много кода в производственной ветке, но иногда это необходимо.

Единственное, о чем я говорил до сих пор, это то, что существует также система заявок, в которой коммиты связаны с заданиями / заявками, а задания / заявки связаны с определенной датой выпуска. Таким образом, рабочий процесс заключается в том, что пользователь создает задачу, присоединяет к ней код в виде наборов изменений (с отношением «одна задача ко многим изменениям»), задача проходит процесс утверждения и в конечном итоге крещается как готовая к патч. Затем есть серия автоматизированных сценариев, которые определяют, какие ревизии файлов будут исправлены в день X, и синхронизируют промежуточные среды (или производственные) с соответствующими версиями файлов. Конкретный сценарий, с которым у меня возникают проблемы, - это сценарий, в котором задается набор задач, а через них и их наборы изменений, которые готовы к исправлению, мы можем синхронизировать набор файлов с соответствующими ревизиями, чтобы эмулировать, что будет в будущем производственном исправлении выглядит как. Если бы я использовал перформанс, я мог бы сделать это с помощью меток, которые являются изменяемыми и в основном просто содержат набор значений (имя файла, filerevision), с которыми пользователь может синхронизироваться. Но я собираюсь использовать инструменты с открытым исходным кодом и, в частности, инструменты, которые интегрируются с Redmine (да, мне все еще нужно создать уровень связывания билета с набором изменений).

Итак, мои вопросы.

  1. Существуют ли СКМ с открытым исходным кодом, в которых есть концепция метки?Я немного посмотрел на mercurial и расширение очередей, но, опять же, похоже, оно решает похожую, но не совсем ту же проблему.(не стесняйтесь исправлять меня и говорить: «Нет, очереди решают эту проблему только для этого ...»)
  2. Если нет инструментов, которые бы работали именно так, любые предложения о том, как лучше всего это настроить?Я, конечно, могу написать скрипт, который подделывает ярлыки и вручную синхронизирует каждый отдельный файл, но во многих отношениях он кажется плохим.

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

Спасибо за помощь.

1 Ответ

2 голосов
/ 03 июля 2011

[Этот ответ пытается обобщить обсуждение в комментариях выше.]

Современные DVCS (например, Git, Mercurial) управляют изменениями в виде последовательностей фиксаций, а не наборов файлов.Потому что, если это другая парадигма, трудно придумать «метку», которая выбирает конкретные файлы из определенных ревизий.Коммиты могут касаться нескольких файлов, а коммиты могут касаться и определенного файла (хотя изменения внутри файла могут перекрываться или не перекрываться).

Чтобы управлять поэтапным выпуском с помощью Git, вы можете сделать следующее:

  1. Возьмите ветку предыдущего выпуска.
  2. Извлеките каждую ветку или выберите все коммиты, которые должны быть в следующем промежуточном тесте (вы можете сделать это на рабочей станции разработки).
  3. Перейдите в промежуточный репозиторий.
  4. Извлеките это на промежуточный сервер.
  5. Когда постановка пройдет успешно, вытащите ту же ветку в производство.

В (надеюсь) общем случае, когда нет никаких изменений, которые вы не хотите, тогда шаг 2 становится одношаговым объединением.Если вам не нужны конкретные изменения, вы можете выбрать те изменения, которые вы делаете хотите.

Некоторые полезные ресурсы:

  • Pro Git - бесплатная книга по Git
  • Успешная модель ветвления Git - описание (с фотографиями) одного способа управления несколькими изменениями и промежуточными выпусками с помощью Git
...