Лучшие практики для управления и развертывания артефактов для различных сред (dev, test, prod и т. Д.)

Question

Я новичок в мире CI / CD, и теперь я хотел бы реализовать эти рабочие процессы в моем процессе разработки.Я хотел бы понять, как правильно создать конвейер сборки и выпуска для управления средами Dev, Test и Prod, когда у Dev, Test и Prod есть небольшие различия.

Итак, я делаю приложение Asp .Net Core,код размещен в DevOps Azure, который я буду использовать также для сборки и выпуска, для кода на стороне клиента (js и css) я использую Typescript и SASS, а для компиляции в js и css я использую сценарии npm.

Сейчасв среде Dev я хочу развернуть неинициализированные js и css, а также хочу файлы исходных карт, в среде Test вместо этого я хочу минимизированные js и css и файлы исходных карт, в среде prod мне нужна только минимизированная версия моегоcss and js.

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

Теперь я могу выбирать между различными вариантами:

1. Я могу управлять различиями на этапе сборки :
2. У меня может быть один конвейер сборки, который производит «стандартный» клиентский код, исходную карту и минимизированные версии и развертывает одни и те же артефакты в Dev, Test и Prod;
3. У меня может быть другая сборкаконвейер для другой среды;
4. Я могу иметь один конвейер сборки и использовать условные задачи;

Я могу управлять различиями на этапе выпуска :

1. Я могу создать код, используя опцию 1.1, а затем исключить файлы, которые мне не нужны вконвейер выпуска;
2. Я могу собрать только код на стороне сервера в конвейере сборки и скомпилировать код на стороне клиента во время конвейера выпуска;
3. Я могу скомпилировать стандартную версию файлов js и cssв конвейере сборки и в конвейерах выпуска я могу создать исходную карту или минимизировать js и css;

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

Опции 1.2 и 1.3 добавляют некоторую сложность конвейерам сборки.

С опциями 2.x у нас есть «неполные» сборки, потому что артефакты, создаваемые процессом сборки, не содержат некоторых артефактов, которые требуются в среде развертывания.

Мне, чтоich Я не знаю, каковы руководящие принципы и лучшие практики для рабочих процессов CI и CD, кажется, что гораздо более подходящим является вариант 1.3 или 2.3.

Если я не ошибаюсь,вопрос стал: Допустимо иметь конвейеры сборки, которые производят артефакты, которые не могут быть полностью отправлены, поскольку они не отвечают требованиям для среды развертывания (например, необходимость иметь исходную карту в среде Dev)?

Answer 1

Чао Леони,

Я работаю менеджером по выпуску уже несколько лет, и я понимаю вашу боль.В системе, над которой я работал, последовательность была примерно такой: 1: от домена разработки до промежуточного сервера 2: от промежуточного сервера до среды тестирования на проникновение и уязвимость 3: от тестового домена до рабочего домена SaaS и репозитория DML.4: из рабочего домена в условное депонирование и установленное сокращение.

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

Как только документированный процесс согласован,людям легко использовать это как контрольный лист.Ваши процессы, возможно, должны отличаться от того, что я изложил выше, и они должны быть уточнены со временем.Я знаю многих людей, которым не нравятся документированные процедуры, но я задокументировал здесь некоторые преимущества: http://www.esm.solutions/wp/change-management/

A presto, Роберт