This commit completes the database consolidation cleanup by documenting the historical migrations and updating all references to reflect the single-database architecture. Changes: - db/openneo_id_migrate/README.md: Created comprehensive documentation explaining the history of the separate database and why these migrations are preserved but no longer runnable - db/openneo_id_schema.rb: Deleted (no longer needed) - README.md: Updated to reflect single-database architecture - Removed mentions of "two databases" - Updated "OpenNeo ID Database" section to "Authentication Architecture" - Added reference to historical context in db/openneo_id_migrate/README.md - deploy/setup.yml: Removed openneo_id database creation and privileges for future deployments - db/migrate/20240401124200_increase_username_length.rb: Updated comment to note this was historically paired with an openneo_id migration The codebase now fully reflects the consolidated single-database architecture. The legacy migration files in db/openneo_id_migrate/ are preserved for historical reference only. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| files | ||
| ansible.cfg | ||
| deploy.yml | ||
| inventory.cfg | ||
| README | ||
| rollback.yml | ||
| setup.yml | ||
Dress to Impress is deployed to a VPS server. We use this Ansible Playbook to automate the environment setup! We expect to be deploying to Ubuntu 20.04 LTS, initially with nothing installed. The user you deploy with should have sudoers access. That should be all it takes! First, run `yarn deploy:setup` in the app root, to run the `setup.yml` playbook. This will prompt you for your root password, to set up system dependencies. It should be safe to re-run this, including if you add a new dependency to the playbook, because the steps are non-destructive and Ansible will skip steps that are already satisfied. Then, to deploy a new version of the app, run `yarn deploy`. This will build the app from the code on your machine, then send the source and build output to the remote machine, and switch it to be the new production version. Nice! Note that the setup script references a file named `production.env`, which is gitignored because it contains sensitive information, like database passwords. You should create a `production.env` file in the local `deploy/files` directory, to be copied to the remote server and used as its environment variables.