Answers: <p>This is a general issue with react apps that is independent of what CI/CD stack you use that is discussed at <a href="https://stackoverflow.com/questions/49975735/rendering-an-environment-variable-to-the-browser-in-a-react-js-redux-production">https://stackoverflow.com/questions/49975735/rendering-an-environment-variable-to-the-browser-in-a-react-js-redux-production</a></p>
  
  <p>With the Azure family of CI/CD products it is expected you create a release artefact then release that same artefact into environments using a release workflow. That is a typical best practice and expected by ”enterprise” release management processes. The general manifesto of native cloud apps is 12factor.net, and it also advises to ”build once, deploy many times, configured by environment variables”. So its a bit of a surprise to me that the best practices isn't really known in the react community so you have to hunt around for solutions. </p>
  
  <p>In my case at that link above I didn't want to make deployments of our react apps different from our backend microservices where we have ”build once, run anywhere”. So we chanced the js code to fetch env vars from the server at page load. Also with this approach and by using containers we are guaranteed to always run the same front end libraries everywhere even if the front end build tool is misconfigured or buggy in terms of not always using the exact same dependency on every run. </p>
  
  <p>In your case you do have a release workflow where you can use all the same built-in and marketplace tasks of a build workflow. This means its straight forward to add a front-end compile task to the release workflows. </p>
  
  <p>On the downside a frontend build of a large react app can take a lot of time and a lot of memory. Memory probably won't be an issue for you. The time taken will be a little annoying. Yet the approach wouldn't be invasive so I would recommend it may be the least effort to set up and the easiest for colleagues to troubleshoot and maintain in the future as long as you have a stable frontend build. Historically npm was less reliable than other frontend builds at giving the exact same lib versions every run for the same package.json (e.g., npm vs. yarn). So you need to study that aspect and ensure that you are certain that every time you run the frontend build it is guaranteed to use the same exact dependency versions. </p>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-31T21:45:55.933Z
Answers: Yes, I thought about building the frontend on the release pipeline, but the problem is how to actually get the frontend source into the release pipeline? Release jobs in TFS 2018 doesn't have a "Get Sources" step, so it cannot be fetched from the repo. We could use a command line step and pull the repo from there, but it feels hacky.
  The other option is publish the frontend src code as an artifact, but the node_modules folder is huge and takes a lot of time to publish.
