Introduction

This handbook outlines the software development life cycle (SDLC) methodology used at Sourcegraph. It serves as a reference guide for all team members involved in the software development process. Our SDLC methodology is designed to ensure effective planning, execution, and delivery of software projects while maintaining transparency and accountability.

Overview

At Sourcegraph, we utilize a structured approach to software development. Our SDLC methodology is primarily driven by Linear issues, which act as the central repository for tracking and managing changes to our software applications. This methodology includes the following key components:

1. Roadmap Items: We maintain a roadmap tracker to list objectives for each quarter, with individual issues detailing these objectives. Each issue is tagged with ownership information, including the owning organization, team, and assignees responsible for updates.
2. Tracking Issues: Tracking issues are used to capture planned and ongoing work related to milestones, projects, RFCs (Request For Comments), goals, and more. They serve as a planning tool, facilitate progress check-ins, and aid in stakeholder communication.
3. Standard Issues: Standard issues represent tasks, bugs, or exploratory work owned by specific teams, indicated by labels such as team/NAME. Teams have flexibility in defining the content and labels for standard issues.
4. Additional Artifacts: In addition to Linear issues, we use PRDs to communicate product plans and RFCs to discuss specific issues and make decisions.

Workflow

Our software development process follows a structured workflow:

Design Phase

The design phase involves defining the solution to a problem. Detailed design processes are described in our Design process.

Product Lifecycle Labels

We use labels to communicate the quality and support level of our products and features to our customers. These labels are assigned subjectively but not arbitrarily, following these guidelines:

• Early Access Program (EAP):
  • The one liner: We opt in customers.
  • Shared privately with NDA's customers.
  • Supported and enabled by EPD.
  • Feature implementations represent super early functionality.
  • Not suitable for production workloads.
  • Goals: Assess potential, identify improvements.
• Experimental:
  • The one liner: Anyone can opt in.
  • Shared publicly.
  • Supported and enabled by EPD.
  • Feature implementations represented are in super early functionality.
  • Unsupported.
  • Goals: Assess potential, identify improvements.
• Research Preview
  • A label for when we expect the capabilities and features to change not just based on iterative customer feedback but on fundamental technological advances
  • Formally as it applies to our customer contracts, research preview means “beta” and we note that somewhere when we use the research preview label
• Beta (n):
  • The one liner: On by default, but customers can opt out.
    • Note that “opt out” should be interpreted broadly. E.g. a new button that a user could just choose not to press is a good enough opt out mechanism. It doesn’t have to be a flag.
  • Shared publicly (although private betas are sometimes used).
  • Supported by EPD
  • Enabled by TS
  • Features are fully implemented, although may need additional quality and performance improvement.
  • Best-effort support.
  • No guarantee of stability between beta versions.
  • Goals: Gather feedback, fix bugs, optimize performance, train sales and support staff, finalize documentation.
• General Availability (GA):
  • The one liner: This is the only version of the experience.
  • Publicly available.
  • Supported and enabled by TS.
  • Suitable for production workloads.
  • Fully supported using industry best practices.
  • Performance optimized.
  • No new features without sufficient "bake time."
  • Come with scenario-complete docs + samples.
  • Sales and support staff trained and ready to go.
  • Goals: Continual stability and improvement.

Change Management