Рекомендуемые цели сборки

Question

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

Мои мысли для сборки цели являются:

• отладочных: Предназначен для быстрого составления и развертывания. Никакой анализ кода или проверки не выполняются.
• Анализ: Выполняет отладочную сборку, анализ кода и создает документацию.
• Развертывание: Компиляция с соответствующими флагами компилятора для выпуска. Также выполняет те же шаги, что и сборка Analysis.

Я нахожусь на правильном пути здесь? Какие цели построения следует использовать для разработки .NET?

Answer 1

В настоящее время мы используем только CI (непрерывная интеграция или сборка отладки) и Release. Отладочная сборка состоит только из компиляции, анализа кода, тестирования и т. Д.

Релиз, где происходит вся магия (так же, как они всегда говорят в MTV Cribs): управление версиями, подписание кода, упаковка, сжатие, обфускация, документация , и т. д.

Я могу представить себе еще одну цель «Опубликовать» или «Развертывание», которая выполняет выпуск и публикацию на тестовом сервере, где я решаю, когда версия выпуска готова к нажатию на нашу тестовую версию, сервер.

Answer 2

Некоторые из нижеприведенных правил относятся скорее к развитию команды.

Я согласен с ограничением количества конфигураций - каждая конфигурация добавляет к служебным расходам на обслуживание. Поэтому Debug убирается, тогда как Release имеет анализ кода и т. Д. Однако я запускаю CI в сборке Release, так что мне не нужно делать отдельные сборки CI и Release. Это также означает, что любые проблемы с выпуском выпусков будут зависеть от сборки CI, вызванной проверкой, поэтому разработчики получают немедленную обратную связь, если они нарушили (потенциальную) версию. Другая вещь, которую я делаю, - это настройки выпуска, я меняю настройки проекта, чтобы обрабатывать предупреждения как ошибки, так как мне нравится код, предупреждающий об этом; любые предупреждения затем приводят к сбою сборки CI. Поскольку анализ кода создает предупреждения, это означает, что любые нарушения правил ЦС также выйдут из строя CI, что означает, что разработчик будет быстрее исправлен, что поможет обеспечить лучший код качества с самого начала.