Splits as Configuration

Follow
francisco.alvarez

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

Comments

10 comments

Date Votes
  • Official comment
    Trevor Stuart

    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.

    Permalink
  • Dave Murphy

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

    1
    Permalink
  • francisco.alvarez

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

    0
    Permalink
  • francisco.alvarez

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

    0
    Permalink
  • Bilal Al-Shahwany

    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
    Permalink
  • francisco.alvarez

    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
    Permalink
  • Bilal Al-Shahwany

    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
    Permalink
  • Trevor Stuart

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

    0
    Permalink
  • francisco.alvarez

    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
    Permalink
  • Pato
    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
    Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post