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 GitHub issues, which act as the central repository for tracking and managing changes to our software applications. This methodology includes the following key components:
- 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.
- 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.
- 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.
- Additional Artifacts: In addition to GitHub 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.
- 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 and enabled by EPD and 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.
Verification and Testing
The testing phase ensures that the solution meets the specified product requirements for the feature. Automated vulnerability scanning and SAST (Static Application Security Testing) are integrated into our CI/CD pipeline to assess security. Features may initially be behind feature flags for testing and continuous releasability.