Два Environment.ts, чтобы управлять ими всеми.

Или почему большинство людей до сих пор неправильно используют Angular CLI.
Angular CLI (швейцарский армейский нож для разработки под angular) — хорошо известный инструмент в сообществе разработчиков Angular. Большинство фронтенд-разработчиков используют его в повседневных задачах при создании приложений на основе Angular 2+, но используем ли мы его так, как предполагалось?

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

Если вы работаете над относительно небольшим приложением, с парой страниц и меньшим количеством модулей, и в нем нет обязательных правил или процесса управления выпуском, вы можете свободно использовать столько environment.ts, сколько пожелаете, а когда придет время, просто предоставить среду в качестве аргумента сборки для CLI и продемонстрировать свое новое, блестящее угловое приложение, но что произойдет, если вы работаете над сложным корпоративным веб-приложением со многими модулями и строго контролируемым жизненным циклом выпуска? Что, если в вашей компании автоматизирован процесс CI/CD, и как только ваш PR будет объединен с основной или релизной веткой, вы потеряете над ним весь контроль? С этим столкнулись многие компании при разработке SPA. Проблема стала еще более заметной, когда поставщики узнали, что они должны не только создавать SPA на основе Angular с помощью автоматизированного конвейера CI, но и передавать его своим клиентам, чтобы они могли развернуть его в своей внутренней инфраструктуре.

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

Давайте рассмотрим пример простого приложения, в котором применяются следующие правила CI/CD;

Управление версиями приложения должно выполняться с помощью semver;
Любая сборка должна выполняться на каком-либо сервере сборки.
Релизы должны храниться в репозитории и передаваться по конвейеру компакт-дисков.
Каждый выпуск должен быть сначала развернут в среде QC.
После прохождения контроля качества он должен быть перемещен в среду UA и протестирован пользователями.
Если тест среды UA пройден, выпуск должен быть официально объявлен, и приложение должно быть выпущено.

Чтобы добиться этого, большинство разработчиков angular сразу подумали о том, чтобы создать 3 отдельных файла конфигурации среды и среду pas в качестве аргумента для Angular CLI во время процесса сборки, поэтому мы явно указываем CLI, для какой среды мы строим, и это может Это вполне допустимый подход, но давайте ненадолго вернемся назад и взглянем на конвейер выпуска, который мы перечислили выше. Управление версиями приложения должно выполняться с использованием semver, это означает, что после того, как сервер сборки создаст приложение и поместит его в конвейер развертывания, одна и та же версия должна пройти через все среды до конечного пункта назначения (выпуск в производство). Теперь представьте, что система сборки устанавливает номер сборки при запуске сборки релиза. Здесь мы уже сталкиваемся с блокировщиками, и вот почему.

В какой среде сервер сборки должен выполнять первоначальную сборку? Вы можете ответить на QC, но не забывайте, что жизненный цикл выпуска диктует, что одна и та же сборка должна быть перемещена через среды и, наконец, выпущена, и, поскольку сервер сборки меняет номер сборки при каждой сборке, передача приложения из одной среды в другую приведет к тому, что система сборки будет перестраиваться, предоставляя другую среду и увеличение номера сборки. В результате у нас будут такие релизы, как 18.2.1.3, 18.2.1.6, 18.2.1.9. Вы видите, что мы уже пропускаем 3 второстепенные версии только для того, чтобы довести приложение до рабочей версии из-за этой перестройки каждый раз, когда мы хотим развернуть его в другой среде.

Хорошо, достаточно проблем, мы хотим решения!
Должен быть какой-то способ справиться со всем этим, вы могли бы сказать, и ответ на этот вопрос, безусловно, большой ДА. Итак, как мы можем справиться с таким развертыванием в масштабе предприятия и остаться в рамках правил и процессов? Конечно, мы по-прежнему будем использовать файлы environment.*.ts, но вместо создания каждого файла среды, что, если мы создадим только два из них? Что, если бы у нас были только Environment.release.ts и environment.ts, и в качестве примера во время разработки мы использовали environment.ts, а файл среды, который наш сервер сборки когда-либо использовал бы, — environment.release.ts?

Основное различие между этими двумя файлами заключается в том, как они определены внутри. В то время как в обычном файле среды у вас есть определенные значения, внутри файла release.ts вы всегда будете использовать токены вместо прямых значений и позволить автоматизации развертывания позаботиться о замене этих токенов реальными значениями в зависимости от целевой среды развертывания. В результате запись в обычном файле environment.ts типа ApiEndpoint = ‘ станет ApiEndpoint = ‘${ENDPOINT_TOKEN}’ (примером токена здесь является стиль развертывания Octopus, но большая часть программного обеспечения для автоматизации развертывания поддерживает замену переменных во время развертывания) и то, что мы теперь остается очень чистый процесс автоматизации, в котором одна и та же версия сборки может быть развернута по всему конвейеру и выпущена под той же версией, созданной агентом сборки изначально.

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