NODE_ENV for development and production

[adamduncan]

In order to leverage environment-specific control over certain site features, we should differentiate between builds for production and development.

We currently just build with NODE_ENV=production assumed. Let's rework these scripts to support both, by setting the NODE_ENV appropriately, e.g. something like...?

"build": "npm-run-all clean --parallel site css js assets",
"build:development": "cross-env NODE_ENV=development npm run build",
"build:production": "cross-env NODE_ENV=production npm run build",

This way we'll be able to reference process.env.NODE_ENV available at build-time.

• Suggest we create an isProduction variable in our _data/site.json as a Boolean (e.g. isProduction: process.env.NODE_ENV === 'production')
• Make use of site.isProduction in scenarios where we need environment-specific control, e.g.
  • Add <meta name="robots" content="noindex, nofollow"> if not production
  • Set env-specific hostname where needed (e.g. for sitemap.xml) — or we just omit creation of sitemap.xml for non-production environments?
  • Google Analytics snippet (Set up and implement analytics #191)

@djgalloway — Will need support on how we might differentiate the two environments in our build config. Will it be possible to trigger npm run build:development and npm run build:production for https://develop.ceph.io and https://ceph.io, respectively (in place of the generic npm run build we use for both envs currently)?

[djgalloway]

Will it be possible to trigger npm run build:development and npm run build:production for https://develop.ceph.io and https://ceph.io, respectively (in place of the generic npm run build we use for both envs currently)?

For sure. Will just add some BASH here that will change the command based on the branch.

[djgalloway]

Ultimately, will the main/master branch be what you want displayed at https://ceph.io?

[adamduncan]

Ultimately, will the main/master branch be what you want displayed at https://ceph.io?

Yep, that was my understanding.

main/master ➡️ https://ceph.io
develop ➡️ https://develop.ceph.io

Though it might be worth raising with the group? Once we move beyond launch, will the team want to maintain a development environment to collect updates in (and ultimately push up to master/prod to publish), or will the expectation be that users feature-branch from master and cut-out the middleman?

[djgalloway]

Though it might be worth raising with the group? Once we move beyond launch, will the team want to maintain a development environment to collect updates in (and ultimately push up to master/prod to publish), or will the expectation be that users feature-branch from master and cut-out the middleman?

Please do raise with the group. For me, personally, I think it makes more sense to push mychange branch and view it at https://mychange.ceph.io then merge into main. I'm not sure how else it could work. Everyone push to develop?

[adamduncan]

Please do raise with the group. For me, personally, I think it makes more sense to push mychange branch and view it at https://mychange.ceph.io then merge into main.

Yep, perfect. So each branch deploy is accessible from its branch-name subdomain (as it is currently). All branch deploys will run npm run build:development, reserving npm run build:production for main (master). In which case the develop branch (and site) becomes redundant once we go live and move to a feature-branch-to-master workflow?

@Thingee — is that how you envisage we'll be managing content updates/branch previews?

[Pete-Robelou]

• Add <meta name="robots" content="noindex, nofollow"> if not production

• Set env-specific hostname where needed (e.g. for sitemap.xml) — or we just omit creation of sitemap.xml for non-production environments?

@adamduncan I've completed these tasks and they're working fine; however, I've noticed a warning in the browser console Uncaught ReferenceError: process is not defined / site.js which I can't quite get to the bottom of. Maybe something we can discuss?

I haven't spotted anything else obvious that we can use the isProduction variable for at the moment.

[adamduncan]

I've noticed a warning in the browser console...

@Pete-Robelou Do you have a PR you can publish exhibiting this error? I can take a look to see if anything jumps out.

[Pete-Robelou]

I've noticed a warning in the browser console...

@Pete-Robelou Do you have a PR you can publish exhibiting this error? I can take a look to see if anything jumps out.

PR is here #170.

[adamduncan]

Thanks @Pete-Robelou. Commented over there.

[Pete-Robelou]

All resolved on the PR.

[djgalloway]

Let me know when I should do this

[adamduncan]

Let me know when I should do this

@Thingee Need your take on how you see the branching workflow and environments required once we launch. Do we think we need a intermediate develop/staging environment, or is it enough to have branch deploys to manage previews and master?

[Thingee]

Let's just use the branch previews.

[djgalloway]

Let's just use the branch previews.

With main (formerly master) the target branch?

[adamduncan]

With it decided that we'll just be working from a main/master and feature branch workflow, is there anything remaining to action here, @djgalloway?

The website changes required for this ticket have been completed and merged (#170)