Developing Guide

Developing 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 this branch. Only 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 (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.

New Features

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

• Port Breakout
• MMU Allocation
• PFC Watchdog
• LogAnalyzer
• SONiC to SONiC update

New Tests

Here are some examples

• ACL Test Plan
• DHCP Relay Agent Test Plan
• Everflow Test Plan
• FIB Scale Test Plan
• IPv4 Decapsulation Test
• LAG Feature Test Suite
• VLAN Feature Test Suite

HOWTO

We also have some HOWTO guide for some debugging tips:

• HOWTO Compile and Run SAI Server Docker
• HOWTO Reset syncd Docker
• HOWTO Write a PTF Test
• Using swssconfig to apply configuration
• How to Deploy SONiC
• How to Use SAI Player