Советы по управлению зависимостями для выпуска?

Наша система состоит из множества веб-сайтов .NET, библиотек классов и базы данных MSSQL. Мы используем SVN для управления версиями и TeamCity для автоматической сборки на тестовый сервер.

Наша команда обычно работает над 4-5 проектами одновременно. Мы стараемся объединить множество изменений в крупный выпуск каждые 2–4 недели.

Моя проблема в том, чтобы отслеживать все зависимости для развертывания. Пример:

Веб-сайт A не может работать, пока мы не развернем ветвь X библиотеки классов B, построенную, в свою очередь, на базе библиотеки классов C, для которой требуются обновления конфигурации Y и Z и обновление базы данных D, для которого требуется сценарий миграции E ...

Это становится еще более сложным - например, убедиться, что проекты каждого разработчика действительно совместимы с другими и строятся на одних и тех же версиях. Да, это не только технический вопрос, но и управленческий вопрос.

На данный момент наше неоптимальное решение:

  • список функций доски, которые еще не были запущены
  • полагаясь на нашу память и интуицию при планировании развертывания, пока мы не уверены, что мы все продумали ...
  • пробный запуск нашей промежуточной среды. Это хороший показатель, но мы часто не уверены, что Staging на 100% синхронизирован с Live - часть проблемы, которую я надеюсь решить.
  • некоторое количество крыла в день развертывания.

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

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

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


dependencies release-management versioning process
person realworldcoder    schedule 24.05.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Я предполагаю, что все ваши проекты являются частью всеобъемлющего проекта, для которого существует репозиторий системы управления версиями. В качестве первой меры вы должны попытаться разделить код, находящийся в стадии разработки, и код стабильного / будущего выпуска в ветвях. Настройте Teamcity, чтобы регулярно делать полную сборку стабильной ветки. Если набор изменений готов к выпуску, создатель изменения должен нести ответственность за их слияние вместе со всеми зависимостями в стабильной ветке. Я вам скажу, прошло ли все гладко или нет. Идея CI заключается в том, что вы «всегда готовы к выпуску».

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

  • Если проекты взаимозависимы, почему они разделены? Даже если они развиваются с разной скоростью, действительно ли они должны быть отдельными?
  • Следовательно, у вас есть разные репозитории для каждого проекта? Это сделает выпуск действительно трудным.
  • Можно ли управлять зависимостями на двоичном уровне? Или есть зависимости от времени компиляции?

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

В конце концов, случайная мысль: если бы вы использовали распределенную систему управления версиями (такую ​​как git или mercurial), разместить весь код в одном репозитории было бы очень просто. Каждый проект может иметь свою собственную ветку, которая регулярно обновляется с учетом последних изменений из основной ветки (прямая интеграция). Когда изменение завершено, ветвь проекта снова объединяется с главной ветвью (обратная интеграция). Команда Windows в Microsoft придумала этот рабочий процесс.

person Johannes Rudolph    schedule 24.05.2010
comment
Проекты находятся в отдельных папках в едином репозитории. Примером взаимозависимости является наш веб-сайт, мобильный сайт и API, которые ссылаются на одну и ту же библиотеку бизнес-логики. Это, наряду с некоторыми другими проектами, ссылается на те же служебные библиотеки. Согласитесь, что мы не полностью используем CI, и мне нравится идея стабильных веток. Но это касается кода. А как насчет базы данных, конфигураций, сценариев миграции и других факторов? - person realworldcoder; 24.05.2010
comment
@Andrew: Все это находится рядом с вашим кодом в вашем репозитории svn. - person Johannes Rudolph; 24.05.2010