From idea to production — understand every phase of the SDLC and how modern teams ship software reliably at scale.
The SDLC is a structured process that guides teams from initial concept through deployment and maintenance. Each phase has specific goals, deliverables, and quality gates.
Good requirements prevent expensive rework. The cost of fixing a bug found in production is 100× more than catching it in the requirements phase.
# User Story Template As a [type of user], I want to [perform some action], So that [I can achieve some goal]. # Acceptance Criteria (Given-When-Then) Given I am a logged-in user When I click "Add Expense" Then a modal opens with amount, category, and note fields And the form validates required fields before saving And success shows a toast notification # Example: Real Story Title: Monthly Budget Limit Warning Story Points: 3 Priority: High (P1) As a budget-conscious user, I want to receive a notification when I reach 80% of my monthly budget, So that I can adjust my spending before exceeding my limit.
| Category | Meaning | Example |
|---|---|---|
| Must Have | Critical for launch — without it, product fails | User login, core CRUD operations |
| Should Have | Important but not critical — ship in v1.1 | Email notifications, search filters |
| Could Have | Nice to have — include if time allows | Dark mode, export to PDF |
| Won't Have | Explicitly out of scope for this release | AI recommendations, multi-language |
The testing pyramid defines how to structure your test suite for maximum coverage with minimum maintenance overhead.
// Unit Test — fast, isolated, no external dependencies describe('calculateMonthlyBudget', () => { it('returns correct total for valid expenses', () => { const expenses = [ { amount: 50, category: 'food' }, { amount: 30, category: 'transport' } ]; expect(calculateMonthlyBudget(expenses)).toBe(80); }); it('throws error for negative amounts', () => { expect(() => calculateMonthlyBudget([{ amount: -10 }])) .toThrow('Amount must be positive'); }); }); // Integration Test — tests component interaction with real DB it('saves expense and updates user balance', async () => { const user = await createTestUser({ balance: 1000 }); await addExpense(user.id, { amount: 200, category: 'food' }); const updated = await getUser(user.id); expect(updated.balance).toBe(800); });
Continuous Integration and Continuous Delivery automate the path from commit to production, catching issues early and enabling reliable, frequent releases.
# .github/workflows/ci.yml name: CI/CD Pipeline on: push: branches: [main] pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - run: npm ci - run: npm run lint - run: npm test -- --coverage - run: npm run build deploy: needs: test if: github.ref == 'refs/heads/main' runs-on: ubuntu-latest steps: - name: Deploy to server run: | scp -r dist/ $SERVER_USER@$SERVER_IP:/var/www/app/ ssh $SERVER_USER@$SERVER_IP "docker compose up -d --build" env: SERVER_IP: ${{ secrets.SERVER_IP }} SERVER_USER: ${{ secrets.SERVER_USER }}
Code review is not just bug catching — it's knowledge sharing, mentoring, and ensuring architectural consistency.
| Aspect | What Reviewers Look For | Example Feedback |
|---|---|---|
| Correctness | Does the code do what it's supposed to? | "This function returns null for empty arrays — is that intentional?" |
| Security | SQL injection, XSS, auth bypasses | "User input is not sanitized before DB insert — use prepared statements" |
| Performance | N+1 queries, missing indexes, memory leaks | "This loop calls DB inside — fetch all records at once and filter in memory" |
| Readability | Variable names, function length, comments | "What does 'x2' mean here? Rename to 'discountMultiplier'" |
| Test coverage | Are edge cases tested? | "No test for when the list is empty — add a test" |
| Architecture | Does it follow existing patterns? | "This should use the Repository pattern like other data access code" |