How do you handle deployment configuration of your thick browser (html/javascript/css) clients?

Question

Question

For those of you working with html/javascript/css "thick clients", specifically those that work against some client-independent server API, how do you manage your deployment environment configuration?

Do you manage the configuration at build time with per-environment release builds (e.g. QA, STAGE, etc) or do you build a general release and rely on some server-side configuration? What's worked best in your experience?

Background

My company has several different thick browser clients. All clients share some common attributes.

• They operate against a common api server which is unaware of client-specific concerns
• They are completely static at deployment and delivered via apache with no server-side processing. This means that each environment requires it's own release build (QA, STAGE, UAT, PROD).

We are looking at refactoring our clients to have general release builds and relying on server side processing to support the necessary client-specific configuration. This seems like the obvious choice, but I'd like to see how other people in same situation have handled it.

Answer 1

There are any number of different options, and the best one would depend on your specific (much more specific than we have so far) circumstances:

1. Create separate per-environment configuration files as part of your build script. Then have your deployment script replace the default (usually empty) files with the correct environment.

2. Have only one configuration, but use replacement tokens, and use a configuration management tool like ESCAPE or a release automation tool like Nolio to substitute them during deployment.

3. Implement a Configuration API as part of the application server. The client could request the current settings during the initial load.

4. Don't have any configuration dependencies in the client at all. Let the server handle it within the behaviour of its APIs, and make the only "setting" for the client be the base URL for the various APIs.

There might be more options but those are the obvious ones. And, like I said, which one is most appropriate for you depends on your exact situation. You haven't yet told us enough to recommend a specific one.