Production in CI/CD — what it is, stages and environment in development

What is Production in CI/CD

Production in the context of CI/CD is the final stage of the application lifecycle, where code after passing all build and testing stages becomes available to end users. Unlike development and staging environments, the production environment works with real data and loads, which imposes special requirements on reliability and performance.

Role of the Production Environment

The production environment is not just a server, but a whole infrastructure including load balancers, databases, caching layers, CDN and monitoring systems. Each component must be fault-tolerant and scalable. In mobile development, production also includes backend services, API gateways and push infrastructure that support the client application.

Production Environment Requirements

The production environment must meet strict criteria: availability 99.9% and above, API response time no more than 200 ms, disaster recovery support (RTO and RPO within SLA). For mobile applications, crash reporting, usage analytics and A/B platforms for experiments are additionally required. The CI/CD pipeline ensures compliance with these requirements through automated checks before each deployment.

Production Deployment Stages

Deployment to production is a multi-stage process automated through the CI/CD pipeline. Each stage includes checks that prevent defective code from reaching production. Let us review the key stages using a typical mobile application pipeline as an example.

CI/CD Pipeline for Production

The pipeline starts with a commit to the main repository branch. After the push, automatic build and unit tests are launched, followed by integration tests and code quality checks. Upon successful completion of all stages, the artifact is published to the build registry and deployed to staging for final verification. Only after confirmation on staging does the pipeline proceed to production deployment.

@Library("shared-lib") _

pipeline {
    agent any

    stages {
        stage("Build") {
            steps {
                sh "cd app && ./gradlew assembleRelease"
            }
        }
        stage("Test") {
            steps {
                sh "cd app && ./gradlew testRelease"
            }
        }
        stage("Deploy to Staging") {
            steps {
                sh "deploy-staging.sh"
            }
        }
        stage("Deploy to Production") {
            input "Deploy to production?"
            steps {
                sh "deploy-production.sh"
            }
        }
    }
}

Deployment Automation

Automated deployment to production uses zero-downtime deployment strategies: rolling update, blue-green deployment or canary release. With rolling update, new application instances gradually replace old ones without stopping the service. Blue-green deployment maintains two identical environments and switches traffic instantly, allowing quick rollback if problems occur. The choice of strategy depends on the criticality of the service and acceptable downtime. For mobile applications, deployment to production includes publishing in app stores (App Store Connect, Google Play Console) with phased rollout, which requires additional CI/CD integration with store APIs to automate the publication process, including uploading binaries, filling metadata and submitting for review.

Post-Deployment Checks

After successful deployment to production, the CI/CD pipeline launches a set of smoke tests that verify basic service functionality: endpoint availability, API response correctness, response time within normal limits. For mobile applications, authorization capability, data synchronization and correct operation of payment integrations are additionally checked. If smoke tests fail, the pipeline automatically initiates a rollback to the previous stable version and sends a notification to the team. Post-deployment monitoring continues for 30-60 minutes with an increased alert level — this is the window for detecting problems not covered by automated tests.

Differences Between Production and Test Environments

The key difference between production and less strict environments is working with real user data and loads. The staging environment is designed for final pre-release testing but uses synthetic or anonymized data. Production, on the other hand, processes live transactions, personal data and critically important operations, which requires a fundamentally different approach to management.

Configuration and Infrastructure

Production environment configuration must be strictly isolated from other environments. This applies to environment variables, database connection strings, API keys and certificates. Production infrastructure is usually duplicated across multiple availability zones to ensure fault tolerance. For mobile applications, production also includes Apple App Store and Google Play configurations that are absent in test builds.

Data Management

In production, using real data for testing is strictly prohibited — staging and development environments exist for that purpose. All database structure changes must go through migrations that are automatically applied by the CI/CD pipeline. Production data backup is performed on a schedule with automatic integrity verification. Retention policy determines the storage period of backups in accordance with GDPR requirements and other regulations.

Production Infrastructure Monitoring

Production monitoring is a continuous process of collecting and analyzing metrics, logs and traces. Without comprehensive monitoring, it is impossible to guarantee SLA and detect incidents in a timely manner. The modern approach to monitoring is based on three pillars: metrics (numerical indicators), logs (structured event records) and traces (request tracing).

Key Metrics

Key production environment metrics include: uptime (service availability), latency (response delay), error rate (percentage of errors), throughput (bandwidth) and saturation (resource load level). For mobile applications, startup time metrics, crash-free rate and data synchronization time are critical. Alerts are configured based on SLO (Service Level Objectives) so that the team receives notifications before SLA is violated.

Monitoring Tools

Specialized platforms are used for production infrastructure monitoring: Datadog, New Relic, Grafana + Prometheus for metrics collection, Sentry and Crashlytics for tracking errors in mobile applications. Logs are centralized through the ELK stack (Elasticsearch, Logstash, Kibana) or Splunk. Request tracing is implemented using Jaeger or Zipkin. All tools are integrated with the CI/CD pipeline for automatic dashboard creation when deploying a new service. The incident response system (PagerDuty, Opsgenie) receives alerts from all monitoring tools and automatically assigns an on-call responsible person based on rotation and escalation rules. A runbook for each incident type is stored in the repository and versioned together with the code, ensuring the relevance of recovery instructions.

Production Environment Security

Production environment security is a multi-layered protection system covering infrastructure, data, access and the deployment process. Each layer must be configured so that compromise of one does not lead to compromise of the entire system. The CI/CD pipeline plays a key role in ensuring security through automated checks, vulnerability scanning and compliance control at each pipeline stage.

Access and Roles

Access to the production environment is strictly limited by the principle of least privilege. Developers do not have direct access to production servers — all changes go through the CI/CD pipeline with an approval mechanism. For emergency access, temporary credentials with automatic rotation and full action logging are used. The four eyes principle (any operation requires approval from two people) is the standard for production operations.

Change Audit

Every change in production is recorded in the audit system: who initiated the deployment, which commit was deployed, what checks were passed, how long the deployment took. Integration of CI/CD with incident management systems (PagerDuty, Opsgenie) allows automatic ticket creation when deployment fails or SLO is violated. All production logs are stored in an immutable repository with a retention of at least 90 days in accordance with SOC2 and ISO 27001 requirements.