Skip to content

Deployment

Overview

The Gustaffo Reservations Application uses a containerized deployment approach with Kubernetes for orchestration. This document outlines the deployment architecture, environments, and processes.

Deployment Architecture

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
flowchart TB
    subgraph "CI/CD Pipeline"
        Git[Git Repository] --> Build[Build & Test]
        Build --> Artifact[Artifact Repository]
        Artifact --> Deploy[Deployment Process]
    end

    subgraph "Kubernetes Cluster"
        subgraph "Infrastructure"
            Ingress[Ingress Controller]
            LB[Load Balancer]
            Secrets[Secret Management]
            Config[ConfigMaps]
        end

        subgraph "Application Pods"
            API[API Services]
            Workers[Background Workers]
            Scheduled[Scheduled Jobs]
        end

        subgraph "Data Services"
            DB[Database]
            Cache[Redis Cache]
            Queue[Message Queue]
        end
    end

    Deploy --> Kubernetes[Kubernetes API]
    Kubernetes --> Infrastructure
    Kubernetes --> Application
    Kubernetes --> Data

    Ingress --> API
    LB --> API
    Secrets --> API
    Secrets --> Workers
    Secrets --> Scheduled
    Config --> API
    Config --> Workers
    Config --> Scheduled

    API --> DB
    API --> Cache
    API --> Queue
    Workers --> DB
    Workers --> Cache
    Workers --> Queue
    Scheduled --> DB

Environments

Development

  • Purpose: Feature development and initial testing
  • Deployment Frequency: On every commit to feature branches
  • Data: Anonymized subset of production data
  • Access: Development team only
  • Infrastructure: Shared Kubernetes cluster with namespace isolation

Testing

  • Purpose: QA testing, integration testing, and user acceptance testing
  • Deployment Frequency: After feature completion and PR approval
  • Data: Test data with production-like volume and variety
  • Access: Development and QA teams
  • Infrastructure: Dedicated Kubernetes cluster with production-like configuration

Staging

  • Purpose: Pre-production validation and performance testing
  • Deployment Frequency: Before production releases
  • Data: Full production-like dataset (anonymized where necessary)
  • Access: Development, QA, and operations teams
  • Infrastructure: Production-equivalent configuration

Production

  • Purpose: Live system serving end users
  • Deployment Frequency: Scheduled releases after staging validation
  • Data: Live production data
  • Access: Limited to operations team with role-based access
  • Infrastructure: Highly available, multi-region Kubernetes clusters

Deployment Process

CI/CD Pipeline

  1. Code Commit: Developer commits code to feature branch
  2. Automated Testing: Unit tests, integration tests, and static analysis run
  3. Build: Container images built and tagged with commit hash
  4. Artifact Storage: Images pushed to container registry
  5. Deployment Approval: Manual approval for production deployments
  6. Deployment: Kubernetes manifests applied to target environment
  7. Smoke Tests: Basic functionality tests run post-deployment
  8. Monitoring: Deployment metrics monitored for anomalies

Deployment Tools

  • Git: Source code management
  • Jenkins: CI/CD pipeline orchestration
  • Docker: Container runtime
  • Kubernetes: Container orchestration
  • Helm: Kubernetes package management
  • ArgoCD: GitOps continuous delivery
  • Prometheus & Grafana: Monitoring and alerting

Configuration Management

Environment-Specific Configuration

Configuration is managed using Kubernetes ConfigMaps and Secrets:

  • ConfigMaps: Non-sensitive configuration parameters
  • Secrets: Sensitive information like credentials and API keys
  • Sealed Secrets: Encrypted secrets stored in Git

Feature Flags

Feature flags are used to control feature availability in different environments:

  • Implemented using a feature flag service
  • Allows for gradual rollout of features
  • Supports A/B testing and canary releases

Release Management

Release Strategy

  • Release Schedule: Bi-weekly releases to production
  • Hotfixes: Emergency fixes for critical issues
  • Versioning: Semantic versioning (MAJOR.MINOR.PATCH)
  • Release Notes: Generated from JIRA tickets and pull requests

Deployment Strategies

  • Blue/Green Deployment: Parallel environments for zero-downtime updates
  • Canary Releases: Gradual rollout to a subset of users
  • Feature Flags: Toggle features without deployment

Rollback Procedures

In case of deployment issues, the following rollback procedures are in place:

  1. Automated Rollback: Triggered by failing health checks
  2. Manual Rollback: Initiated by operations team
  3. Version Rollback: Redeploying previous stable version
  4. Feature Flag Disable: Disabling problematic features

Database Migrations

  • Migration Scripts: Versioned SQL scripts using Flyway
  • Forward-Only: Migrations are designed to be forward-only
  • Testing: Migrations tested in lower environments before production
  • Backup: Database backed up before migrations

Infrastructure as Code

All infrastructure is defined as code using:

  • Terraform: For cloud infrastructure provisioning
  • Kubernetes Manifests: For application deployment
  • Helm Charts: For reusable application components
  • Ansible: For configuration management

Monitoring and Observability

Deployment monitoring includes:

  • Health Checks: Regular probing of service endpoints
  • Metrics: Application and infrastructure metrics collection
  • Logs: Centralized logging with structured log format
  • Tracing: Distributed tracing for request flows
  • Alerts: Automated alerting for deployment issues

Security Considerations

  • Vulnerability Scanning: Container images scanned before deployment
  • Secret Management: Secure handling of credentials and certificates
  • Network Policies: Restricted network communication between services
  • Pod Security Policies: Enforced security context for containers

Disaster Recovery

  • Regular Backups: Automated backups of all critical data
  • Multi-Region Deployment: Production deployed across multiple regions
  • Failover Procedures: Documented procedures for regional failover
  • Recovery Time Objective (RTO): 1 hour
  • Recovery Point Objective (RPO): 15 minutes
Back to top