Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

development -vs- production settings #53

Closed
mjallday opened this issue Apr 18, 2013 · 4 comments
Closed

development -vs- production settings #53

mjallday opened this issue Apr 18, 2013 · 4 comments
Assignees

Comments

@mjallday
Copy link
Contributor

What is the best way to replace configuration variables into the html files as part of the build process so we can switch analytics accounts etc?

@mahmoudimus
Copy link
Contributor

chef

Sent from my iPhone

On Apr 18, 2013, at 1:23 PM, Marshall Jones notifications@github.com wrote:

What is the best way to replace configuration variables into the html files as part of the build process so we can switch analytics accounts etc?


Reply to this email directly or view it on GitHub.

@kleinsch
Copy link
Contributor

In the past (for a non-grunt build system) I've had the HTML file be handlebars templated and modified the context variable that gets passed into that template based on an environment variable. Some Googling came across grunt-env and grunt-preprocess that seem like they could handle this.

On simpler projects, I've just had different HTML files for each environment, but that gets hairy as the number of environments grows and your HTML file gets more complicated. You end up with a lot of duplicate code, so probably not advisable.

@mjallday
Copy link
Contributor Author

the issue with chef is it would need to know how to construct the file. since it's static html it needs to be injected into the file at build time. a build command that pulls them from a file (which can be stored in a chef recipe) would work.

having a settings.ini file which is used sounds good and then chef could overwrite this in our CI environment as part of the build/deploy process. bonus points if it can read from a file specified by BALANCED_ENV which selectively overrides the default settings which means less duplication.

the other benefit of pulling in from a static file is it will make it easier for people to replicate the build process locally.

@ghost ghost assigned kleinsch Apr 25, 2013
@mjallday
Copy link
Contributor Author

Completed by @kleinsch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants