Development workflow

The MongoDB server is developed against a single long-lived master branch. Releases are cut from release branches that fork off master near the start of a release cycle.

Where work is tracked

• JIRA: tickets are tracked at jira.mongodb.org under the SERVER project. Every commit references a SERVER-NNNNN ticket.
• GitHub: PRs land via GitHub. External contributors fork the repo and open PRs against master.
• Evergreen: MongoDB's CI system. Each PR triggers a "patch build" that runs the relevant resmoke suites across the supported platforms.

The configuration that drives Evergreen lives under evergreen/. The top-level etc/evergreen*.yml defines tasks; the shell scripts under evergreen/ are the task implementations.

Typical patch flow

graph LR
    A[Pick up SERVER ticket] --> B[Branch off master]
    B --> C[Write tests + code]
    C --> D[bazel build install-devcore]
    D --> E[buildscripts/resmoke.py run --suites=core ...]
    E --> F[bazel run format / clang-tidy]
    F --> G[Commit referencing SERVER-NNNNN]
    G --> H[Push to fork]
    H --> I[Open PR]
    I --> J[Evergreen patch + reviews]
    J -->|approved| K[Merge to master]

Branch and commit conventions

• One ticket per PR is the norm. If a fix needs to backport, the backport carries the same ticket number and an explicit suffix.
• Commit messages start with SERVER-NNNNN and a short summary. Multi-commit PRs are squashed at merge time.
• Branches use snake-case names like server-12345-fix-foo. The naming is not enforced.

Backports

When a fix needs to land in a release branch (e.g. v8.0, v7.0), it's typically:

1. Landed on master first.
2. Cherry-picked to the release branch as a separate PR.
3. Verified against the release-branch-specific Evergreen suites.

The Evergreen workflow understands "backport" patches and fans the same tests across multiple branches.

Feature flags and FCV

Most non-trivial features are introduced behind a feature flag declared in IDL (see Patterns and conventions and src/mongo/db/feature_flag.h). The flag is gated by a binary version: when the cluster's Feature Compatibility Version (FCV) is below the flag's required version, the flag returns false and the feature is hidden. This lets the team land in-progress features on master without exposing them in releases until they're ready.

The FCV machinery lives under src/mongo/db/commands/set_feature_compatibility_version_steps/ and the flag definitions are scattered through the codebase under files named *_feature_flags.idl.

What lands where

Type of change	Lands in
Server bugfix	master, then backported as needed to live release branches.
New feature	master only, behind a feature flag. The flag is enabled in the release that GA's the feature.
Performance improvement	master and, in some cases, backported when low-risk and high-impact.
Build-system or tooling change	master. Backports are uncommon.
Test-only change	master. Backports follow the corresponding fix.

Pre-commit hooks

The Poetry virtualenv installs the lint/format pre-commit toolchain. Running bazel run format reformats the entire tree using clang-format, prettier, and the in-tree formatters. buildscripts/clang_format.py format-my is the targeted variant that only touches files changed in your branch.

If the pre-commit hooks rewrite files, amend your commit. The Evergreen build is strict and fails on formatting drift.