Skip to content

馃殌 Server side batch changes

Created by: sourcegraph-bot

Background / Motivation

Adoption Today, batch changes is only available to enterprise users, after a very intensive POC process. Getting users on board batch changes requires a lot of efforts from the sales, CE, product and engineering teams. Batch changes has a lot of value, but the effort required to get started is high.

It has not hurt us yet as we have been focused on large customers that allow for this kind of effort, but we want Batch Changes to be self-serve, so that any developer can get value out of it in the future.

A large part of the problem is setup: to use Batch Changes today, users need to grok the concepts of batch changes, install a CLI, manually generate a token to connect it to the instance, generate a token to connect Sourcegraph to the codehost, write a spec, then iterate locally on a batch change. Users can start with a ready-made example, but provided that they take the time to read through the example website and get this example locally.

Overall, this greatly limits adoption (we lose users that don't want to go through a POC process), and makes it costly (we have to be all hands on deck to set interested customers for success).

Rather, users should search for a symbol, click a button to generate a spec template, and be able to run a batch change from there without leaving the Sourcegraph GUI.

Offloading compute

As we deliver Batch Changes to larger companies, that have more complex use cases (eg. Java refactoring), it becomes prohibitive for users to run batch changes on their own machine.

Although this is represents a small number of customers, users from the companies with the most advanced tooling expect a solution to create batch changes without the use of a local CLI, and not providing that is a show stopper.

We do need to take into account the customer concern that creating batch changes from the server could cause accidental DoS on the Sourcegraph instance, but this does not appear to be a blocker.

Cool features

We envision that Batch Changes could be used to schedule recurring batch changes and to enforce invariants. Batch changes could feature a starting library of rules, that users can choose from and have running on their codebase in a few seconds. This experience is blocked because there is nowhere those ready-made batch changes can execute right now.

Similarly, Batch Changes could generalize an IntelliJ-style symbol search and replace, that would run on the entire codebase instead of on a repository.

This future vision is blocked until we can run batch changes independently of the CLI or a single developer's machine.

Success criteria

This is a success criteria framework for this initiative, each milestone should have its own detailed success criteria, narrowing those categories into clear success criteria.

  • UX: Users can create their batch changes entirely from the GUI (the CLI flow will still exist)

  • Setup/Compute: Users don't need a local environment to create Batch Change

  • Debugging experience: It's easy for users to understand, debug, inspect what's going on when they create a batch change. They can inspect the run containers and get to

  • Security: Users will need to be able to run arbitrary containers

  • Deployment: server side batch changes needs to be compatible and sustainable in many customer environment.

  • Scale: the solution needs to be compatible with autoscaling, and eventually allow for all Sourcegraph users to create batch changes provided that site-admin provide the right infrastructure size. The solution also needs to be compatible with sourcegraph.com deployment.

Proposal

We are working on a proposal for executing batch changes server side: Batch Changes server side execution: runners.

CI runners sound like the right analogy / inspiration. They serve the same need (providing compute), have roughly the same security constraints, and are well adopted in our target market.

Resources

Documents

Prototypes

  • Erik鈥檚 src runner prototype that鈥檚 based on RFC 135: src-cli#139

Discussions