What is the SDLC?#

The Software Development Lifecycle is the process of planning, creating, testing, deploying, and maintaining software. Different methodologies organize these phases differently, but the activities are universal.


SDLC Phases#

flowchart LR
    Plan["Plan"] --> Design["Design"]
    Design --> Build["Build"]
    Build --> Test["Test"]
    Test --> Deploy["Deploy"]
    Deploy --> Operate["Operate"]
    Operate --> Plan
PhaseActivitiesOutputs
PlanRequirements, prioritization, estimationUser stories, backlog
DesignArchitecture, API contracts, data modelsDesign docs, ADRs
BuildWrite code, unit tests, code reviewWorking software
TestIntegration tests, QA, UATTest reports, bug fixes
DeployRelease to productionRunning service
OperateMonitor, maintain, supportMetrics, incident responses

Methodologies#

Waterfall#

Sequential phases — each completes before the next begins:

Requirements → Design → Implementation → Testing → Deployment → Maintenance
ProsCons
Clear milestonesLate feedback
Predictable timelineExpensive to change
Good for fixed requirementsRisk concentrated at end

Agile (Scrum)#

Iterative — deliver working software in short cycles (sprints):

flowchart LR
    PB["Product<br/>Backlog"] --> Sprint["Sprint<br/>(2 weeks)"]
    Sprint --> Increment["Working<br/>Increment"]
    Increment --> Review["Review +<br/>Retro"]
    Review --> PB
CeremonyPurposeDuration
Sprint PlanningSelect work for sprint2-4 hours
Daily StandupSync, unblock15 minutes
Sprint ReviewDemo to stakeholders1 hour
RetrospectiveImprove process1 hour

Kanban#

Continuous flow — no fixed sprints, limit work in progress:

TO DO → IN PROGRESS (WIP limit: 3) → REVIEW → DONE
AspectScrumKanban
CadenceFixed sprintsContinuous flow
RolesScrum Master, PO, TeamNo prescribed roles
PlanningSprint planningJust-in-time
Best forFeature developmentSupport, ops, maintenance

CI/CD (Continuous Integration / Continuous Delivery)#

Continuous Integration#

Every code change is automatically built and tested:

flowchart LR
    Push["Git Push"] --> Build["Build"]
    Build --> Test["Run Tests"]
    Test --> Lint["Lint + Security Scan"]
    Lint --> Report["Report Results"]

Continuous Delivery / Deployment#

TermMeaning
Continuous DeliveryEvery change CAN be deployed (manual trigger)
Continuous DeploymentEvery change IS deployed automatically
flowchart LR
    CI["CI (build + test)"] --> Staging["Deploy to Staging"]
    Staging --> Approval{"Manual Approval?"}
    Approval -->|CD| Prod["Deploy to Production"]
    Approval -->|Continuous Deployment| Prod

Pipeline Stages#

Commit → Build → Unit Tests → Integration Tests → Security Scan → Deploy (test) → Deploy (prod)

Testing Pyramid#

flowchart TD
    E2E["E2E Tests (few, slow, expensive)"]
    Integration["Integration Tests (moderate)"]
    Unit["Unit Tests (many, fast, cheap)"]
LevelTestsSpeedScope
UnitIndividual functions/classesMillisecondsSingle component
IntegrationComponents working togetherSecondsMultiple components
E2EFull user workflowsMinutesEntire system

Rule: Many unit tests, fewer integration tests, minimal E2E tests.


Environments#

EnvironmentPurposeWho Uses It
Local (dev)Developer’s machineIndividual developer
TestAutomated testingCI/CD pipeline
Staging (pre)Production-like validationQA, stakeholders
ProductionReal usersEveryone

Principle: Environments should be as similar as possible. Differences between staging and production cause “works in staging, breaks in prod” bugs.


Deployment Strategies#

StrategyHow It WorksRiskRollback
Big BangReplace everything at onceHighRedeploy old version
RollingReplace instances graduallyMediumStop rollout
Blue/GreenTwo identical environments, switch trafficLowSwitch back
CanaryRoute small % of traffic to new versionLowRoute back to old

Key Takeaways#

  1. SDLC is cyclical — plan, build, test, deploy, operate, repeat
  2. Agile delivers value incrementally — small batches, fast feedback
  3. CI/CD automates the path to production — build, test, deploy on every commit
  4. Testing pyramid — many unit tests, fewer integration, minimal E2E
  5. Environments should match production — minimize “works on my machine”
  6. Blue/green and canary reduce deployment risk
  7. The methodology matters less than the principles — fast feedback, small batches, automation