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

Setup staging flow #57

Open
3 tasks
ROODAY opened this issue Sep 6, 2020 · 1 comment
Open
3 tasks

Setup staging flow #57

ROODAY opened this issue Sep 6, 2020 · 1 comment
Assignees
Labels
enhancement New feature or request low priority Isn't critical, no need to get done anytime soon v3.3 Target Release - v3.3

Comments

@ROODAY
Copy link
Member

ROODAY commented Sep 6, 2020

In the future it'd be nice to be able to work on the site and not worry about messing up actual user's data. To do so, we need a staging environment. Will require adding back the develop branch, which will essentially be the pre-release version of inquisitor. Branches will be made off develop and merged back into develop, and when it's time for a release a PR from develop to master will occur to bring in new features.

  • Bring back develop branch, setup branch protections, update contributing guidelines
  • Whenever a push/PR to develop happens, deploy to firebase hosting (master will continue to use gh-pages as the production hosting location)
  • To differentiate data, create another firebase project (import production to seed it). Inject the firebase config using env variables locally, and through github secrets/actions (just compress the config into a json string so its one var). Load the appropriate var based on whether its develop or master branch, then deploy

This way we can have a staging environment in which we can mess with data as much as we want without fear of accidentally deleting real user data. Will need more rigorous code review when pulling into master to make sure stuff doesn't break existing data.

@ROODAY ROODAY added enhancement New feature or request low priority Isn't critical, no need to get done anytime soon labels Sep 6, 2020
@ROODAY
Copy link
Member Author

ROODAY commented Sep 23, 2020

Alternatively a simpler solution is writing instructions for using the Firebase Emulator. This way we don't need a staging environment as someone can test out exactly how it would work in production on their own machine, and an added benefit is that multiple devs can work in parallel without overwriting each others data (e.g. someone enables applications to test something and someone turns it off to test something else, with the emulator they can test everything locally).

@vitorvicente vitorvicente added the v3.3 Target Release - v3.3 label Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request low priority Isn't critical, no need to get done anytime soon v3.3 Target Release - v3.3
Projects
None yet
Development

No branches or pull requests

2 participants