For my React Native app, in my dev environment, I've a .env.development file that contains environment variables required by my app, like service endpoint urls, library secret keys, environment and log prefixes etc. In my app I'm consuming those using react-native-config.
How can I define these in App Center? I read here that environment variables defined in App Center config are only for build scripts.
Can I define variables required by my app here and use these or do I have to check in my .env.development into my repo (which I'd rather not if there is a way to avoid it!).
Related
I've deployed React SPA to Azure and its running/started with pm2 serve /home/site/wwwroot --spa --no-daemon command. App build/deploy is done using Github action. We want to have two separate applications for production and test, on separate app services and with different env files. Problem is that by default, pm2 always loads .env.production - even if we set both DOTENV_CONFIG_PATH and NODE_ENV to .env.test and test respectively.
How to force app to load different .env file, depending on Application settings on Azure or by some other method? Apps are essentially the same but they are built using different action (different branch) and they should load different environment settings, depending on which App Service they are hosted. One should use .env.production and other should use .env.test. Local development works fine, it loads .env.development.
I had my app previously deployed on Vercel, but since I'm using Azure AD and MongoDB on Azure, I'm moving the hosting of my app to Azure as well for decreased networking delays.
I set all my environment variables under Configuration -> Application Settings in the Production environment. The private variables (e.g. client secrets) are perfectly readable by my Next.js back-end, but my front-end cannot read the environment variables prefixed by NEXT_PUBLIC, even though this previously worked in my other projects on Vercel and Google Cloud Platform.
Printing the public environment variables (NEXT_PUBLIC_*) to the console returns undefined.
How do I make a distinction between full-stack and server-side environment variables? Because NEXT_PUBLIC does not seem to work.
I found a workaround. Under the build_and_deploy_job -> steps, add a field named env. Under this, you can place your environment variables like this:
env:
NEXT_PUBLIC_VARIABLE: "value1"
NEXT_PUBLIC_ANOTHER_VARIABLE: "value2"
You can find my full .yml file here.
I want to express the fact that this is a suboptimal solution and for the multi-billion dollar company that Microsoft is, you should be able to place public/client-side environment variables directly in your Static Web App via the Azure web portal.
this is a question related to a CRA React app using Azure App Service and Deployment Slots.
We have a Backend API that is specific to each environment, so for "dev" we have a specific API, and for "testing" we have another, basically just different URLS depending on the environment we are in.
This has been solved so far by Pipelines. Building a pipeline from the "dev" branch in the React App, sets the REACT_APP_STAGE to "dev", and we can then check inside the react app which stage we are in, and therefore change the URLs to use.
The tricky part now though, is that we are planning on using deployment slots, which from my understanding, means that we can seamlessly change from Stage -> Prod, without rebuilding the project or using any pipelines. This means that the React App in both of these environments, will have the same REACT_APP_STAGE variable, but they need to be different.
Does anyone have any hints or clues on how to solve this issue regarding different URLS and deployment slots?
I appreciate the time!
https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
Assuming REACT_APP_STAGE is an environment variable, and you want to have a different value for this variable depending on your slot.
If you use the App Service settings, you can mark a configuration value as "sticky", so when you swap the slots, the target environment variables will not swap.
To configure an app setting or connection string to stick to a specific slot (not swapped), go to the Configuration page for that slot. Add or edit a setting, and then select deployment slot setting. Selecting this check box tells App Service that the setting is not swappable.
https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
How are people transitioning between local development with .env files for Node.js to production deployment with Azure app service config settings?
Locally, I use a .env file for settings but on the cloud app service - I use service app settings. My deployemnt using the Azure app service extension deploys my .env file - which I don't want. The only way to stop it is to use a VSCode app setting which doesn't get saved to GitHub.
There has to be a better mechanism.
If you're using the zip deploy, VS Code should automatically add a settings.json file in your ".vscode" folder with a appService.zipIgnorePattern. That setting defines which items to ignore in the deploy. And it should be fine to check that into source control.
I have an ASP.NET Core (RC1) app running on Azure App Service. The app takes its configuration from environment variables. I currently use the Azure Portal's 'Application Settings' page to set these environment variables. The app is deployed with Kudu (if this is relevant?)
I would like a way to programmatically set these environment variables so that I don't have to go through the Azure Portal every time I want to create a new environment variable or modify an existing environment variable. Ideally I would like to do this by calling a REST API. Is this possible, and if so, how?
Instead of setting environment variables in the Azure Portal, you could deploy an appsettings.json file along with your app with the desired settings. If you have a build server or deployment server, you could transform the config file with the correct settings for your environment.
If you i.e. are using Octopus Deploy for deployments, you could use the JSON Configuration variables feature to handle this.
http://docs.octopusdeploy.com/display/OD/JSON+Configuration+Variables+Feature