Skip to main content
deleted 22 characters in body
Source Link

You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.

What is suggested in the other answer regarding dotenv will not work unless you buildcombine it multiple times or host eg. express to serve and transform indexwith #2 og #3 from this answer.html

Basically you have a few options.

  1. Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!

  2. Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.

  3. Setup your release to generate a transformed index.html from the original index.html created during build. This transformed index contains a snapshot of variables for a given environment when release is run on the environment.

If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.

You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.

What is suggested in the other answer regarding dotenv will not work unless you build it multiple times or host eg. express to serve and transform index.html

Basically you have a few options.

  1. Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!

  2. Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.

  3. Setup your release to generate a transformed index.html from the original index.html. This transformed index contains a snapshot of variables for a given environment when release is run on the environment.

If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.

You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.

What is suggested in the other answer regarding dotenv will not work unless you combine it with #2 og #3 from this answer.

Basically you have a few options.

  1. Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!

  2. Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.

  3. Setup your release to generate a transformed index.html from the index.html created during build. This transformed index contains a snapshot of variables for a given environment when release is run on the environment.

If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.

Updated #3
Source Link

You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.

What is suggested in the other answer regarding dotenv will not work unless you build it multiple times or host eg. express to serve and transform index.html

Basically you have a few options.

  1. Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!

  2. Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.

  3. Setup your buildrelease to generate index.dev.html, index.test.html, index.uat.html,a transformed index.prod.html to your artifacts. These are generated from the finishedoriginal index.html. Then you just need to setup your webserver to use the correctThis transformed index.html file as default file contains a snapshot of variables for a given environment when release is run on the environment.

If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.

You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.

What is suggested in the other answer regarding dotenv will not work unless you build it multiple times or host eg. express to serve and transform index.html

Basically you have a few options.

  1. Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!

  2. Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.

  3. Setup your build to generate index.dev.html, index.test.html, index.uat.html, index.prod.html to your artifacts. These are generated from the finished index.html. Then you just need to setup your webserver to use the correct index.html file as default file.

If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.

You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.

What is suggested in the other answer regarding dotenv will not work unless you build it multiple times or host eg. express to serve and transform index.html

Basically you have a few options.

  1. Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!

  2. Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.

  3. Setup your release to generate a transformed index.html from the original index.html. This transformed index contains a snapshot of variables for a given environment when release is run on the environment.

If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.

added 50 characters in body
Source Link

You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.

What is suggested in the other answer regarding dotenv will not work unless you build it multiple times or host eg. express to serve and transform index.html

Basically you have a few options.

  1. Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!

  2. Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.

  3. Setup your build to generate index.dev.html, index.test.html, index.uat.html, index.prod.html to your artifacts. These are generated from the finished index.html. Then you just need to setup your webserver to use the correct index.html file as default file.

If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.

You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.

What is suggested in the other answer regarding dotenv will not work unless you build it multiple times or host eg. express to serve and transform index.html

Basically you have a few options.

  1. Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!

  2. Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.

  3. Setup your build to generate index.dev.html, index.test.html, index.uat.html, index.prod.html to your artifacts. Then you just need to setup your webserver to use the correct index.html file as default file.

If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.

You are completely right that it should be the same artifacts that are deployed to all environments. Especially in npm, dependencies tend to be loosely defined so a updated dependency could easily break the build just by building at different times. Even if you don't use hat or tilde in packages.json transient dependencies could be less strict with versioning.

What is suggested in the other answer regarding dotenv will not work unless you build it multiple times or host eg. express to serve and transform index.html

Basically you have a few options.

  1. Switch on the url in order to find the current environment you are in. This is a complete hack. Do not do this!!

  2. Have some server side code replace global vars in index.html on each request. The simplest solution depends on what you have installed on your server. It could be php or even something simple as SSI if you are on IIS. You will want to keep you index.html as valid html so you still can do local development. SSI is nice in this regard since it works inside comments. If you do php, keep your index.html and make a index.php which reads index.html but replaces your vars. A html parser works well for this replacement.

  3. Setup your build to generate index.dev.html, index.test.html, index.uat.html, index.prod.html to your artifacts. These are generated from the finished index.html. Then you just need to setup your webserver to use the correct index.html file as default file.

If your needs are simply configuration variables, I would recommend #3. If you need something a little more advanced, go for #2.

Source Link
Loading