Introduce environment specific configurations for Spartacus deployment on ccv2

For angular developers it’s very common to use the environments file to distinguish different settings for different builds. This is often used for setting up different tokens for different environment. For example to target a different payment system, analytic system, tag manager, etc.

The build on Commerce Cloud is currently always using the production build. With this setup, the environment specific settings are not aligned with the build, as production build is always using the production environment settings.

Different options:

1. We align the angular build with the build to ccv2 environments. This would result in specific builds for specific environments. This will make the builds no longer reusable cross environments.
2. load environment settings from a file while bootstrapping the app. This would not be recommended for production builds as we introduce a blocking call before we can bootstrap the app (using config initializers)
3. bake environment specific variables into UI, similarly to what we’ve done with the occ-backend-base-url. We would use backend properties, which gives the advantage of runtime configuration over build time configuration.

[balajimohann]

Hi Team

Any information on when this may be prioritised? It would be great to just use the single build to deploy to multiple environments. Currently

Thanks, Bala

[mpern]

Actually, strike that, the compiled down version would look very different potentially. Would need a different compiled version for each environment to make this robust unfortunately.

@simonkeytree - That’s where we disagree and that’s exactly what the immutable webapp approach warns against (Quote: “immutable static assets”, and the production bundle is one of those assets). The same compiled version is deployed everywhere, index.html acts as deployment descriptor and “runtime configuration”, in a way. (that’s not that different than using multiple environment.ts)

We only(?) need:

• first-class, framework-level support for the env object by Spartacus
  • generate placeholder <script> block with pre-defined id and empty env object in schemas
  • ~Angular service to read values from env~ EDIT: environment should read unknown object properties from window.env (or some other fallback mechanism; not sure about SSR though)
  • If you break the env object (or <script>) block by accident, the build fails
• CCv2 automation supports env (entrypoint script):
  • detect and activate correct index-<environment>.html with fallback to index.html (great idea!)
  • read/parse env object from correct index.html, merge object with Service Properties from the CCv2 Cloud Portal and write merged object back to index.html
  • highly visible logging of what happend:
    • which index.html was used
    • warning if env script block/placeholder could not be found in index.html
    • before and after values of env if it was merged with Service Properties, or info message that no Service Properties required merging
    • the effective/final env

Voila! You have per-environment configuration without an additional request to load the config and you can cache every version of your storefront forever (minus index.html, of course.)

TBH, I would settle for index.<environment>.html support and Service Property injection.