CI/CD plan for several services in one repository

You are a delivery engineer. Your goal is to propose a pipeline strategy that deploys each service independently from one shared repository. Inputs: - Services and languages or frameworks: {{services}} - Where they run and how they are packaged: {{runtime_environment}} - Current tooling and team size: {{current_tooling}} - Environments, approvals and compliance needs: {{environments_and_rules}} Steps: 1. State your assumptions. If something that changes the design is missing, ask at most 3 questions, otherwise proceed. 2. Describe how changes are detected per service so only affected services build and deploy; explain shared code and how it triggers dependents. 3. Lay out pipeline stages: build, unit tests, security and dependency checks, package, deploy to test, integration tests, approval, production rollout. 4. Define versioning and artifact naming, and how a deployed version maps back to a commit. 5. Define the rollout method (rolling, blue-green or canary), health checks and the exact rollback trigger and steps. 6. Cover secrets handling, environment configuration and database changes. 7. List metrics to track, such as lead time and failure rate. Output format: - Assumptions. - Stage table: Stage, What happens, Pass criteria, Owner. - Rollout and rollback section. - Risks and a phased adoption plan (week 1, month 1, month 3). Quality bar: stay tool-neutral unless I name tools, avoid deep configuration code, and flag where a choice depends on team size.

You are a delivery engineer. Your goal is to propose a pipeline strategy that deploys each service independently from one shared repository. Inputs: - Services and languages or frameworks: {{services}} - Where they run and how they are packaged: {{runtime_environment}} - Current tooling and team size: {{current_tooling}} - Environments, approvals and compliance needs: {{environments_and_rules}} Steps: 1. State your assumptions. If something that changes the design is missing, ask at most 3 questions, otherwise proceed. 2. Describe how changes are detected per service so only affected services build and deploy; explain shared code and how it triggers dependents. 3. Lay out pipeline stages: build, unit tests, security and dependency checks, package, deploy to test, integration tests, approval, production rollout. 4. Define versioning and artifact naming, and how a deployed version maps back to a commit. 5. Define the rollout method (rolling, blue-green or canary), health checks and the exact rollback trigger and steps. 6. Cover secrets handling, environment configuration and database changes. 7. List metrics to track, such as lead time and failure rate. Output format: - Assumptions. - Stage table: Stage, What happens, Pass criteria, Owner. - Rollout and rollback section. - Risks and a phased adoption plan (week 1, month 1, month 3). Quality bar: stay tool-neutral unless I name tools, avoid deep configuration code, and flag where a choice depends on team size.

Change detection: each service has its own path; a change to shared libraries triggers all services that import them. | Stage | What happens | Pass criteria | Owner | |---|---|---|---| | Unit tests | Run for changed service only | All pass, coverage not lower | Service team | | Deploy to test | Deploy image tagged with commit ID | Health check green in 5 minutes | Pipeline | Rollback: if error rate exceeds 2 percent for 10 minutes after release, redeploy the previous tagged image. Phase 1 (week 1): build and test only. Phase 2: automatic test deploys.