Max Brunsfeld
dfcc143ead
This is just a refactor. I noticed that we now have a `project_core` crate, which mainly contains the `Worktree` type and its private helpers, plus the project's settings. In this PR, I've renamed that crate to `worktree` and did some minor simplification to its module structure. I also extracted a new `WorktreeSettings` settings type from the `ProjectSettings`, so that the worktree settings could live in the worktree crate. This way, the crate is now exclusively about worktree logic. Release Notes: - N/A
Zed Server
This crate is what we run at https://collab.zed.dev.
It contains our back-end logic for collaboration, to which we connect from the Zed client via a websocket after authenticating via https://zed.dev, which is a separate repo running on Vercel.
Local Development
Detailed instructions on getting started are here.
Deployment
We run two instances of collab:
- Staging (https://staging-collab.zed.dev)
- Production (https://collab.zed.dev)
Both of these run on the Kubernetes cluster hosted in Digital Ocean.
Deployment is triggered by pushing to the collab-staging (or collab-production) tag in Github. The best way to do this is:
./script/deploy-collab staging./script/deploy-collab production
You can tell what is currently deployed with ./script/what-is-deployed.
Database Migrations
To create a new migration:
./script/sqlx migrate add <name>
Migrations are run automatically on service start, so run foreman start again. The service will crash if the migrations fail.
When you create a new migration, you also need to update the SQLite schema that is used for testing.