open-bounty
open-bounty copied to clipboard
Infrastructure revamp
Problem
The infrastructure we're currently running on is mostly undocumented and spread across multiple clouds. This makes it hard for us to troubleshoot problems or make adjustments.
Solution
Recreate our infrastructure and document every step along the way to avoid similar problems in the future. Perhaps define our infrastructure in code so there is a shared up-to-date understanding of what our infrastructure looks like and what changes are being made to it.
Requirements
- Multiple environments (prod, staging, testing)
- Environments should not impact each other
- PostgreSQL database for each environment
- SSL for each environment
@churik @siphiuel @andytudhope please check if this sounds sane and add user stories in the comments.
USER STORY
As a developer of Open Bounty I'd like to be able to easily deploy specific versions to a given environment. A command like:
./script/deploy $GIT_SHA
Could be used to instruct a server to download the Open Bounty software of version $GIT_SHA
and restart the service once the new version is ready. For a first version minimal downtime during service restarts is acceptable.
This command may also be used during Continuous Integration, i.e. to update the version ran on production and staging.
USER STORY As a QA I'd like:
- to have easy way to build and deploy any PR to testing env from Jenkins with predefined dataset (with database restored from dump; known whitetelisted users and tokens);
- to have deployed
develop
branch on staging env after each merge; - to have easy access to databases and whitelist on staging and test envs.
Some additional notes have been captured in this Google Doc