Click here to Skip to main content
15,868,141 members
Articles / Programming Languages / Scala

Scala Environment Config Options

Rate me:
Please Sign up or sign in to vote.
0.00/5 (No votes)
24 Jan 2017CPOL3 min read 5.6K  
Scala environment config options

This is going to be a slightly weird post in a way as it is going to go round the houses a bit, and not going to contain any actual code, but shall talk about possible techniques of how to best manage specific environment config values for a multi project scala setup.

Coming from .NET

So as many of you know, I came from .NET, where we have a simple config model. We have App.Config or Web.Config.

We have tools at our disposal such as the XmlTransformation MsBuild tasks which allow us to maintain a set of different App.Config values in them that will be transformed for your different environments.

I wrote a post about this here:

Here is a small example of what this might look like:

image

So when I started doing multi project Scala projects using SBT where I might have the following project requirements:

image

In the above diagram, the following is assumed:

  • There is a Sacha.Common library that we want to use across multiple projects.
  • That both Sacha.Rest.Endpoints and Sacha.Play.FrontEnd are both apps which will need some environment specific configuration in them.
  • That there is going to be more than 1 environment that we wish to use such as:
    • PROD
    • QA
    • DEV

Now coming from .NET, my initial instinct was to put a a bunch of folders in the 2 apps, so taking the Sacha.Rest.Endpoints app as an example, we may have something like this:

image

So the idea would be that we would have specific application.conf files for the different environments that we need to target (I am assuming there is some build process which takes care of putting the correct file in place for the correct build within the CI server).

This is very easy to understand, if we want QA, we would end up using the QA version of the application.conf file

This is a very common way of thinking about this problem in .NET.

Why Is This Bad?

But hang on here, this is only 1 app, what if we had 100 apps that made up our software in total. That means we need to maintain all these separate config files for all the environments in ALL the separate apps.

Wow, that doesn’t sound so cool anymore.

Another Approach!

How about this for another idea. How about the Sacha.Common JAR hold just the specific bits of changing config in separate config files such as:

  • Qa.conf
  • Prod.conf
  • Dev.conf

And then, the individual apps that already reference the Sacha.Common JAR just include the environment config they need.

This is entirely possible, thanks to the way that the Typesafe config library works, where it is designed to include extra config files. These extra config files in this case are just inside of the a JAR that is external -> Sacha.Common.

Here is what this might like look for a consumer of the Sacha.Common jar.

image

Where we just include the relevant environment config from Sacha.Common in the application.conf for the current app.

And this is what the Sacha.Common may look like, where it provides the separate environment config files that consumers may use:

image

This diagram may help to illustrate this further:

image

Why Is This Cool?

The good thing about this design over the separate config files per environment per application is that we now ONLY need to maintain one set of environment specific settings, which are those in the common Jar Sacha.Common.

I wish we could do this within the .NET configuration system.

Hope this helps, I personally think that this is a fairly nice way to manage your configs for multiple applications and multiple environments.


Image 7 Image 8

This article is part of the series 'Scala View All

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer (Senior)
United Kingdom United Kingdom
I currently hold the following qualifications (amongst others, I also studied Music Technology and Electronics, for my sins)

- MSc (Passed with distinctions), in Information Technology for E-Commerce
- BSc Hons (1st class) in Computer Science & Artificial Intelligence

Both of these at Sussex University UK.

Award(s)

I am lucky enough to have won a few awards for Zany Crazy code articles over the years

  • Microsoft C# MVP 2016
  • Codeproject MVP 2016
  • Microsoft C# MVP 2015
  • Codeproject MVP 2015
  • Microsoft C# MVP 2014
  • Codeproject MVP 2014
  • Microsoft C# MVP 2013
  • Codeproject MVP 2013
  • Microsoft C# MVP 2012
  • Codeproject MVP 2012
  • Microsoft C# MVP 2011
  • Codeproject MVP 2011
  • Microsoft C# MVP 2010
  • Codeproject MVP 2010
  • Microsoft C# MVP 2009
  • Codeproject MVP 2009
  • Microsoft C# MVP 2008
  • Codeproject MVP 2008
  • And numerous codeproject awards which you can see over at my blog

Comments and Discussions

 
-- There are no messages in this forum --