Skip to content
DocsAll docs
Console

Use cases

Use cases for desks, from a single developer to a team that tests its changes together on one environment.

Last updated

On this page

Overview

Each use case below uses only desks, their workspaces, the environment connection, and intercepts. The examples use a team acme with an environment shop that runs web, api, worker, and db.

Use caseWhoWhat you get
Start on a projectA new developerA working set-up against the real services, with nothing installed locally
Change the frontend and the backend togetherOne developerTwo components that you change and run side by side
Debug a failing request with real trafficOne developerYour code answers the real calls of the environment
Test two changes against each otherTwo developersA request that passes through both changes before either is merged
Reproduce a bug without disturbing the teamOne developerA private copy of the environment to break and fix
Review a pull request in a real environmentA reviewerThe change running against the services, not only the diff
Run integration tests against the servicesA developer or a pipelineA test run that reaches every service by name
Stop everything with one callAnyoneAll workspaces of a piece of work stopped, kept, and started again together

Start on a project

Situation. A developer joins the team. The application needs a database, a queue, and three services to run.

Set-up. The developer creates a desk in acme, connects it to shop, and creates a workspace in the desk with the repository and its packages.

Result. The code in the workspace reaches db, api, and the other services by name. There is nothing to install, seed, or configure on the laptop. See Create a desk and Create a workspace in a desk.

Change the frontend and the backend together

Situation. A feature needs a change to web and to api.

Set-up. One desk holds two workspaces, frontend and backend. The developer intercepts web with frontend and api with backend.

Result. A request to web reaches the frontend change, which calls api and reaches the backend change. Both run against the real db and worker.

Debug a failing request with real traffic

Situation. Some requests to api fail, and only with the data and the callers of the environment.

Set-up. The developer intercepts api with a workspace that runs the service under a debugger.

Result. The failing request arrives in the workspace. The developer adds logs or breakpoints and saves; the next request runs the new code. When the bug is fixed, the developer removes the intercept and api takes its traffic back. See Intercept a service.

Test two changes against each other

Situation. Two developers change web and api for the same feature, in separate branches.

Set-up. Each developer connects their own desk to shop. One intercepts web, the other intercepts api.

Result. A request passes through both workspaces. The two changes are tested together before either is merged. See task 002.

CAUTION

An intercept affects every developer on the environment. Agree who intercepts which service before you start.

Reproduce a bug without disturbing the team

Situation. A bug needs changes to the data or to a service that other developers use.

Set-up. The developer clones shop, connects their desk to the copy, and intercepts there.

Result. The developer changes data and services freely. Nobody else on shop is affected. The copy is deleted at the end. See task 001.

Review a pull request in a real environment

Situation. A reviewer wants to see a change run, not only read it.

Set-up. The reviewer creates a workspace in their own desk and checks out the branch of the pull request. The reviewer then intercepts the service that the change touches. In a shared environment, the reviewer uses a copy.

Result. The reviewer calls the service and sees the change answer with real data. The workspace is deleted after the review.

Run integration tests against the services

Situation. A test suite needs the real services, not mocks.

Set-up. A capsule is created through the desk, with the test command.

Result. The tests reach every service of the environment by name, and the capsule ends when the run ends. Pipelines use the same model for their jobs. See Capsules.

Stop everything with one call

Situation. A piece of work uses several workspaces, and the developer stops for the day.

Set-up. The developer stops the desk.

Result. All workspaces of the desk stop together, and their homes are kept. Starting the desk starts them again. Without any call, an unused desk stops by itself after 30 minutes. See Stop a desk.

Tasks

Work against a copy of an environment

Reason for the task

Test a change, or intercept a service, without affecting the other desks on a shared environment.

Job set-up

Procedure

  1. Clone the shared environment. The copy has the same services and data, and belongs to the same team.

    Python
    kl.environments.clone(environment="acme/shop", to="shop-dev")
    TypeScript
    await kl.environments.clone({ environment: "acme/shop", to: "shop-dev" });
    Go
    if _, err := kl.Environments.Clone(kloudlite.CloneEnvironment{Environment: "acme/shop", To: "shop-dev"}); err != nil {    log.Fatal(err)}
    Ruby
    kl.environments.clone(environment: "acme/shop", to: "shop-dev")
    Java
    kl.environments().clone(new Kloudlite.CloneEnvironment().environment("acme/shop").to("shop-dev"));
    CLI
    kode environments clone acme/shop --to shop-dev
  2. Connect your desk to the copy. The workspaces of the desk now reach the services of the copy.

    Python
    kl.desks.connect(desk="acme/dev", environment="shop-dev")
    TypeScript
    await kl.desks.connect({ desk: "acme/dev", environment: "shop-dev" });
    Go
    env := "shop-dev"if _, err := kl.Desks.Connect("acme/dev", &env); err != nil {    log.Fatal(err)}
    Ruby
    kl.desks.connect(desk: "acme/dev", environment: "shop-dev")
    Java
    kl.desks().connect("acme/dev", "shop-dev");
    CLI
    kode desks connect-env shop-dev --desk acme/dev
  3. If you test a change against real traffic, intercept a service of the copy. See Intercept a service.

Close-out

  1. When you are done, connect the desk to the shared environment again, and delete the copy.

Collaborate on a shared environment

Reason for the task

Let several developers test their changes against each other, each in their own desk.

Job set-up

  • Access: each developer, in their own desk of the same team.
  • Conditions: the team has an environment, for example acme/shop with the services web and api.
  • References: Connect an environment, Intercept a service.
CAUTION

An intercept affects every developer on the environment. Agree who intercepts which service before you start.

Procedure

  1. Connect your own desk to the environment, as each developer does in theirs (Connect an environment).
  2. Send the traffic of the service that you change to a workspace of your desk, for example api. Another developer intercepts another service, for example web (Intercept a service).
  3. Send a request to web to test end to end. It reaches the other developer's workspace, which calls api and reaches yours.

Close-out

  1. Remove your intercept, and make sure that the other developers remove theirs (Remove an intercept). The services take their traffic back.

Troubleshooting

SymptomPossible causeCorrective action
409 with desk dev (karthik) already intercepts this serviceAnother developer holds the intercept on the shared environment.Ask the holder to release it, or work in a copy.
Other developers see your change answer their requestsYour intercept is in force on a shared environment.Remove the intercept, or move your work to a copy.
The copy of the environment counts against your quotaA clone is a full environment.Delete the copy when you are done.