This topic contains 5 replies, has 4 voices, and was last updated by  grgsmith 1 month ago.

Strategies for storing environment specific interface configuration

  • Hi all,

    What are best practices for storing interface configuration that is environment specific and shouldn’t be moved between dev, test, and production environments? By interface configuration, I mean things like database servers to connect to (i.e. information the Lua translator code needs access to but isn’t an Iguana setting). Ideally I’d like to keep this information in configuration files that can be part of the Iguana project and easily updated by uploading a new file through the Iguana GUI (rather than putting them somewhere else in the filesystem where they are harder to access). But this approach means those files get included when exporting/importing channels to a Repo, which I don’t want.

    Has anyone used gitignore or other features of Git to suppress moving configuration files? Are there any smart approaches to handling configuration information I’m not aware of?

    Thanks!

    Hi there,

    The best way to do this would be to use environment variables in Iguana.

    You can access the values contained in environment variables from within the Translator using the os.getenv() method. For example, if you have set an environment variable named TEST to the value “Hello World!” then calling os.getenv(‘TEST’) would return the string “Hello World!” in the Translator.

    This is useful when accessing databases, files, LLP IPs/Ports, or other bits that are configured on an system-by-system basis. Setting this information in the environment variables allows you to use the same code across a development, and production system while only requiring you to change the value of the environment variable in each.

    Integration Analyst at iNTERFACEWARE

    You can also use environment variables in certain Iguana configuration screens. For example the “Host address” in an LLP client can use the form ${TEST} to evaluate to an IP that’s been set in IguanaEnv.txt. If a field supports this it will show the expanded value under the field before saving and once saved will appear as “${TEST} –> VALUE”.

    Thanks! Sounds like that would work nicely, at least for Iguana level settings. It would be nice to be able to do something similar for interface level configuration that’s not shared across all channels.

    Greg,

    Our customers are doing interface level configurations in other ways as well. Configurations can be stored in local external files that Iguana scripts can import prior to executing any business logic. This is a common strategy.

    The downside here is that these files do not get stored as part of version control. So there are a few extra assets to maintain external to Iguana for any one interface. But the tradeoff may be worth it for you.

    Casey Trauer,
    Director, Client Education
    iNTERFACEWARE

    Makes sense, thanks for everyone’s input.

    Sounds like depending on the nature of the configuration there are different places that make sense for it to live:

    Iguana level (i.e. applies to all channels), environment specific: Iguana Environment Variables

    Interface level, environment specific: External configuration files (not kept in Iguana and NOT moved with a channel during export/import to Git repo)

    Interface level, not environment specific: ‘Internal’ configuration files (kept in Iguana project and moved with a channel during export/import to Git repo)

You must be logged in to reply to this topic.