-
Notifications
You must be signed in to change notification settings - Fork 517
Main next Automation
The goal of automating main-next integration is to synchronize two branches daily. None of the pending commits should be older than 24 hours. This document outlines immediate tactical steps to get our process going and while allowing us to learn from it.
This is simplified flow that should help us reason about gaps:
- Automation: every 2 hours check if we have open main-to-next PR, and if so, we bail.
- Automation: opens PR with a maximum number of commits. To start with, we will go with 3-5 commits. In average we have ~15commits a day, so we may need to bump this number.
- Automation: assigns PR to the author of the last (most recent) commit in that PR.
- Developer: acknowledges they are actively on it or assigns PR to another developer.
- Process Owner: If the owner does not acknowledge within one hour, we reassign ownership to the owner of the second last commit (and so on). Since commits are recent, it is likely that developer should be around.
- Developer: resolves merge conflicts, CI failures if any and notifies process owner.
- Process Owner: completes final next-to-main cleanup on the PR.
- Process Owner: merges the commit.
With this approach we are minimizing the burden on each developer. Potential pitfall here is that this cycle may need to run few times a day to achieve objective. Ownership assignment could also cause delays. Lastly, if a developer takes ownership but does not complete resolution quickly enough, we will be incurring debts on pending commits.
You will be seeing main-to-next PRs assigned to you with the PR title as Automation: Main Next Integrate. Developers are expected to complete Steps (4) and (6).
- Resolve any merge conflicts between this branch and next thereby pushing the resolution to this branch. Merge next into this branch if needed. Do NOT rebase or squash this branch: its history must be preserved.
- Ensure CI is passing for this PR, fixing any issues. Please don't look into resolving Real service e2e test and Stress test failures as they are non-required CI failures.
This wiki is focused on contributing to the Fluid Framework codebase.
For information on using Fluid Framework or building applications on it, please refer to fluidframework.com.
- Submitting Bugs and Feature Requests
-
Contributing to the Repo
- Repo Basics
- Common Workflows and Patterns
- Managing dependencies
- Client Code
- Server Code
- PR Guidelines
- CI Pipelines
- Breaking vs Non-Breaking Changes
- Branches, Versions, and Releases
- Compatibility & Versioning
- Testing
- Debugging
- npm package scopes
- Developer Tooling Maintenance
- API Deprecation
- Working with the Website (fluidframework.com)
- Coding Guidelines
- Documentation Guidelines
- CLA