Logic for server environment-specific settings

Enonic version: 7.4
OS: Mac/Win/PS4

Beautiful people of the Enonic community, I need some ideas here!

I’m in the need to add config for my app. That’s fair enough, the good old trick to use [app.name].cfg for app specific settings are great. But, I need to do have different sets of config based on what environment we’re in: LOCAL, DEV, TEST, PROD. So, my initial idea is to just group my settings in the .cfg like local.url1=xxx, dev.url1=xxx or something like that. And then within my controllers use the req object and the current server URL to figure out which environment we’re in. In theory I guess this could work. Any other ideas out there?

The reason I need this environment-specific setup is because of multiple reason, but we use a few different CDNs (based on mimetype), and our CDNs also run in different environments. This is why I need a config that understand where it is and serves me different values based on that fact.

We also build automatically and deploy to the cloud whenever we merge into master, so having these strings outside of our app-code and rather inside our docker-config (two different repoes) would be nice. Obviously, putting all this logic within our app could pull the job off, but wouldn’t be so sexy to maintain.

Makes sense? Give me your thoughts. Peace!

Hi there Mr B!

Your code should never need to “know” which environment it is in. If your infrastructure does not facilitate support for this, you May for instance tell XP which folders to scan, and then create a folder per environment. Common config may be stored in /config, evn specific in /config/test etc.

Use the xp.config.paths setting: https://developer.enonic.com/docs/xp/stable/deployment/config#xp_config_files

Also, check out this funky app: https://market.enonic.com/vendors/enonic/gitpull

2 Likes

Hi Thomas,

Thanks for input. Since the CDN operates on different URLs depending on environment, my code has to know were it is or it cannot fetch the correct resources. I will look into the folder-structuring idea, that’s a nice add-on for us. We’re currently looking into using Docker variables to do some slight changing on deployment. That or Jenkins. We’ll see what solution we’ll land on.

The gitpull-app is nice, but we run a self-hosted git repository not available for outside access. Otherwise we’d love that type of setup.

You can always run Git internally. Lots of options.
I would think that the fact that having unique URL’s would be “config enough” without having to add further intelligence in your code? Perhaps some additional config would do?