Skip to content

Developing Guide

Jump to bottom
kannankvs edited this page Feb 4, 2020 · 21 revisions

Development Guide

Workflow

All SONiC source code repositories follow a similar branching paradigm, as described in detail below.

  • Master: This branch is always intended to be stable. Pull requests to master are expected to come from finished features branches which have been shown to implement and pass all defined tests.
  • Release: Official builds of the repository are based off these branches (e.g. 201811, 201910). Only pull requests for bug fixes will be accepted.
  • Feature: Feature branches are where development occurs prior to submitting a pull request to master. Feature branches should not be created on the main repository, but rather on forked copies of the project repository. Forked repositories should periodically (i.e. weekly) rebase onto master.

We're following basic GitHub Flow. If you have no idea what we're talking about, check out GitHub's official guide. Note that merges are only performed by the repository maintainer.

Design Specs For New Features

If you are a developer who plans on developing new features for SONiC, you need to follow the Design Guidelines first and write a design spec. Here are some examples:

Test Plans For New Features

If you are developing new features for SONiC, or if you are adding further tests for existing features, you should also write a test plan. Here are some examples:

Development Tutorials

We also have some tutorials for common SONiC development tasks, and some debugging tips:

Clone this wiki locally