Files
zed/crates/collab
Conrad Irwin f2fc84ab44 Revert change to tracing (#10578)
Although we thought this fixed the bug, it just worked around it, and
runnign two copies of tracing in one app is a bad idea.

Simplify default RUST_LOG in development to avoid
 https://github.com/tokio-rs/tracing/issues/2927#issuecomment-2040080189



Release Notes:

- N/A
2024-04-15 14:00:56 -06:00
..
2024-04-03 11:35:23 -06:00
2024-04-12 11:40:59 -06:00
2024-04-11 15:36:35 -06:00
2024-04-11 15:36:35 -06:00
2024-04-15 14:00:56 -06:00
2024-03-22 08:44:56 -06:00

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:

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/create-migration <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.