Practise vocabulary for planning and communicating a migration from polyrepo to monorepo: consolidation, cut-over, risk communication, and team coordination.
0 / 13 completed
1 / 13
The process of moving multiple separate repositories into a single monorepo is called ___ consolidation.
Repository consolidation is the process of merging polyrepos into a monorepo. Tools like git-filter-repo and git subtree help migrate history while preserving commit authorship.
2 / 13
During a monorepo migration, a ___ period prevents new features from being merged to the old repositories while the migration is in progress.
A freeze period (also called a code freeze or merge freeze) pauses new commits to the source repositories during migration to prevent conflicts and ensure a clean, complete import.
3 / 13
The ___ date is the planned moment when teams switch from the old polyrepo structure to the new monorepo for all development work.
The cut-over (or go-live) date marks the switch to the new monorepo. Teams need to update their local clones, CI configurations, and CODEOWNERS assignments after this date.
4 / 13
A key risk to communicate in a monorepo migration plan is ___ during initial CI runs as caches are empty and all packages rebuild.
Initial CI runs in a new monorepo are slow because the build cache is empty. Teams should expect and communicate this 'cold cache' period and plan for gradual cache warming.
5 / 13
`git filter-repo` is a tool used during monorepo migration to ___.
git filter-repo rewrites git history, enabling teams to import code from a polyrepo into a monorepo subdirectory while preserving the full commit history, authors, and timestamps.
6 / 13
Review Comment: "Hey @john_doe, I noticed you've been using the npm install command directly on the `frontend` repo to fetch dependencies. During this monorepo migration, we need to use the centralized package manager setup – it's crucial for consistent builds and avoiding conflicts. Could you please update your scripts to utilize the new package management system?"
This question tests understanding of the immediate practical impact during a monorepo migration. The core issue isn't just about syntax; it's about adhering to the new, centralized package management strategy established for consistency and avoiding problems caused by inconsistent dependency versions across repositories. John's approach is technically fine in *some* contexts, but not within the specific constraints of the migration process.
7 / 13
Slack Message: @alice_smith (Lead Engineer): "Just a heads up – we're anticipating some increased CI build times over the next few days as the teams are still resolving conflicts between the old and new repository structures. Please be patient with any failures."
This assesses the ability to interpret communication related to common challenges. The question focuses on anticipating increased CI build times – a very real concern during a monorepo migration due to the complex refactoring and potential for unresolved conflicts that require re-builds. It's not just about delays; it's proactive advice.
8 / 13
PR Description: "This PR updates the build script to leverage the monorepo's centralized package manager. It also includes a temporary override for the dependency version in the `backend` repo to allow for testing of the new tooling without impacting core functionality."
This explores understanding of common PR practices. While it's *typical* to introduce overrides temporarily for testing, the description acknowledges this as a necessary step in the migration process. The key is recognizing that temporary measures are often part of the strategy, not a sign of poor design – provided they're documented and have rollback plans.
9 / 13
@bob_jones (Senior Developer) comments on a PR: "I'm seeing some slow builds when I try to run tests after merging this change. It seems like the monorepo's dependency cache hasn't fully populated yet. Should we be focusing our efforts on increasing the CI build node size, or is there something else we can do?"
The correct answer acknowledges the reality of empty caches during a monorepo migration. Simply increasing node size won't address this core issue. Waiting allows the cache to populate organically, and while reverting isn't ideal, it highlights the need for deeper investigation into potential conflicts – which is what Bob is implicitly asking.
10 / 13
API Response: `{
"status": "warning",
"message": "Monorepo migration in progress. Dependency resolution may experience intermittent delays.",
"details": [
"Temporary overrides for dependency versions are being utilized.",
"Increased CI build times are expected due to initial cache invalidation."]
}`,
What does this API response primarily indicate?
The API response clearly flags a 'warning' and highlights potential 'intermittent delays' related to dependency resolution. This aligns with the expected behavior during a monorepo migration where caches are initially empty, leading to rebuilds. It's *not* a critical failure, nor does it suggest infrastructure upgrades – those would be separate concerns.
11 / 13
@charlie_brown (DevOps Engineer) sends a Slack message: "We've configured the CI pipeline to use Docker layers for dependency caching. However, we're still seeing significant rebuild times because many of the base images are being redownloaded repeatedly. Any suggestions?"
The core issue is redundant image downloads during the migration. Disabling Docker layer caching is a drastic step that doesn't address the root cause of the problem – the cache isn't being utilized effectively due to the monorepo structure. Caching layers within the CI environment or a larger build node would be better long-term solutions, but disabling the cache provides immediate relief.
12 / 13
PR Description: "This PR introduces a new automated script to manage dependency versions across the monorepo. The script uses a centralized repository to store and synchronize version numbers for all packages. This should minimize conflicts and ensure consistency during the migration process."
The description highlights the *primary* purpose: resolving build errors caused by conflicting versions. While consistency is a benefit, and a single source of truth is an outcome, the core function is version conflict resolution – this is crucial during a migration where old and new repositories are interacting.
13 / 13
During a standup meeting, @diana_lee (Tech Lead) states: "We're seeing some unexpected package resolution issues when building the `api` service. It seems like the monorepo's tooling isn't fully understanding the dependencies between services yet." What is the most likely underlying issue?
Diana's statement points to a lack of understanding by the tooling – specifically, how dependencies are resolved *within* the monorepo. This strongly suggests that the dependency relationships haven't been clearly defined or understood during the migration, leading to resolution problems. The other options represent potential secondary issues but aren't the root cause.
What will I practise in "Monorepo Migration Language"?
This module focuses on Monorepo Build Systems — real workplace phrasing you'll use on the job. It contains 13 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 13 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Monorepo Build Systems exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around monorepo build systems — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Monorepo Build Systems exercises?
See the Monorepo Build Systems hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.