2

In our case, both test and prod environments are Azure app services. So currently when we deploy to test:

  1. I replace the layoutServiceHost and deployUrl in scjssconfig.json to be the address of QA environment on my local
  2. Run jss deploy files on my local
  3. Copy resulting dist folder to the test environment (cm and cd)

This works, but having to edit a config file manually bothers me as it does not seem like a good and viable solution from a long-term view point & considering having to deploy to prod later too. What are the recommended/other ways to do it? Thank you

Improve this question

2 Answers 2

Reset to default
1

We have two scjssconfig.json files in root of our solution. One with the same name that is used by developers and second one with .dist suffix in name.

During build we remove the file without suffix and remove.dist suffix from the other.

scjssconfig.json.dist looks like this:

{ "sitecore": { "instancePath": "d:\\home\\site\\wwwroot", "apiKey": "{apiKeyGUIDOmmittedForSSE}", "deploySecret": "DeploySecretOmmittedForSSE", "deployUrl": "", "layoutServiceHost": "" } }

as you can see layoutServiceHost is blank. We have no problem with this setup in any of environments QA/INT/PROD/PREPROD.

You can do something similar for both layoutServiceHost and deployUrl in your case. So you just do this "replacement" before build, build solution on Build Server and deploy automatically to your environment without manual steps...

Improve this answer
0
3

Another solution would be to add support for environment variables in your JSS bundle. It was added already for Next.js: https://github.com/Sitecore/jss/pull/527/files but it works also for React with one difference in generate-config.js:

instead of const computedConfig: { [key: string]: string } = {};

use just const computedConfig = {};

rest of the changes in your code shall be the same as in pull request for Next.js

For SSR Proxy variables are already supported: https://github.com/Sitecore/jss/blob/master/samples/node-headless-ssr-proxy/config.js

With this approach you don't need to create artifacts with different bundles per environment, but control the variable in Release Pipeline, for example in Azure DevOps App Service Deploy task with Application Settings:

-SITECORE_API_KEY $(sitecoreApiKey) -SITECORE_API_HOST $(sitecoreUri)

or in in App Service Settings task in Application Settings:

[ { "name": "SITECORE_API_HOST", "value": "$(sitecoreUri)", "slotSetting": false }, { "name": "SITECORE_API_KEY", "value": "$(sitecoreApiKey)", "slotSetting": false }, ]
Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.