Problem Statement
The team needs a structured, low‑disruption workflow for upgrading software dependencies. The workflow must clarify strategy, risks, testing, rollback, and communication while accounting for breaking changes and CI processes. The goal is to ensure predictable releases using practical, calm guidance.
Steps
Audit Dependencies
INGESTCollect the package list, current versions, changelogs, breaking changes, CI configuration, and release cadence. Normalize this information so it can be used to make upgrade decisions.
Prioritize Upgrades
EXECUTERank dependencies based on severity of breaking changes, security importance, and compatibility. Identify which upgrades can be batched and which require incremental treatment.
Develop Upgrade Strategy and Plan
EXECUTEGenerate the upgrade strategy (batch vs incremental), risk assessment, test plan, rollback steps, and the team communication note. Incorporate a canary rollout phase to reduce disruption.
Validate Strategy Against Constraints
EXECUTEConfirm the proposed plan aligns with release cadence, CI coverage, and known breaking changes. Ensure no missing assumptions or risky gaps remain.
Monitor and Adjust
EXECUTEOutline monitoring steps for canary and full rollouts. Specify conditions for rollback and criteria for stability.
Prompt Configurations
Dependency Upgrade Planning Prompt
You are preparing a dependency upgrade plan. Use the provided package list, versions, breaking changes, CI setup, and release cadence. Produce: (1) upgrade strategy (batch vs incremental), (2) risk assessment, (3) test plan, (4) rollback plan including canary steps, and (5) a calm, practical communication note for the team. Do not invent packages or data; only use what is provided. Keep examples generic and avoid vague advice. The tone must be practical and calm.
Example Inputs/Outputs
Packages: libA 1.2 → 2.0 (breaking change: config format), libB 4.1 → 4.2 (no breaking changes). CI: unit + integration tests, nightly pipeline. Release cadence: weekly. Breaking changes: libA requires config migration.
Strategy: Upgrade libB first as a small incremental change; then upgrade libA alone due to breaking config change. Introduce a canary branch using 10% of traffic for libA upgrade validation. Risks: config incompatibilities and migration script failures. Test plan: run unit, integration, and config‑migration tests in CI; validate on the canary branch for one full day. Rollback: revert to previous version and restore old configs from snapshots. Comms note: explain sequencing, canary timing, and expected developer impact in calm, practical language.