Как управлять файлами конфигурации среды и целями
Когда вы создаете свое угловое приложение с помощью Angular CLI или Nrwl Nx tools, у вас всегда есть папка с файлами окружения:
<APP_FOLDER>/src/environments/
└──environment.ts
└──environment.prod.ts
Например, вы можете переименовать environment.prod.ts в environment.production.ts, а также создать дополнительные файлы конфигурации для конкретных целей, такие как environment.qa .ts и environment.staging.ts.
└──<APP_FOLDER>/src/environments/
└──environment.ts
└──environment.production.ts
└──environment.qa.ts
└──environment.staging.ts
По умолчанию используется файл environment.ts. Чтобы использовать другие файлы, вы должны открыть angular.json и настроить раздел fileReplacements в конфигурации build и добавить целевые блоки в serve и e2e.
Чтобы создать или обслужить ваше приложение с определенной целью, выполните следующие команды:
ng build --configuration=staging ng start --configuration=staging ng e2e --configuration=staging Actually ng build --prod is just a shorthand for ng build --configuration=production
Создать интерфейс для файлов среды
Не используйте файлы среды напрямую, только через DI
Использование глобальных переменных и прямого импорта нарушает подход ООП и тестируемость ваших классов. Так что лучший вариант - создать сервис для внедрения в ваши компоненты и другие сервисы. Вот пример с возможностью использовать значение по умолчанию.
Различайте конфигурацию среды и конфигурацию бизнеса
Файлы конфигурации среды должны включать только значения, специфичные для среды, например apiUrl. В лучшем случае файлы конфигурации среды должны состоять всего из двух свойств:
export const environment: EnvironmentInterface = {
production: true,
apiUrl: 'https://api.url',
};
Эти файлы могут включать свойство для включения режима отладки debugMode: true. Также вы можете добавить имя сервера развертывания environmentName: «QA», но не забывайте, что для приложения - плохая практика - знать что-либо о сервере, на котором оно работает.
Никогда не помещайте конфиденциальную информацию, такую как пароли или секретные ключи, в файлы среды.
Другие значения конфигурации, такие как maxItemsOnPage или galleryAnimationSpeed , должны храниться в другом месте и в лучшем случае предоставляться некоторым configuration.service.ts, который может запрашивать конечная точка backend или, по крайней мере, загрузите config.json из папки ресурсов.
- Подход с асинхронной конфигурацией (используется, когда конфигурация может быть обновлена во время выполнения)
2. Подход с синхронизацией конфигурации (используйте, когда у вас постоянная конфигурация)
Заменить файлы среды при развертывании или во время выполнения
Многие команды нарушают правило DevOps «Построить один раз, развернуть много», перестраивая приложение для каждой среды, а не просто изменяя конфигурацию и используя одну и ту же сборку.
Не создавайте отдельные сборки с разными конфигурациями, используйте только одну производственную конфигурацию и заменяйте необходимые значения при развертывании или во время выполнения. Сделать это можно несколькими способами:
- Добавьте заполнители в файлы среды, которые будут заменены во время развертывания
export const environment = {
production: true,
apiUrl: ‘APPLICATION_API_URL’,
};
При развертывании строка APPLICATION_API_URL должна быть заменена на соответствующий URL-адрес API, то есть http://api.your-app-server.com.
2. Используйте глобальную переменную и введите ее с помощью томов докеров.
export const environment = {
production: true,
apiUrl: window.APPLICATION_API_URL,
};
// in index.html before angular app bundles
<script src="environment.js"></script>
Спасибо за чтение, не стесняйтесь обращаться ко мне по любым связанным вопросам или исправлениям.
— — — — — — — — — — — — —
🚀 Подпишитесь на нас в Medium, Telegram или Twitter, чтобы узнать больше об Angular, архитектуре программного обеспечения и лучших практиках создания веб-приложений!
