Optimizing Monorepos with Rush and Mergify

Rush is a renowned open-source build orchestrator facilitating the handling, building, and publishing of multiple packages within a single Git monorepository (monorepo). Rush efficiently breaks up large applications into manageable pieces, each with its lifecycle and build processes. In a Rush-enabled monorepo, Mergify enhances the development workflow by automating merges, implementing project-specific merge queues, and adapting workflows to each sub-project's unique requirements.

Why Mergify with Rush?

Mergify’s merge queue comes furnished with exclusive features, especially designed for managing high velocity, large-scale monorepo projects. These features enable:

• Independent management of each sub-project;
• Uninterrupted and parallel development cycles for each sub-project;
• Adaptation to each project’s unique processes and CI checks.

Partition rules are Mergify's solution to monorepo management complexities. Each partition operates in parallel and encompasses all the queues defined in the queue_rules. They function independently, allowing multiple sub-projects to coexist, each running their merge cycles without interference from the others.

Integrating Rush Project Structure with Mergify

Implementing Partition-Based Merge Queues

Once Rush has modularized your project, each sub-project or app can have its Mergify merge queue, automated according to its specific needs, CI checks, and development lifecycle.

Creating Partitions for Each Project

To implement this, we define partitions for each sub-project using partition_rules in our Mergify configuration. Each partition can then have its specific queue_rules defining the merge conditions based on each sub-project’s requirements.

Example Configuration

Here’s a simplified example where Rush has split a project into projectA, projectB, and projectC, and we create a partition and queue for each:

1
partition_rules:
2
  - name: projectA
3
    conditions:
4
      - files~=^apps/projectA
5

6
  - name: projectB
7
    conditions:
8
      - files~=^apps/projectB
9

10
  - name: projectC
11
    conditions:
12
      - files~=^apps/projectC
13

14
queue_rules:
15
  - name: default
16
    merge_conditions:
17
      - and:
18
        - or:
19
          - partition-name!=projectA
20
          - check-success=ciA
21
        - or:
22
          - partition-name!=projectB
23
          - check-success=ciB
24
        - or:
25
          - partition-name!=projectC
26
          - check-success=ciC

In this configuration:

• Pull requests modifying files in projectA will be managed by the projectA partition. Same for other projects.

• If a pull request alters files in multiple projects, it will be processed in each corresponding partition independently.

Conclusion

Merging Mergify's automation prowess with Rush’s monorepo management capabilities leads to a streamlined, efficient, and organized development workflow. It not only fosters parallel development but also ensures each sub-project retains its unique development rhythm, making monorepo management a breeze.