Answers: empz
Answers: CC BY-SA 4.0
Answers: 2019-01-31T21:47:55.677Z
Answers: I still don't quite understand what you mean by "we changed the js code to fetch env vars from the server at page load". What's the server in this case? In my case the frontend is just a pure static website. The URL of the API is generated during the build by webpack. As I see it, this solution still needs a way to tell the frontend where to fetch the env. vars. from.
Answers: empz
Answers: CC BY-SA 4.0
Answers: 2019-01-31T23:16:49.180Z
Answers: A react app is a package.json that webpacks a static site. So just add something like this https://github.com/simbo1905/react-redux-realworld-example-app/blob/master/server.js that repo is a fork of a pure spa single page app with that small express server added to serve up env var and a minor mod to the html page to load a /env.json from that small server.
Answers: simbo1905
Answers: CC BY-SA 4.0
Answers: 2019-02-01T13:33:51.387Z
Answers: Yeah, I can't use a server. This is hosted as a pure static website in a CDN. No server-side code allowed.
Answers: empz
Answers: CC BY-SA 4.0
Answers: 2019-04-10T01:03:45.500Z
Answers: @emzero Release pipelines very much do in fact have a way to "get sources" from a Git repo.  Add an [artifact source](https://docs.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops#sources) that is a linked Git repository and it will perform a fetch on it before the rest of the pipeline starts such that the code artifacts from the Git repo are present.
Answers: Sumo
Answers: CC BY-SA 4.0
Answers: 2019-01-26T08:54:13.430Z
Answers: 2019-01-26T09:16:37.970Z
Answers: 2019-01-26T09:16:37.970Z
Answers: simbo1905
Body: <p>So I have an application that contains an ASP.NET Core backend and a React frontend (pure static).</p>
  
  <p>In our TFS 2018, we have created a Build that does the following:</p>
  
  <ul>
  <li>Get sources from the repo</li>
  <li>Get Nuget packages (backend)</li>
  <li>Build the backend</li>
  <li>Run backend tests</li>
  <li>Get NPM packages (frontend)</li>
  <li>Build the frontend</li>
  <li>Run frontend tests</li>
  <li>Generate and publish artifacts</li>
  </ul>
  
  <p>Then, a Release pickups those artifacts and deploy them to an Azure AppService (backend) and an Azure Storage v2 account (frontend).</p>
  
  <p>We currently have only one environment, but we need to support multiple ones. The problem is that the frontend build depends on some environment variables which are not present during the build stage. The build doesn't know where is it going to be deployed yet.</p>
  
  <p>So there are a few options here:</p>
  
  <ul>
  <li>Generate the frontend build in a Release. This needs a way for the Release to get access to the sources, either via Git or by getting it from an artifact. Latest is really slow because of all the npm_modules.</li>
  <li>Build should produce builds artifacts for all posible environments and each Release environment will pick up the proper one. </li>
  </ul>
  
  <p>What's the recommended approach to handle this on TFS 2018?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-01-26T07:47:58.633Z
Comments: This is a general issue with react see the q&a at https://stackoverflow.com/questions/49975735/rendering-an-environment-variable-to-the-browser-in-a-react-js-redux-production
Comments: simbo1905
Tags: <azure><azure-devops><tfs><azure-pipelines><environments>
Title: How to setup multiple build environments in Azure DevOps/TFS2018?
UserDisplayName: empz
ThreadText: # How to setup multiple build environments in Azure DevOps/TFS2018?
  
  (Asked by: username_0 on 2019-01-23)
  
  So I have an application that contains an ASP.NET Core backend and a React frontend (pure static).
  
  In our TFS 2018, we have created a Build that does the following:
  
  * Get sources from the repo
  * Get Nuget packages (backend)
  * Build the backend
  * Run backend tests
  * Get NPM packages (frontend)
  * Build the frontend
  * Run frontend tests
  * Generate and publish artifacts
  
  Then, a Release pickups those artifacts and deploy them to an Azure AppService (backend) and an Azure Storage v2 account (frontend).
  
  We currently have only one environment, but we need to support multiple ones. The problem is that the frontend build depends on some environment variables which are not present during the build stage. The build doesn't know where is it going to be deployed yet.
  
  So there are a few options here:
  
  * Generate the frontend build in a Release. This needs a way for the Release to get access to the sources, either via Git or by getting it from an artifact. Latest is really slow because of all the npm\_modules.
  * Build should produce builds artifacts for all posible environments and each Release environment will pick up the proper one.
  
  What's the recommended approach to handle this on TFS 2018?
  
  **Tags:** azure, azure-devops, tfs, azure-pipelines, environments
  
  > **Comments:**
  > **username_1**: This is a general issue with react see the q&a at https://stackoverflow.com/questions/49975735/rendering-an-environment-variable-to-the-browser-in-a-react-js-redux-production  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-01-26. Score: 1 | Accepted answer
  
  This is a general issue with react apps that is independent of what CI/CD stack you use that is discussed at <https://stackoverflow.com/questions/49975735/rendering-an-environment-variable-to-the-browser-in-a-react-js-redux-production>
  
  With the Azure family of CI/CD products it is expected you create a release artefact then release that same artefact into environments using a release workflow. That is a typical best practice and expected by ”enterprise” release management processes. The general manifesto of native cloud apps is 12factor.net, and it also advises to ”build once, deploy many times, configured by environment variables”. So its a bit of a surprise to me that the best practices isn't really known in the react community so you have to hunt around for solutions.
  
  In my case at that link above I didn't want to make deployments of our react apps different from our backend microservices where we have ”build once, run anywhere”. So we chanced the js code to fetch env vars from the server at page load. Also with this approach and by using containers we are guaranteed to always run the same front end libraries everywhere even if the front end build tool is misconfigured or buggy in terms of not always using the exact same dependency on every run.
  
  In your case you do have a release workflow where you can use all the same built-in and marketplace tasks of a build workflow. This means its straight forward to add a front-end compile task to the release workflows.
  
  On the downside a frontend build of a large react app can take a lot of time and a lot of memory. Memory probably won't be an issue for you. The time taken will be a little annoying. Yet the approach wouldn't be invasive so I would recommend it may be the least effort to set up and the easiest for colleagues to troubleshoot and maintain in the future as long as you have a stable frontend build. Historically npm was less reliable than other frontend builds at giving the exact same lib versions every run for the same package.json (e.g., npm vs. yarn). So you need to study that aspect and ensure that you are certain that every time you run the frontend build it is guaranteed to use the same exact dependency versions.
  
  > **Comments:**
  > **username_0**: Yes, I thought about building the frontend on the release pipeline, but the problem is how to actually get the frontend source into the release pipeline? Release jobs in TFS 2018 doesn't have a "Get Sources" step, so it cannot be fetched from the repo. We could use a command line step and pull the repo from there, but it feels hacky. The other option is publish the frontend src code as an artifact, but the node_modules folder is huge and takes a lot of time to publish.  
  > **username_0**: I still don't quite understand what you mean by "we changed the js code to fetch env vars from the server at page load". What's the server in this case? In my case the frontend is just a pure static website. The URL of the API is generated during the build by webpack. As I see it, this solution still needs a way to tell the frontend where to fetch the env. vars. from.  
  > **username_1**: A react app is a package.json that webpacks a static site. So just add something like this https://github.com/username_1/react-redux-realworld-example-app/blob/master/server.js that repo is a fork of a pure spa single page app with that small express server added to serve up env var and a minor mod to the html page to load a /env.json from that small server.  
  > **username_0**: Yeah, I can't use a server. This is hosted as a pure static website in a CDN. No server-side code allowed.  
  > **username_2**: @emzero Release pipelines very much do in fact have a way to "get sources" from a Git repo.  Add an [artifact source](https://docs.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops#sources) that is a linked Git repository and it will perform a fetch on it before the rest of the pipeline starts such that the code artifacts from the Git repo are present.  
  
  ---
  
  