I have a requirement to use a different apiKeyGigya per environment specific configuration for Spartacus on ccv2.
I tried to solve this by using multiple environment.xxx.ts files in which I defined the apiKey. However, in ccv2 environments only one command is being executed which is "build:ssr" in the build process.
I use the following tags for the corresponding environments:
Environment Production "build:ssr"
Environment Development "build:ssr-d1"
Environment Staging "build:ssr-s1"
Does anyone have a solution for this case?
Could you support me, please
Does anyone have a solution for this case?
There is no support for different build targets in Spartacus and SAP does not offer an official solution for this.
A possible solution to this, is moving your environment specific properties to your backend properties files. With the manifest, you can load in different properties files in the different environments.
You then create a new OCC endpoint, where you fetch your environment specific configuration based on the environment key. This can contain different values per environment.
For performance reasons, you could also have this endpoint serve all configurations in 1 response, cache this in Spartacus and use accordingly.
There were quite some discussions on this topic on the github repo. https://github.com/SAP/spartacus/issues/5772
Related
I want to have multiple (based on stage param) AWS cloudfront distribution.
So if --stage dev passed it would deploy a different CloudFront dist than --stage qa.
Each stage should update/create a distribution based on the stage params.
Is it possible to achieve with serverless.yml?
I have found the following plugin serverless-api-cloudfront , not sure it will create additional distribution if domain name is changed, and not sure it is possible to add origins with this plugin.
Thanks
Is it possible to achieve with serverless.yml?
Yes. Yes it's possible and it's already built in. Your config will be simpler if you use the plugin serverless-api-cloudfront (rather than declaring a AWS::CloudFront::Distribution resource yourself). You will get one distribution-per-stage, without having to jump through any hoops.
** EDIT
Expanding on my original post: It does seem that the serverless-api-cloudfront plugin's README is lacking in usage examples (at the time of this writing). I do suggest that anyone reading this post should go to the plugin's github and help the author by PR'ing a better README.
Here's a link to a blog article I found that shows an example of how to write up a AWS::CloudFront::Distribution directly in your serverless.yml. It's only 1 resource, so you may not even want to depend on a plugin anyway. https://medium.com/yld-blog/caching-in-with-cloudfront-using-serverless-5a174651ab14
I'm working with a React application in GPC, and I have multiple environments [uat|training|staging]. Due to the way GCP is setup each application has a specific application configuration.
Therefore, I want to filter over my GCP app.yaml file to apply environment specific values per my build process. Is there something in NodeJS that allows me to do this? When building my current project I used create-react-app to do the initial build.
At this time, I'm still researching if anyone has done this or if this is an Anti-pattern with NodeJS applications. Not sure if anyone else has run into this problem.
I develop an application with nodejs and react. I use dotenv for configuration in my different environment.
I use TFS 2017 for build and release my application.
What is the best practise for add my .env file of production environment?
Production configs can be difficult to maintain. You can use any module or even write your own custom module to load environment variable in to your application.
However, maintaining production .env files locally for each product (i.e. committing them or putting them inside your docker image is a bad idea. If you ever happen to change some of those configs, you will have to manually change in the code for each application, build docker image (if required) and redeploy. If there are just a couple of applications, it might be easy. But if the number of related applications grow in size (as usually happens in case of microservice based architecture) - all of them sharing credentials, ips for database connections etc. it becomes a hectic task to manually change code and redeploy all the applications.
Usually, developers tend to keep a central repository of all credentials and environment variables. For examples, AWS offers parameter store and MS Azure offers Azure Key vault. In such a case, all the parameters are fetched during start time, and all we have to do is restart the application.
So usually people set only one global varibale NODE_ENV (as prod or dev), dynamically fetch all environment variables based on NODE_ENV running something like env $(node read-env-variables.js) node app.js.
We have several web projects that we deliver as .war files and deploy to jboss. We have a situation where the exact same "war"/code base is delivered to multiple environments with each environment requiring different auth-constraints to be defined in the web.xml. What is the best way/best practice on delivering these different configurations.
You can either
supply specific builds for each environment
deploy the same build everywhere and use Puppet or similar tools to manage specific web.xml content per environment
Which is cleaner and/or more easy to implement depends on your existing work flows. There may be other alternatives as well.
I am building a Node.js application and need to store database credentials (and other runtime properties) in such a way that they can be read when deployed on Heroku. My source is available in a public GitHub repository.
I am currently using environment variables, configured using heroku config:add, but am looking to understand if there are any alternatives. I would potentially like to use Cloud9 IDE, but it does not currently support environment variables.
Another option is to store the parameters in a config. file, but I believe the file would need to be checked in to Git (and as such, be publicly available) in order to be pushed to Heroku.
Thanks for your help.
ENV vars are generally considered the way to go, and the way Heroku do it themselves for database_urls and the like.
As you and your app are the only people with access to the env vars, you're generally OK security wise.
Putting credentials in Git or similar is a bad idea as it's another place that needs to be secured.
The one way I know of to solve the problem for development using command-line arguments. These can be specified in your run/debug configuration. You can then access the parameters in process.argv. Of course this means that they will be stored in your Cloud9IDE dev environment. You could then use the ENV variables in a retail production. This will at least prevent the credentials from being visible in source or config files.