Skip to main content

Deployment

Deployment Process Documentation

Overview

This document outlines the automated deployment process for the Smart360 platform services using Jenkins CI/CD pipeline. The deployment process follows a containerized microservices architecture pattern with automated builds, testing, and deployment to Google Kubernetes Engine (GKE).

PIPELINES : https://github.com/BynryGit/bifrost/pipeline

Deployment Architecture

Pipeline Structure

The deployment pipeline follows a multi-stage approach:

  1. Source Code Management - Git checkout and branch management
  2. Container Image Building - Docker image creation and registry push
  3. Infrastructure Preparation - SSL certificate and namespace management
  4. Service Dependencies - Redis cache deployment
  5. Application Deployment - Multi-container service deployment
  6. Notification System - Slack integration for build status

image.png

Workloads

Each service deployment includes three containerized components:

  • Web Service: Main application server (Django REST API)
  • Celery Worker: Asynchronous task processing
  • Celery Beat: Scheduled task management

Along side there is also a redis container for particular serivce.

Deployment Configuration

Environment Management

The pipeline supports environment-specific deployments with the following configuration:

Environment Variables

  • ENVIRONMENT: Target deployment environment (dev/staging/prod)
  • ENVIRONMENT_URL: URL identifier for domain configuration
  • PROJECT_ID: Google Cloud Project identifier
  • SERVICE_NAME: Microservice identifier (auth, user, notification, etc.)
  • CLUSTER_NAME: Target GKE cluster name

Infrastructure Settings

  • Zone Configuration: us-central1 (registry) and us-west1-a (GKE)
  • Container Registry: Google Artifact Registry with environment-specific repositories
  • Namespace Strategy: Service-specific Kubernetes namespaces ({service}360-namespace)

Security Measures

Credential Management

  • GitHub Access: Secured with Jenkins credential store
  • GCP Authentication: Service account key-based authentication
  • Container Registry: Authenticated push/pull operations
  • Kubernetes Access: Cluster credentials managed through gcloud

Access Controls

  • Namespace Isolation: Service-specific Kubernetes namespaces
  • Service Account: Dedicated GCP service accounts for deployment operations
  • Network Security: GKE cluster-level network policies

Deployment Process Flow

Stages

Stage 1: Source Code Checkout

Purpose: Retrieve the latest code from version control

Process:

  • Checks for existing workspace and performs incremental updates
  • Supports branch-based deployments with parameter configuration
  • Configures Git credentials for authenticated access
  • Handles both initial checkout and subsequent updates

Safety Measures:

  • Credential encryption and secure handling
  • Branch validation and checkout verification
  • Workspace consistency checks

Stage 2: Container Image Building

Purpose: Create deployable container images for all service components

Process:

  • Builds three distinct container images (web, celery, celery-beat)
  • Uses build numbers for image versioning and traceability
  • Pushes images to Google Artifact Registry
  • Includes application credentials and configuration files


Stage 3: SSL Certificate Management

Purpose: Ensure secure HTTPS communication

Process:

  • Creates or validates Google-managed SSL certificates
  • Configures domain-specific certificates (api-{service}-{env}.bynry.com)
  • Establishes Kubernetes namespace if not present
  • Links certificates to ingress configurations


Stage 4: Redis Deployment

Purpose: Deploy caching layer for application performance

Process:

  • Deploys Redis as a shared caching service
  • Checks for existing deployments to prevent conflicts
  • Applies both deployment and service configurations
  • Ensures cache availability before application deployment


Stage 5: Application Service Deployment

Purpose: Deploy main application components with high availability

Process:

  • Deploys web, celery, and celery-beat services simultaneously
  • Creates ConfigMaps for environment-specific configuration
  • Implements rolling update strategy for zero-downtime deployments
  • Configures ingress rules for external access

High Availability Measures:

  • Rolling Updates: Zero-downtime deployment strategy
  • Health Checks: Readiness probes for web services
  • Service Discovery: Internal DNS for service communication
  • Load Balancing: NodePort services with ingress configuration

Configuration Management:

  • Environment-specific ConfigMaps from external configuration files
  • Separation of secrets and configuration data
  • Dynamic configuration updates without image rebuilds

Ingress and Load Balancing

Components:

  • Ingress Controller: Google Cloud Load Balancer integration
  • Static IP: Reserved IP addresses for consistent access
  • Health Checks: Custom health endpoints for service validation
  • Path Routing: Intelligent request routing based on paths

Performance Optimization:

  • Health check intervals optimized for responsiveness
  • Custom health endpoints for accurate service status
  • Geographic load distribution through GCP infrastructure

Configuration Management Strategy

Environment Separation

  • Configuration Files: Environment-specific variable files
  • Namespace Isolation: Kubernetes namespaces for environment separation
  • Resource Naming: Environment prefixes for resource identification
  • Domain Mapping: Environment-specific domain configurations

ConfigMap Management

  • Dynamic Updates: Configuration changes without image rebuilds
  • Version Control: Configuration file versioning alongside code
  • Validation: Configuration validation before deployment
  • Rollback Support: Previous configuration preservation

Operational Procedures

Standard Deployment

  1. Trigger: Manual or automated trigger based on code changes
  2. Branch Selection: Developer specifies target branch for deployment
  3. Automated Process: Pipeline executes all stages automatically
  4. Notification: Team receives status updates via Slack

Emergency Procedures

  • Rollback Process: Quick rollback using Kubernetes rollout history
  • Emergency Stops: Pipeline can be stopped mid-deployment if issues arise
  • Manual Override: Direct kubectl access for emergency interventions

Maintenance Windows

  • Scheduled Updates: Planned maintenance with advance notification
  • Zero-Downtime: Rolling updates minimize service interruption
  • Resource Planning: Capacity planning for deployment resources
  • Performance Monitoring: Post-deployment performance validation



Back to top