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

Question

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

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

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

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

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

В настоящее время наше неоптимальное решение:

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

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

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

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

Answer 1

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

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

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

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

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

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