Skip to content

🍳 CI/CD Recipes and Best Practices

This document defines CI/CD recipes and best practices for building and deploying applications using Azure DevOps Pipelines, following Azure Cloud-Native standards.

It standardizes how applications are built, packaged, and deployed using Docker and Azure App Service, ensuring secure, repeatable, and maintainable releases.

📌 Golden Rule
If a CI/CD practice is not documented here, it is considered not standardized.

🎯 Objective

The objectives of these guidelines are to:

  • Standardize CI/CD practices across teams
  • Reduce deployment errors and configuration drift
  • Align new team members with approved delivery workflows
  • Promote cloud-native and container-based deployments
  • Improve operational reliability and security

☁️ CI/CD Architecture Overview

The standard deployment flow is based on:

  • Azure DevOps Pipelines (Build + Release)
  • Docker as the build and packaging mechanism
  • Azure App Service as the hosting platform
  • Azure DevOps Library for environment variables and secrets

High-level flow

Source Code
   ↓
Azure DevOps Pipeline (Build)
   ↓
Docker Image
   ↓
Azure DevOps Pipeline (Release)
   ↓
Azure App Service

🐳 Docker as the Deployment Artifact

  • Docker is the mandatory packaging format
  • Applications must be built into a Docker image
  • The Docker image is the single deployment artifact
  • Docker images must be immutable and versioned

Base Image Requirements

Docker base images must be:

  • Actively supported
  • Regularly updated
  • Free of known security vulnerabilities

📌 Rule
If a Docker base image, runtime, or framework is end-of-life (EOL) or out of security support, it must not be used.

🔐 Environment Variables & Configuration Management

Azure DevOps Library

  • All environment variables must be defined in Azure DevOps Library
  • Secrets must never be committed to source control
  • Pipelines inject variables during build or release stages
  • Different variable groups must be used per environment

Local Development Configuration

For local development and testing, environment variables must be handled as follows:

.env

  • Used only for local execution
  • Must never be committed to the repository

.env.sample

  • Documents all required environment variables
  • Must be committed to the repository
  • Must not contain real secrets
  • Must be kept up to date

📌 Rule
If a variable is required in any environment, it must be declared in .env.sample.

🎥 Reference Video

The following video demonstrates a CI/CD implementation using Azure DevOps Release Pipelines, Docker, and Azure App Service:

▶️ https://youtu.be/POuA3bIKCpI

The video covers:

  • Docker image creation
  • Azure DevOps build pipeline configuration
  • Release pipeline to Azure App Service
  • Environment variable management using Azure DevOps Library

📌 The video complements this document but does not replace it.

✅ Key Rules (Summary)

  • Use Docker as the standard build and deployment artifact
  • Do not duplicate logic across services or pipelines
  • Externalize all configuration using environment variables
  • Never store secrets in source code or Docker images
  • Keep Docker images and runtimes up to date
  • Prefer clarity and simplicity over unnecessary complexity
  • Design pipelines with maintainability in mind

📌 Compliance Rule

All projects must:

  • Use Azure DevOps pipelines for CI/CD
  • Deploy containerized applications
  • Use Azure DevOps Library for configuration and secrets
  • Provide a .env.sample file for environment documentation
  • Follow these guidelines unless a formal exception is approved via an Architecture Decision Record (ADR)