New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce environment specific configurations for Spartacus deployment on ccv2 #5772
Comments
|
In addition to what Tobias described above, there is also currently a need for a mechanism to differentiate between local development vs deployment in CCv2. An example currently is the way that the occ-backend-base-url is used. The options currently are: configure it in code, or use the meta injection approach. If configured in code it overrides the meta approach, but the meta approach is not available in a local development environment. It would be possible to achieve this via an environment.ts (local dev) vs environment.prod.ts (CCv2) switching approach ... if there was a standard/recommended mechanism for how to handle this in CCv2. At the moment CCv2 just uses the yarn build, taking the package.json definition (ng build vs ng build --prod) so the same environment file is used in both local/CCv2 (depending on how package.josn has been configured) Most developers will be working in a checked-out version of the same repo used for deployment to CCv2. The current setup leaves them with only manual file alteration possibilities to make this work. For a repo that is currently working in CCv2 that means for local development, the developers must either change package.json or environment.ts/environment.prod.ts ... and to enable this, the standard app.module.ts code needs to change slightly (test whether/not the an environment configuration item for occBaseUrl exists). It seems like some form of option 1 is required for local vs CCv2 builds, as well as perhaps option 3 for applying the CCv2 build across multiple different environments in CCv2 |
|
A non trivial implementation may need different configuration properties to set for different environments, for example to connect also to other external systems or for some debugging options. Using environments is at the moment working very well for us. |
|
I would vote for the option 1 from the starters three options. In the current project we would like to set the server side rendering off for development environment, but true for test and production. Currently it seems that the only option is to create separate builds for development and test / production. |
|
Hi, @tobi-or-not-tobi ! I have disabled the properties on JS Storefront Service. For other services proreperties aren't disabled |
|
@alvteren - for other services, the properties override back-end configuration properties - the kind of thing you can override on a server-by-server basis in hac. Have you seen something to indicate that there is a mechanism to include properties into Spartacus? I don't get to even click the 'SAVE' button if I try this myself, so I just assumed this wasn't available. |
|
Hi @aleruz - how have you got this working in ccv2, if it's always running the production build (I assume using --prod)? I was kind of expecting that ccv2 backend build process would be calling ng build --configuration=staging for staging, ng build --configuration=production for production, ng build --configuration=dev for development and we could use our own for local development / CI (e.g. ng build --configuration=local) and then it's easy to control config from environment to environment. Maybe even --configuration=d1 / s1 / p1 as I'm aware some customer might have more environments - e.g. s2 etc) |
|
Hi @simonkeytree - I have created environment.qa.ts and environment.prod.ts in my project also configurated property in angular.json to replace it. My question is how we can execute our builded code(ng build --configuration=qa ) in cloud? |
|
Hi @hikmettuysuz - my question as well. I've raised a support request with SAP to see if there's any kind of workaround. I'm hoping it's not creating three builds that are duplicates of each other other than the config for each environment. Not too bad to do via CI, but a really nasty kludge. |
|
Hi @alvteren, @simonkeytree, @hikmettuysuz This is not an official response, but my personal understanding of CCv2 is:
I think all of this is at some level under review by the relevant teams, but I do not know if/how it is progressing. |
|
Thanks @neilhubertprice - that's my understanding at the moment. It effectively means you can't use the same build for all three environments, which seems like a big omission as Commerce Cloud officially only supports Spartacus as a SPA, and goes against the approach used for traditional Spring MVC accelerators, where the configuration is well managed through the Manifest file. But the current approach really makes an external CI pipeline essential to ensure git branches have the correct configuration per environment with a build per environment. I can't really think of another good way around it. |
|
@simonkeytree My view is you should aim to keep the same single build & progress it across environments ... but that means losing out on some of the standard Angular approaches to different environment config. Elsewhere I have suggested a custom call to the backend SAP Commerce system to retrieve environment-specific configuration - that way you can treat it as data/config separate from the build. |
|
Hi @neilhubertprice - I was hoping to workaround it this way. I may be missing something obvious (quite likely!) but how would you know which URL to call to the SAP Commerce system for the specific environment, from the Spartacus pod? I'm looking for something that would identify the environment from within Angular (e.g. an OS environment variable, config from the manifest) but haven't been able to identify anything yet. Any ideas - I'm really hoping I've missed something obvious. |
|
@simonkeytree Each Spartacus instance is served from a particular environment & the OCC url is injected for the API endpoint of that specific environment. What I suggested above would be an additional (custom) call against that endpoint. Internal to the Commerce instance it would then have (and respond with) data specific to that environment |
|
Hi @nathanss - How is the OCC URL injected? I hadn't realized this got injected from the environment - I thought it was taken from configuration defined in the codebase (either from the meta tag or as defined in a typescript configuration file). I guess I could take the results from the HOSTNAME environment variable and map this to the specific environment, assuming the hostname remains the same for the environment. That could then be used for using a specific set of configuration values - will give that a try. Unfortunately, the internal HOSTNAME bears no resemblance to the externally visible hostname, so that was a dead end. |
|
Hi @simonkeytree - I guess that was meant for me rather than Nathan? Take a look at the 'Caution' box on this page: https://help.sap.com/viewer/b2f400d4c0414461a4bb7e115dccd779/v2005/en-US/63577f67a67347bf9f4765a5385ead33.html or this page in the Spartacus docs: https://sap.github.io/spartacus-docs/configuring-base-url/ |
|
Hi @neilhubertprice - thanks. Yes apologies to Nathan there. Will give that a go. Bit of a kludge - the standard Angular approach would seem more intuitive, but I guess that's being considered by the Spartacus / Commerce Cloud teams at the moment. Cross fingers. |
|
What would be the problem with passing (for example) ng build --configuration=s1 for staging, ng build --configuration=p1 for production, ng build --configuration=d1 for development so that the appropriate config files can be used? This would seem to eliminate the need to use a meta tag, allow any config you want (per environment), and ensure there's only a single code base. It does mean duplicating the constants per environment, but that's not the end of the world (and could potentially be worked around by including a common file in each environment .ts file) Thanks Simon |
|
@simonkeytree did you figure something out to make it work via pipeline actions or did you get an answer from the SAP Support request? |
|
Hi, |
|
@neilhubertprice the way how the deployment changes the index.html AFTER the angular build also leads to the problem, that the PWA is not working correctly because the hash of the index.html does not match anymore.. |
|
@tobi-or-not-tobi were you aware of this issue around the PWA / hash? Do we have a solution? |
|
@simonkeytree @mpern - We've faced this issue as well while working on several projects. Overall I agree with @mpern - the application (assets) should be immutable. The way we've fixed it is as follows :
This change obviously relies on a backend change (OCC) but it feels like the right way to configure our immutable application as a runtime in a "headless storefront" context. It's also not tied to any hosting solution (CCV2, Onprem, etc). |
|
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, |
|
Any updates on this? |
|
This is something that would be useful in the |
|
This would be more useful if the ccv2 environment supports one of the suggestions in this ticket! |
|
It would be awesome to have the possibility to set custom NodeJS variables for build time. Or at least to have a NodeJS variable, which indicates the environment (d1/s1/p1) at build time. Looking forward for any updates on this. |
|
On platformServer mode (when page is generated on the server side), you can use |
How did you determine which OCC endpoint needs to be called? d1/s1/p1, etc.. Or are you sending all the config, for all the environments and then checking on UI based on window location href? |
|
@Pranavbhartia - the OCC endpoint is the only thing that does get automatically configured per environment. It works by using the special placeholder Details can be found here: |
|
@Pranavbhartia you should be able to access the OCC endpoint in your code by using |
|
@janwidmer and @mpern, thanks for that. I am a bit stuck though. I am a Backend dev trying to resolve this, and not very good with Angular concepts. I have reached to a point where I am able to read the property, but I am just not able to set it to the properties inside the ngModule. Could you please help me out. Please find the code attached. The conf variable inside the constructor has a value and is printing the full config object that I need. On the other hand, the object before the ngModule has an undefined value and hence it takes the undefined value where I need to provide it with the base url and base site. Instead of going with a backend API, I am using a config file per environment here, so then all the control is within the Spartacus code itself. This might not be the best forum for this, but though would help others in my situation as well. Edit : Putting the Stackoverflow link for anyone who might be in the same position as me. |
|
@Pranavbhartia could you maybe create a stackoverflow question with your code, then the community can help there.. |
|
@tobi-or-not-tobi Is there any hope a solution to this issue will be provided in the future? We are running into the issue of trying to pass environment specific google tag manager Ids in app.module. We still have not found way to get this working. Any help would be great |
|
Hi @timoblume, |
|
Hey, I see there's a lot of frustration about this topic, so I want to share our solution to separate between stages on server side. It's not the nicest way, but the only way we found. We are using a custom storefront, based on express and react, but this also works for spartacus. So, the only indicator to get information about the stage we found at runtime, is the occ-backend-base-url meta tag in dist/custom-storefront/index.html. If you put We built a service, which read this meta tag information from the index.html file on server side, to get the current stage. This service is only called once at startup of our nodejs (express) app. After we got the stage, we import asynchronously the corresponding stage configuration. |
|
Hey guys, because SAP doesn't really seem to provide an update on this topic and also no solution for one of the fundamental missing features in Spartacus / Composable Storefront, I thought it would be great to provide an easy-to-integrate solution to the SAP Commerce Cloud community and especially for every project, in which one is force to have different configuration provided, e.g. for single-sign-on with OAuth, etc. The solution can be summarized as follows:
As I don't like to do things several times, you can jump-on a open-source extension provided at SAP CX Tools: Steps to integrate
With this solution in place, I think this topic can be marked as solved. Even though it would be great to have the solution provided by SAP... Have fun. Bechte |



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:
occ-backend-base-url. We would use backend properties, which gives the advantage of runtime configuration over build time configuration.The text was updated successfully, but these errors were encountered: