Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
Are you saying that every environment (QA, staging, production, etc.) all operate against the same API server? Or do you at least have different API servers per environment? –  Aaronaught Sep 19 '13 at 0:42
    
Sorry for not including that detail, we have different API servers per environment. –  Terence Sep 19 '13 at 0:48
add comment

1 Answer

up vote 1 down vote accepted

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.

share|improve this answer
    
The heart of my question is wether it's best to handle client env. config at build time or afterwards. All of 4 the solutions you've included put the responsibility for managing env. configs after the release is built, so that's a pretty strong vote. –  Terence Sep 19 '13 at 15:32
    
I also want to clarify something on #4. It seems to me that setting the base URL for the API server(s) is a configuration dependency. That's actually pretty much the situation we have with some of our web clients today. –  Terence Sep 19 '13 at 15:40
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.