SVN продвигает изменения для тестирования и производства

Вау, это на самом деле звучит как хорошая разумная система продвижения, которую вы здесь получили :)

Что касается отслеживания вещей, самый простой ответ, который у меня есть, — это обеспечить соблюдение определенной дисциплины разработчика, то есть включать только 1 CR на каждый коммит.

В Tortoise есть поддержка свойств bugtraq, которые могут вам здесь помочь гарантируя, что каждый комментарий к коммиту включает по крайней мере один номер CR - это может быть полезной подсказкой, чтобы сообщить разработчикам, что если они включают > 1 номер отслеживания для коммита, то они, вероятно, делают это неправильно (если только одно исправление действительно не делает несколько вещей).

Таким образом, это позволит вам объединиться из транка в системный тест только с нужными вам CR. Вы даже можете использовать пользовательский интерфейс слияния черепахи, чтобы увидеть, какие ревизии в магистрали еще не были объединены в системный тест. Но, конечно же, теперь вы захотите перейти от системного тестирования к производству с аналогичной степенью детализации — вот о чем вопрос.

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

Интересно, не лучше ли было бы выполнить слияние в производство из магистрали, а не из системного теста. Теоретически это должен быть один и тот же код — вы сможете отследить, какие ревизии транков находятся в системном тесте, а какие — в продакшене.

Итак, чтобы внести ясность, вы продвигаете ревизию из магистрали в systemtest, тестируете ее, затем, если все в порядке, продвигаете ревизию из магистрали в рабочую среду (возможно, вам придется снова запустить чистую производственную ветку).

Вы должны быть в состоянии написать несколько инструментов, которые используют mergeinfo для подтверждения того, какие версии находятся в системном тесте, а какие нет в рабочей среде. И, используя свойства bugtraq, вы также должны быть в состоянии сказать, какие CR полностью объединены в ту или иную ветку, а у каких еще есть ревизии.

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

Однако имейте в виду, что при этом существует очень реальный риск дрейфа кода между системным тестированием и производством. Я бы рекомендовал регулярно проводить различия между ветвями и следить за тем, чтобы вы могли учитывать все различия. Если две ветки имеют одни и те же ревизии, объединенные из основной ветки, они должны быть идентичными, любые различия должны быть связаны с ревизиями в тесте, которые еще не запущены в производство, и, конечно же, в рабочей среде никогда не должно быть ревизий, которые не в тесте.

Вот классная библиотека/инструмент, который мы используем: Savana. Для каждого тикета разработчик создаст ветку с помощью Savana и, когда она будет готова, вернет эту пользовательскую ветку в магистраль. Аналогичный подход может решить проблему, которую вы представили: вы создаете ветку для любой заданной задачи и объединяете ее обратно с вашим основным магистральным путем, когда придет время.

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

Между тем, некритические проблемы разрабатываются в отношении магистрали и объединяются в периодический выпуск. Повторный выпуск после завершения каждой некритической проблемы (CR в вашем случае) не является стандартной практикой.

Если вы хотите перевыпустить после завершения определенного CR, я думаю, вы должны следовать схеме ветвления функций. Когда вы получаете CR, для которого требуется производственный выпуск, создайте функциональную ветку из ветки производственного выпуска. Когда изменения будут завершены, объедините функциональную ветвь с производственной ветвью, а магистраль и выпустите из производственной ветки.

Вы также можете рассмотреть возможность сокращения цикла выпуска. Частые выпуски уменьшают необходимость внесения изменений в выпущенный код. Бизнес часто может ждать 6-8 недель для внедрения изменений, но не 6-8 месяцев.