More in DevOps & Cloud — page 55

Configuration as Code: Treat Your Settings Like Source Code
Configuration as Code (CasC) treats your settings like source code, storing them in version control. This ensures every environment is identical, with changes automatically tested and deployed via CI/CD.
The Twelve-Factor App: Store Config in the Environment
Your app's code is the blueprint; its config is the specific address and utility hookups. Store config—database URLs, API keys—in environment variables, not in the code. The footgun is hardcoding secrets, making your code base impossible to open-source safely.
Configuration Files: Separating Code from Settings
A config file separates a program's behavior from its code, allowing you to change settings like database URLs without recompiling. They're used for API keys, feature flags, and environment-specific values. The footgun is committing secrets to version control.
Environment Variables: Configuration Outside Code
Environment variables are settings passed to your app from the outside world, letting you change behavior without touching code. Use them for API keys or database URLs. The biggest footgun is committing secrets to version control instead of using variables.
Cloud-Init: Bootstrapping Cloud Instances
Cloud-init is the script that runs on a generic VM's first boot to turn it into *your* server. It's used by cloud providers to apply your `user-data` (like SSH keys and startup scripts) at launch. The biggest footgun: it only runs once on first boot.
Open Policy Agent (OPA): Centralized Policy as Code
OPA decouples policy decisions from your app's code. Instead of scattering `if` statements, you query a central engine: 'Is this allowed?' It enforces rules in Kubernetes, CI/CD, and API gateways. A common footgun is only using it for yes/no decisions.

Terragrunt: A Thin Wrapper for DRY Terraform
Terragrunt is a thin wrapper for Terraform/OpenTofu that automates common tasks. Just add an empty `terragrunt.hcl` file to get features like automatic `init`.

Pulumi: Infrastructure as Code with Real Programming Languages
Pulumi is Infrastructure as Code using real languages like Python or TypeScript, not a special DSL. This lets you use loops, functions, and classes to define resources. The main footgun is writing overly complex, clever code that becomes unmaintainable.

Ephemeral Environments: A Staging Server for Every PR
Ephemeral environments are disposable, production-like test servers created for every pull request. They let developers test changes in isolation without waiting for a shared staging server, catching integration bugs earlier.

Infrastructure Drift: When Reality and Code Diverge
Infrastructure drift is when live systems no longer match their configuration code. This happens when someone manually changes a cloud resource instead of updating the Terraform file. The footgun: your next `terraform apply` may destroy your manual changes.
Ansible: Automating Infrastructure with Playbooks
Ansible is like a recipe book for your servers. You write simple "playbooks" describing a desired state, and Ansible makes it happen over SSH without installing agents. It's ideal for configuration management, app deployment, and orchestrating workflows.

Packer: Build Identical Machine Images Everywhere
Packer is a universal recipe for baking machine images. It takes a single template and builds identical images for multiple platforms like AWS or Docker. Use it to create consistent "golden images" for your infrastructure.

Terraform State: The Map to Your Infrastructure
Terraform state is the source of truth mapping your code to real cloud resources. It's used on every `plan` and `apply` to determine changes. The footgun: never store state in Git or edit the `tfstate` file directly; this risks corruption and secret leaks.

Vagrant: Your Dev Environment as Code
Vagrant is a scriptable remote for virtual machines, defining a dev environment in one text file. It ensures teams have identical, isolated setups, solving "it works on my machine" problems.
AWS CloudFormation: Your AWS Infrastructure as a Blueprint
AWS CloudFormation is your infrastructure's blueprint. Declare AWS resources in a YAML/JSON file, and AWS builds it. This is perfect for creating repeatable, version-controlled environments.

Terraform: Manage Infrastructure as Code
Terraform lets you define cloud infrastructure—servers, databases, networks—in a text file, like a blueprint. It reads this file and builds everything for you, making setups on AWS, GCP, or Azure repeatable.
Policy as Code in CI/CD with OPA
Treat pipeline rules as code using Open Policy Agent (OPA) to automate guardrails. Instead of scripts, write declarative policies to check test coverage or validate dependency licenses.
Dynamic Pipelines: Parent-Child vs. Multi-Project
Break up monolithic CI/CD pipelines into smaller, independent ones. Use parent-child pipelines for dynamic jobs in one project (like a monorepo), or multi-project pipelines to coordinate across repos. The footgun: the parent pipeline doesn't wait by default.
Pipeline Templates: Reusable CI/CD Building Blocks
Think of pipeline templates as versioned, shareable functions for your CI/CD. Instead of copy-pasting YAML, you import a standardized block of logic for tasks like security scanning or deployment.

Self-Hosted Runners: Bring Your Own CI/CD Hardware
A self-hosted runner is your own machine executing CI/CD jobs, giving you full control over its environment and network. Use it for private network access or custom hardware. The footgun: you are now responsible for all security, updates, and maintenance.