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.
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.
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.
Pipeline Triggers: The 'If This, Then That' of CI/CD
Pipeline triggers are the "if this, then that" for automation. They kick off builds on a code push (CI), run tests for a pull request (PR), or execute jobs on a schedule. The footgun: many systems enable triggers on all branches by default, causing unwanted.
Software Bill of Materials (SBOM): An Ingredient List for Your Code
An SBOM is a nutrition label for your code, listing every library and dependency. It's crucial for security audits and managing supply chain risk, letting you instantly find systems affected by a new vulnerability.
Build Artifact: The Packaged Output of a CI Run
A build artifact is the packaged result of a CI run, like a compiled binary or a zipped web app. Pipelines use artifacts to pass this output between stages, from building to testing and deploying.
Git LFS: Versioning Large Files Without Bloating Your Repo
Git LFS replaces large files with text pointers in your repo, storing the actual data on a remote server. This keeps clones fast when versioning videos, datasets, or graphics. Footgun: `git lfs track` only affects new files, not existing ones.
GitFlow: A Branching Model for Versioned Releases
GitFlow organizes your repo around two main branches: `master` for production and `develop` for integration. It's designed for projects with distinct, numbered releases, like desktop apps, not for continuously delivered web apps where simpler models are…
GitHub Flow: A Simple, Branch-Based Workflow
GitHub Flow is a simple workflow where `main` is always stable and new work happens on a feature branch. It's used for continuous delivery, from code to documentation.
Pull Requests: A Structured Conversation About Code
A Pull Request (PR) is a structured conversation about a proposed code change. It's used in team projects to review new features and fixes, ensuring quality and sharing knowledge. The footgun is treating PRs as a rubber-stamp approval instead of a real review.
Distributed Version Control (DVCS): Everyone Gets a Copy
A DVCS gives every developer a full, independent copy of the repository, history and all. This is Git's model, making commits and branches instant because they're local. The footgun: your local copy isn't the team's truth until you push and pull to sync.
GitOps: Your Git Repo is the Single Source of Truth
GitOps makes a Git repo the single source of truth for your infrastructure's desired state. An automated process makes production match what's declared in Git, enabling continuous deployment.
Blue-Green Deployment: Zero-Downtime Releases
Run two identical production environments, Blue (live) and Green (new). To deploy, just flip a switch routing traffic to Green. This enables zero-downtime releases and instant rollbacks. The footgun is using DNS for the switch, which can lag due to caching.