--- name: software-development-lifecycle description: Manage the full software development lifecycle (SDLC) including requirements gathering, sprint planning, code reviews, testing strategies, continuous integration, deployment pipelines, and technical debt management. Use when planning development sprints, establishing coding standards, managing technical debt, implementing CI/CD pipelines, or coordinating release processes. Triggers on phrases like "SDLC", "software development lifecycle", "sprint planning", "code review", "technical debt", "coding standards", "unit testing", "integration testing", "CI/CD pipeline", "continuous integration", "continuous deployment", "code quality", "test coverage", "refactoring", "code freeze", "branching strategy", "Git flow", "trunk-based development". --- # Software Development Lifecycle (SDLC) Manage the full software development lifecycle including requirements, sprint planning, code reviews, testing, CI/CD, and technical debt management. ## Workflow ### 1. Development Process ``` SDLC FRAMEWORK (Agile/Scrum) ═══════════════════════════════════════ Sprint Cadence (2 weeks): ═══════════════════════════════════════ Day 1 Sprint Planning (2 hours) → Review backlog (prioritized stories) → Estimate stories (story points) → Commit to sprint goal → Assign tasks Day 1-8 Development → Daily standup (15 min) → Pair programming (complex tasks) → Code reviews (PR within 24 hours) → Unit tests (TDD or BDD) → Continuous integration (auto-build) Day 7 Sprint Review (1 hour) → Demo completed features → Gather feedback → Update backlog Day 8 Sprint Retrospective (1 hour) → What went well → What didn't go well → Action items (improvements) → Update velocity VELOCITY TRACKING: ═══════════════════════════════════════ Sprint Capacity Completed Velocity Burnup ─────────────────────────────────────────────────────────────── Sprint 1 60 pts 52 pts 52 52/200 Sprint 2 60 pts 55 pts 55 107/200 Sprint 3 60 pts 58 pts 58 165/200 Sprint 4 60 pts 56 pts 56 221/200 Avg velocity: 55 points/sprint Predicted completion: Sprint 4 (on track) ``` ### 2. Code Review Process ``` CODE REVIEW PROCESS ═══════════════════════════════════════ Pull Request Template: ═══════════════════════════════════════ Title: [Type] Brief description → Type: feat, fix, refactor, docs, test, chore Description: → What: What does this PR do? → Why: Why is this change needed? → How: How was it implemented? Testing: → Unit tests: Added/Updated/Not applicable → Integration tests: Added/Updated/Not applicable → Manual testing: Steps to reproduce Checklist: → [ ] Code follows style guide → [ ] Self-review completed → [ ] Tests added/updated → [ ] Documentation updated → [ ] No console.log/debug statements → [ ] No hardcoded secrets/credentials REVIEW CRITERIA: ═══════════════════════════════════════ Code Quality: → Readability: Clear variable names, comments for complex logic → DRY: No duplicated code → SOLID: Follows SOLID principles → Error handling: Proper try/catch, meaningful errors → Edge cases: Handled boundary conditions Testing: → Unit test coverage: ≥80% for new code → Integration tests: API endpoints, database operations → Test naming: describe/it format (BDD) → Test isolation: No shared state between tests Performance: → No N+1 queries → Efficient algorithms (check time complexity) → Proper indexing (database queries) → Memory leaks (garbage collection) Security: → Input validation → SQL injection prevention → XSS prevention → Secrets management (no hardcoded credentials) REVIEW SLAs: ═══════════════════════════════════════ → First review: Within 4 hours → Review turnaround: Within 24 hours → PR size: <400 lines (split if larger) → Required approvals: 2 (minimum) ``` ### 3. Testing Strategy ``` TESTING STRATEGY (Test Pyramid) ═══════════════════════════════════════ / E2E \ 5% of tests / Integration \ 20% of tests / Unit \ 75% of tests Unit Tests: ═══════════════════════════════════════ → Framework: Jest / pytest / JUnit → Scope: Individual functions, methods, classes → Speed: Fast (<100ms per test) → Coverage target: ≥80% → Run: On every commit (CI) Example: describe('UserService', () => { it('should create user with valid data', () => { const user = userService.create({ name: 'John', email: 'john@example.com' }); expect(user.id).toBeDefined(); expect(user.name).toBe('John'); }); it('should throw error for invalid email', () => { expect(() => userService.create({ name: 'John', email: 'invalid' })) .toThrow('Invalid email format'); }); }); Integration Tests: ═══════════════════════════════════════ → Framework: Testcontainers / Supertest → Scope: API endpoints, database operations, service communication → Speed: Medium (1-5 seconds per test) → Coverage: All API endpoints, critical paths → Run: On merge to main (CI) E2E Tests: ═══════════════════════════════════════ → Framework: Cypress / Playwright / Selenium → Scope: User journeys, critical workflows → Speed: Slow (10-60 seconds per test) → Coverage: Happy paths, critical error paths → Run: Nightly (CI), pre-release TEST COVERAGE REPORT: ═══════════════════════════════════════ File Statements Branches Functions Lines Status ──────────────────────────────────────────────────────────────────────── userService.js 92% 88% 95% 92% ✓ Good orderService.js 87% 82% 90% 87% ✓ Good paymentService.js 78% 72% 80% 78% ⚠️ Below authService.js 95% 90% 98% 95% ✓ Good notificationService.js 65% 58% 70% 65% ❌ Low Overall coverage: 82% (target: ≥80%) ✓ Files below 70%: 2 (paymentService, notificationService) ``` ### 4. CI/CD Pipeline ``` CI/CD PIPELINE ═══════════════════════════════════════ Pipeline Stages: ═══════════════════════════════════════ 1. Commit → 2. Build → 3. Test → 4. Security → 5. Stage → 6. Deploy Stage 1: Commit → Pre-commit hooks (linting, formatting) → Husky / pre-commit (enforced) → Commit message lint (conventional commits) Stage 2: Build → Install dependencies → Compile/build (npm run build) → Linting (ESLint, Prettier) → Type checking (TypeScript) Stage 3: Test → Unit tests (Jest) → Integration tests (Testcontainers) → Code coverage (≥80% threshold) → Visual regression ( Percy, Chromatic) Stage 4: Security → SAST (SonarQube, Snyk) → Dependency scan (npm audit, Dependabot) → Secret scanning (git-secrets, truffleHog) → Container scan (Trivy, Clair) Stage 5: Stage → Deploy to staging environment → E2E tests (Cypress) → Smoke tests → Performance tests (k6) Stage 6: Deploy → Approval gate (manual for production) → Deploy to production (canary/rolling) → Health checks → Monitor for 1 hour BRANCHING STRATEGY: ═══════════════════════════════════════ Trunk-Based Development: → main: Production-ready code → feature/*: Short-lived branches (<2 days) → hotfix/*: Emergency fixes → No long-lived branches → Feature flags (for unfinished features) Git Flow (alternative): → main: Production → develop: Integration → release/*: Release preparation → feature/*: New features → hotfix/*: Emergency fixes ``` ### 5. Technical Debt Management ``` TECHNICAL DEBT MANAGEMENT ═══════════════════════════════════════ Technical Debt Register: ═══════════════════════════════════════ ID Description Impact Effort Priority Status Sprint ───────────────────────────────────────────────────────────────────────────────── TD-001 Migrate from jQuery MEDIUM HIGH P2 Planned Sprint 6 TD-002 Refactor auth module HIGH MEDIUM P1 In Prog Sprint 4 TD-003 Update Node.js 14→20 HIGH LOW P1 Done Sprint 3 TD-004 Add API rate limiting MEDIUM LOW P2 Planned Sprint 5 TD-005 Improve error handling MEDIUM MEDIUM P2 Backlog TBD TD-006 Database index opt LOW LOW P3 Backlog TBD TD-007 Remove deprecated APIs HIGH MEDIUM P1 In Prog Sprint 4 DEBT QUANTIFICATION: ═══════════════════════════════════════ → SonarQube: 45 code smells, 12 bugs, 3 vulnerabilities → Estimated fix time: 120 developer hours → Sprint allocation: 20% per sprint (12 points/sprint) → Estimated clearance: 10 sprints (5 months) Quality Gates (CI): ═══════════════════════════════════════ → New code coverage: ≥80% → Duplicated lines: <3% → Security vulnerabilities: 0 critical, 0 high → Code smells: <50 per 1,000 lines → Technical debt ratio: <5% ``` ## Edge Cases - **Legacy systems**: Brownfield development, strangler pattern - **Microservices**: Distributed testing, service contracts - **Monorepo**: Multiple packages, shared dependencies - **Open source**: Community contributions, governance - **Compliance**: Audit trail, approval workflows ## Integration Points - **Version control**: GitHub, GitLab, Bitbucket - **CI/CD**: GitHub Actions, GitLab CI, Jenkins, CircleCI - **Testing**: Jest, Cypress, Playwright, pytest, JUnit - **Code quality**: SonarQube, ESLint, Prettier - **Project management**: Jira, Linear, Asana - **Monitoring**: Sentry, Datadog, New Relic ## Output ### SDLC Status ``` SDLC STATUS — Q4 2024 ═══════════════════════════════════════ Active sprints: 2 (45 stories, 28 completed) Velocity: 55 pts/sprint (avg, stable) Test coverage: 82% (target: ≥80%) ✓ Code review SLA: 4 hours avg (target: <24h) ✓ CI/CD: 98% build success rate Deployments: 24/month (avg, 3/sprint) Technical debt: 7 items (2 in progress, 1 done) Quality gates: All passing Next priority: Refactor auth module (P1), add API rate limiting ```