Developing Guide
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.
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:
- ACL
- ECMP and LAG Hash Seed
- Enable ECN on lossless queues
- LogAnalyzer
- Management Framework
- MMU Allocation
- NAT
- PFC Watchdog Design
- Port Breakout and Speed
- Sub Port Interface
- TACACS+
- Warm Reboot
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:
- ACL Test Plan
- BSL 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
We also have some tutorials for common SONiC development tasks, and some debugging tips:
-
For Users
-
For Developers
-
Subgroups/Working Groups
-
Presentations
-
Join Us