Inflight Branch Process

In Flight Branch Management

The process involves approving PRs and merging them into the test flight branch, conducting daily tests, and stabilizing the branch before merging it into the main branch.

Introduction:

We are implementing this process because too many PRs get lost in the shuffle while waiting for CI, and they don't get internally validated from our internal testing until too late. The point of this process is to shift reviewing to be the first step. Once a PR has passed that stage, we can merge it to the test flight branch, where it will have to pass CI and manual testing. Once that has all happened, we then merge it to the main branch. The hope here is that we will get more PRs in, and they will be better tested once they get to the main branch. This also lets us insulate the main branch until the in-flight branch has demonstrated that it isn't flakey.

Key Points:

• PR Review Process: PRs are approved and merged into the in flight branch even before tests have ran.
• Merge Requirements: Inflight/Candidate Branch has passed CI and internal testing before merging with main
• Flakey Tests: Strategies to manage flakey tests and reduce their impact on our main branch.

What Branch Should my PR target?

• For the most part, all PRs should still just target main. We will just handle retargeting your PR and merging it into the inflight/current branch
• If a PR is fixing something that was only merged into one of the inflight branches, then the PR can target that specific inflight branch. For example, once we have a candidate branch, the goal is to get it green before merging it into main. So, we will merge these PRs into the candidate branch until it is green.
  • At this point, Syncfusion is managing most of this process. They will monitor the candidate branch and resolve any issues to ensure it becomes green.

PR Review process

• A member of the core team still reviews every single PR
• Once a PR has been approved, we will retarget it ourselves to the inflight branch and the inflight PR will run all the tests.

Process for fixing inflight/current branch

• Currently we are generating our nightly feed from main and the inflight/current branch. So, the most important thing to fix on inflight/current branch are build errors Internal testers also need to use these feeds in order to validate fixes.
• If there's no work to be done on the inflight/candidate branch than work on fixing in flakey or broken tests on the inflight/current branch.

Process for fixing inflight/candidate branch

• If a PR broke "inflight/candidate" branch and it's going to take longer than a few hours to fix just revert the breaking PR and we will fix it on "inflight/candidate"
• When fixing a flakey test that doesn't exist on main, check to see how it works against main. The main thing we're trying to catch here is if the behavior is going to change from merging "candidate" up to "main". If the behavior isn't going to change then we can defer fixing the issue to the "inflight/current" branch.

Workflow

• PRs are still all reviewed by a .NET MAUI Engineer before they are merged into the in-flight branch.
• Once they are merged into the in-flight branch, this allows the PR to run on CI alongside all the other PRs and for the changes to be validated by internal testing earlier in the process.
• We will move this branch to an (inflight/candidate) branch after one week, at which point the only PRs that will be accepted into inflight/candidate are PRs that are stabilizing the branch.
• Once that PR/branch has passed all internal testing and is passing CI without being flakey, then we will merge into the main branch.