Add production deployment scripts #81
Conversation
| - cd into `repos/cb-connect/scripts/` and run `./build.sh` | ||
| this will create a bundle file inside `/cb-connect/bundles` | ||
| - When `./build.sh` script will run successfully, it will output the deploy command like: `./deploy.sh XYZ` where XYZ is the commit hash. | ||
| - Copy and run the deploy command, it will deploy the bundle. In case of emergencies or failed deployment you can rollback the last release by running `./deploy.sh` script with previous hash. |
There was a problem hiding this comment.
Make sure to remove the bundle files inside /cb-connect/bundles after it grows to ~100 or more.
There was a problem hiding this comment.
TODO: Move mongo creds from ./deploy.sh to settings.json.
|
|
||
| export COMMIT_HASH=$1 | ||
| export ROOT_URL='https://connect.codebuddies.org' | ||
| export MONGO_URL='mongodb+srv://rootuser:[email protected]/cb-connect' |
There was a problem hiding this comment.
Instead of hardcoding it here, can we set it up as an environment variable manually in DO? I don't think this needs to be part of the script.
There was a problem hiding this comment.
I know @lpatmo mentioned it's no longer valid, but from my understanding, every time we deploy does this script gets ran and updates the variables in the droplet?
There was a problem hiding this comment.
Right now, deployment is manual -- we have to ssh into the droplet and run ./deploy. Two todos we have are:
1/ Move the mongourl creds into settings.json
2/ Put the deployment script into a webhook so that changes to the master branch trigger an automatic deployment
There was a problem hiding this comment.
Right, so to my understanding, every time we run ./deploy, then the environment variables get reset, and if the mongo_url is no longer valid, then we're setting the variables with incorrect values. Am I assuming that correctly?
Instead of using settings.json, would now be a good time to bring up #32 again? I think that would make things more straightforward.
There was a problem hiding this comment.
#32 is about using .dotenv, not a production settings.json file living in the droplet?
There was a problem hiding this comment.
Correct - we'd drop settings.json all together and use .env files instead. Our local .env files will be in ignored with git (we'll use .env.example as a way for contributors to see what variables they'd need to get) and define process variables manually in DO.
There was a problem hiding this comment.
Ah, cool! Sure, that sounds like a good alternative.
No description provided.