Splits as Configuration

Follow

francisco.alvarez

• February 06, 2019 18:03

We were looking for a simple way to store some environment specific configurations and thought about using split for this.

It already has the UI and the environments that we use, so we wanted to try it out. Works with some caveats.

The treatments names are limited in size and characters allowed.

You have a minimum of 2 treatments.

In our specific case, we wanted to store the url to a vendor's portal, which changes per environment.
We also thought about using it for storing another vendor's keys.

 

Our suggestion would be to allow a single treatment "configuration" split, that allows more chars.

3

• Official comment

  

  Trevor Stuart

  • May 23, 2019 00:51

  Francisco, we wanted to quickly follow-up as we have now released dynamic configurations which should address some of your use case.  You can read more in our documentation or on our blog.  Right now, each Split has a minimum of two treatments.  We will keep you updated should this change and/or configurations become a global object accessible and not attached to specific split treatments.

  Comment actions Permalink
• 

  David Murphy

  • February 08, 2019 22:47

  Hi Francisco, we're looking to prioritize our dynamic configs project in the next 6 months.  More to come.

  1

  Comment actions Permalink
• 

  francisco.alvarez

  • May 28, 2019 18:00

  This is great, I'm going to take it out for a spin ;)

  0

  Comment actions Permalink
• 

  francisco.alvarez

  • May 28, 2019 18:37

  @Trevor how should I set up the .split file to account for configurations in localhost?

  0

  Comment actions Permalink
• 

  Bilal Al-Shahwany

  • May 28, 2019 20:56

  Hi Francisco, each SDK language in our documentation has a section on how to use localhost mode with an sample of .split file content.

  For example here is the Java SDK link: https://help.split.io/hc/en-us/articles/360020405151-Java-SDK#localhost-mode

  Thanks

  Bilal

  0

  Comment actions Permalink
• 

  francisco.alvarez

  • May 28, 2019 21:46

  Thanks for the reply Bilal. 
  We used to have a .split file that held the features for localhost, but now when adding the yaml format it doesn't seem to work. 
  Do we need to rename the file to split.yaml?

  0

  Comment actions Permalink
• 

  Bilal Al-Shahwany

  • May 28, 2019 21:51

  Hi Francisco, if you like to use yaml file, you do need to pass the yaml file name in the builder call, as its shown in the doc link.

  SplitClientConfig config = SplitClientConfig.builder().splitFile("..../split.yaml").build();

  SplitClient client = SplitFactoryBuilder.build("localhost", config).client();

  If you have questions, feel free to send them to support@split.io, we will be happy to help out.

  Thanks

  Bilal

   

   

  0

  Comment actions Permalink
• 

  Trevor Stuart

  • June 07, 2019 00:06

  Francisco - I wanted to check back in here and see if this matched your need. Hope you're well.

  0

  Comment actions Permalink
• 

  francisco.alvarez

  • June 07, 2019 16:01

  Hi Trevor. Yes, it did! It's a pretty cool feature.
  The one thing that gave me some trouble is the .yml file for localhost testing.
  I wish I could write the configuration object in a more natural way.

  Current:

  - feature-flag:

      treatment: "on"

      config: "{\"key1\": \"value\", \"key2\": \"value\", \"key3\": \"value\"}"

   

  Desired:

  - feature-flag:

      treatment: "on"

      config:

          key1: "value"

          key2: "value"

          key3: "value"

  0

  Comment actions Permalink
• 

  Pato

  • June 07, 2019 17:42

  Hey Francisco,

   

  Thanks for the feedback once again. The reason in this first release we did it as a String in one line was to also support nested structures somewhat seamlessly. For example, see below. This nested structure would be a bit trickier if we follow your desired approach.

   

  That said, we continue to hear feedback and ideas to continue to improve this functionality and make it even more usable for everyone's uses cases.

   

   

  - feature-flag:

      treatment: "on"

      config: "{\"key1\": {\"key1_1\" :\"value_1_1\"} , \"key2\": \"value\", \"key3\": \"value\"}"

  0

  Comment actions Permalink

Please sign in to leave a comment.