Cc Integration Practices

Skill: cc-integration-practices

STOP - Integration Rules

• Never Big Bang integration - Add components one at a time
• Fix broken builds immediately - Within 1 hour; stop all other work
• Daily build is MINIMUM - Not a ceiling; modern CI/CD goes faster

Quick Reference

Key Principles:

• Integrate incrementally, not all at once (Big Bang)
• Each integration step must produce a working system
• Build daily, test with smoke test
• Fix broken builds immediately

Key Definitions

• Smoke test: Small (<15 tests), fast (<5 min), automated end-to-end sanity check. NOT a full test suite.
• Working system: Compiles without errors, existing tests pass, smoke test passes.
• Immediately: Within 1 hour; escalate if blocked. Revert counts as a fix.
• Daily build: Main branch builds successfully at least once per calendar day.

Core Patterns

Big Bang -> Incremental Integration

// BEFORE: Big Bang Integration [ANTI-PATTERN]
Phase 1: Develop all units separately
Phase 2: Combine everything at once
Phase 3: "System dis-integration" - debug the mess
Result: All problems surface at once, interact, mask each other

// AFTER: Incremental Integration
Step 1: Integrate component A, test
Step 2: Add component B, test combination
Step 3: Add component C, test combination
...continue until complete
Result: Each problem isolated to most recent addition

No Build Process -> Daily Build + Smoke Test

// BEFORE: Ad-hoc Builds [ANTI-PATTERN]
- Build when "ready" (days or weeks apart)
- No automated verification
- "Works on my machine" syndrome
- Integration problems accumulate undetected

// AFTER: Daily Build + Smoke Test
- Automatic compile/link/combine every day
- Smoke test runs end-to-end verification
- Broken build = immediate fix priority
- Problems caught within 24 hours of introduction

Architecture-Ignorant -> Strategy-Aligned Integration

// BEFORE: Bottom-Up Driven by Convenience [ANTI-PATTERN]
- Start with whatever is "ready"
- Let low-level code drive high-level design
- Contradicts information hiding
- High-level must adapt to low-level decisions

// AFTER: Strategy-Aligned Integration
- Choose strategy based on project needs
- High-level drives low-level (top-down), OR
- Risk-critical components first, OR
- Feature-oriented slices, OR
- T-shaped vertical slice to verify architecture

Modes

CHECKER

Purpose: Execute integration strategy and daily build checklists Triggers:

• "review our integration approach"
• "check our build process"
• "assess integration readiness" Non-Triggers:
• "which integration strategy should we use" -> APPLIER
• "set up daily builds" -> APPLIER Checklist: See checklists.md Output Format:

  Item	Status	Evidence	Location
  Severity:

• VIOLATION: Big Bang integration, no daily build, stale smoke test
• WARNING: Infrequent builds, incomplete smoke test
• PASS: Meets integration and build requirements

APPLIER

Purpose: Select integration strategy and establish daily build process Triggers:

• "plan integration strategy"
• "how should we integrate these components"
• "set up our build process"
• "which integration order" Non-Triggers:
• "review our current integration" -> CHECKER

Integration Strategy Selection

Evaluate in sequence. Stop at first YES - that determines your strategy.

1. Is there high architectural risk or uncertainty?
   (>3 external integrations, unproven tech, novel patterns)
   YES -> T-Shaped Integration (vertical slice to verify architecture early)
   NO  -> Continue

2. Are there clear high-risk components?
   YES -> Risk-Oriented Integration (hardest parts first)
   NO  -> Continue

3. Is the system hierarchical with clear layers?
   YES -> Does high-level need early exercise?
         YES -> Top-Down (stubs for lower classes)
         NO  -> Does low-level need early verification?
               YES -> Bottom-Up (test drivers for higher)
               NO  -> Sandwich (high + low first, middle last)
   NO  -> Continue

4. Are there distinct feature sets?
   YES -> Feature-Oriented (one feature tree at a time)
   NO  -> Use Incremental with any sensible order

Daily Build Setup Procedure

1. Can you compile/link/combine into executable automatically?
   NO  -> Set up automated build script FIRST
   YES -> Continue

2. Is build run at least daily?
   NO  -> Schedule daily build (fixed time, off-peak)
   YES -> Continue

3. Is there a smoke test?
   NO  -> Create smoke test covering end-to-end execution
   YES -> Does it cover recent additions?
         NO  -> Update smoke test (stale test = self-deception)
         YES -> Continue

4. What happens when build breaks?
   "Fix tomorrow" -> WRONG: Fix immediately, stop all other work
   "Skip smoke test once" -> WRONG: Smoke test is the sentry
   Fix immediately -> Correct

Produces:

• Integration strategy recommendation with rationale
• Integration order/sequence
• Daily build configuration
• Smoke test requirements Constraints:
• Never let build stay broken overnight (p.704)
• Smoke test must exercise end-to-end (p.705)
• Check-in at least every 2 days (p.703)

Already Built Everything Separately?

If you've built all components in isolation and are about to combine them: STOP.

Building separately is fine. Combining all at once means ALL interface bugs surface simultaneously - that's Big Bang. Your components aren't wasted, but add them one at a time to isolate issues to each addition.

Rationalization Counters

Benefits of Careful Integration

• Easier defect diagnosis (isolated to recent addition)
• Fewer defects slip through
• Less scaffolding code needed
• Shorter time to first working product
• Shorter overall development schedules
• Better customer relations (demonstrable progress)
• Improved developer morale
• Improved chance of project completion
• More reliable schedule estimates
• Accurate status reporting
• Improved code quality
• Less integration documentation needed

Chain