IT AI Skill

Software Development Lifecycle

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, es...

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: '[email protected]' });
        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