All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
4247 bites
Page 105
Pipeline as Code: Versioning Your Build Process
Treat your CI/CD pipeline not as clicks in a UI, but as a version-controlled file (Jenkinsfile) living with your code. This enables automated, reviewable build processes for every branch. The footgun is defining pipelines in the UI, creating a black box.
Immutable Infrastructure: Treat Servers Like Cattle, Not Pets
Immutable infrastructure means you never modify running servers. To deploy, you replace them with new ones built from a golden image. This is key for CI/CD and autoscaling, ensuring consistency. The footgun is configuration drift from manual, one-off fixes.
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.
Idempotency: Safe to Retry Automation
Idempotent automation ensures an operation has the same effect whether run once or many times. This is vital for safely retrying failed CI/CD jobs or configuration scripts. The footgun: thinking it means 'no side effects'.
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.
Git Commit: A Snapshot, Not a Diff
A Git commit is a permanent snapshot of your entire project, not just the changes. It's a save point containing the full state of all files, linked to the previous commit to form a historical chain.
.gitignore: Telling Git What to Ignore
A .gitignore file is a deny-list for your repository, telling Git which files and directories to intentionally leave untracked. Use it to keep build artifacts, log files, and local configs out of your commit history.
Git Branch: A Lightweight Pointer, Not a Full Copy
A Git branch is a lightweight pointer to a commit, not a heavy copy of your code. This makes creating and switching branches nearly instant. Use them to isolate new features or bug fixes. The footgun is forgetting a branch is local until you push.
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.
Git Merge: Combining Development Histories
Git merge combines separate lines of development into one branch. It creates a special merge commit that ties the two histories together, preserving the context of each. Use it to integrate a feature branch into your main line.
Git Rebase: Rewriting History for a Cleaner Timeline
Git rebase rewrites history by transplanting your commits onto a new base, creating a clean, linear project history instead of a merge bubble. It's used to catch a feature branch up with main. Never rebase a branch others are using; it rewrites history.
Git Tags: Immutable Milestones for Release History
A Git tag is a permanent bookmark on a commit, usually marking releases like v2.0. Annotated tags store author, date, and GPG signatures to anchor deploy pipelines.
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.
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…
Git Cherry-Pick: Copy a Commit to Another Branch
Think of git cherry-pick as copying a single commit's changes from one branch and reapplying them as a new commit on another. It's for backporting a bug fix without merging an entire feature branch.
Monorepo vs. Polyrepo: One Repository or Many?
A monorepo is one repository for all projects, like a city; a polyrepo is one per project, like separate towns. Monorepos simplify code sharing and atomic refactors but require complex tooling. Polyrepos offer autonomy but can create dependency hell.
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.
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.
Make: The Original Task Runner
Make automates tasks by following a recipe in a makefile. It intelligently runs only the necessary steps by checking dependencies, saving time during builds. While common for compiling code, it can run any shell command.
Build Dependency Management: Your Project's Recipe
Dependency management is your project's recipe, ensuring everyone uses the same library versions. It's used everywhere from web apps pulling React via npm to Java services using Maven.