CI/CD & GitOps

uses: runs a packaged action instead of a shell command. It points at a public repository plus a ref (actions/checkout@v4), a path inside your own repository (./.github/actions/setup), or a Docker image (docker://alpine:3.19).

A step either invokes packaged code with uses:, which points at an action by repository, local path, or Docker image and takes inputs via with:, or executes shell commands with run:. One step cannot have both keys.

runs-on picks the machine a GitHub Actions job executes on, by label. ubuntu-latest requests a GitHub-hosted Linux virtual machine that is created fresh for that one job and destroyed when the job finishes.

Reference it through the secrets context, as ${{ secrets.NAME }}, and map it into an env variable or an action input instead of splicing it into a shell command. GitHub masks the value in logs, but masking is redaction, not access control.

They are independent allow-lists over the pushed ref. A branches filter alone means tag pushes never trigger the workflow, and a tags filter alone means branch pushes never do; declaring both matches either. Patterns are globs, not regexes.

The environment: keyword marks a GitLab CI job as a deployment, so GitLab records what is deployed where. The name identifies the tracked environment; the url is the address GitLab links to from that environment, the job, and the merge request.

GitLab CI's include merges other YAML configuration into your pipeline when the pipeline is created. local reads a file from the same repository and commit, project a file from another project on the same instance, remote a publicly reachable URL, and template a file GitLab ships with the instance.

Declare the file under artifacts:paths in the producing job; GitLab uploads it and later-stage jobs download artifacts from all earlier-stage jobs automatically. Narrow that with dependencies: (an empty list downloads nothing) or with needs:.

A GitLab CI job runs only on a runner that carries every tag listed in its tags: keyword. If no online, permitted runner has all of them, the job stays pending until such a runner appears or GitLab drops it as stuck.

Put a CI/CD variable in the environment name so each branch creates its own environment — typically name: review/$CI_COMMIT_REF_SLUG with a matching url. GitLab expands the variable per pipeline, so every merge request gets a separately tracked deployment and a View app link.

agent any lets Jenkins run the whole pipeline on any available executor, allocating one workspace for the entire run. agent none allocates no executor at pipeline level, so every stage must declare its own agent block.

withCredentials fetches a stored credential by its ID and exposes it as an environment variable only inside its block, masking the value in the console log. Inside sh, reference it with single quotes so Groovy never interpolates the secret.

A declarative Jenkinsfile is one pipeline block that must contain an agent directive and a stages block. Inside stages, every stage needs a name and a steps block, and the actual commands live in steps. Everything else is optional.

A Jenkins plugin is a packaged extension (.hpi/.jpi) supplying almost everything Jenkins does beyond scheduling builds. The Plugin Manager downloads it plus its declared dependencies into JENKINS_HOME/plugins and loads it, in many cases only after a restart.

It loads the Jenkins shared library registered as utils at version v1.4 — a branch, tag or commit in the library's repository — so the library's steps become callable in that Jenkinsfile. The underscore is a throwaway statement the annotation must attach to.

An orb is a versioned, shareable package of CircleCI configuration published to a registry and pulled in under the orbs: key. One orb can supply three element types: commands, jobs, and executors.

The docker executor runs steps inside a container that has no Docker daemon of its own. Add the setup_remote_docker step to attach an isolated remote Docker environment, or switch the job to the machine executor, a VM with a local daemon.

Every CircleCI job starts on a clean executor, so nothing carries over implicitly. Workspaces move files between jobs in one workflow run and are the right tool here; caches speed up refetching dependencies; artifacts are outputs stored for people to download.

The full pin @5.0.2 always resolves to one immutable published version. @5 resolves to the newest release in that major line each time the config compiles, and @volatile takes the most recent publish. Only the full pin is reproducible.

A snapshot dependency orders the builds and pins them to one source revision, forming the chain. An artifact dependency copies files produced by the upstream build into the downstream one. They are independent settings, and most real chains declare both between the same pair.

TeamCity's Kotlin DSL describes projects and build configurations as compiled Kotlin code in .teamcity/settings.kts. Enabling Versioned Settings on a project makes the server fetch that file from VCS, compile it, and apply the result as the project's live settings.

Open the build configuration's agents view, which lists compatible and incompatible agents with the exact unmet requirement for each. Fix the mismatch, or check the pool: agents in a pool not associated with the project can never run its builds however well they match.

A typed DSL catches configuration mistakes at compile time, offers IDE completion and safe refactoring, and lets one function generate many near-identical pipelines. It costs a compile step, coupling to the server's API version, and a configuration only JVM engineers can comfortably read and review.

An Azure Artifacts feed is a private package registry hosted inside an Azure DevOps organization or project. One feed can hold NuGet, npm, Maven, Python and Universal Packages together, each reached through its own protocol endpoint URL.

Stages contain jobs and jobs contain steps. The job is the unit of agent allocation: one agent runs all of a job's steps in one workspace, so two separate jobs share no filesystem.

A pipeline authenticates as its build service identity, and an authentication task injects that identity's token into the package client's config. A 401 usually means the build service identity holds no role on the feed, or the job's authorization scope cannot reach a feed in another project.

A deployment job targets a named environment, so Azure Pipelines records deployment history against it, enforces that environment's approvals and checks before the stage runs, and lets you choose a runOnce, rolling or canary strategy.

Three different times. ${{ }} is a template expression evaluated at compile time before the run is scheduled, $[ ] is a runtime expression evaluated when the stage or job starts, and $( ) is macro syntax substituted just before each task executes.

An Argo CD Application is a Kubernetes custom resource that pairs one desired-state source with one cluster destination. spec.source gives the Git repoURL, the path inside it, and the targetRevision to read; spec.destination gives the cluster and namespace to deploy into.

Argo CD tracks two independent axes. Sync status compares live cluster objects with the manifests at the target Git revision (Synced, OutOfSync). Health status judges whether those objects actually work (Healthy, Progressing, Degraded, Suspended, Missing, Unknown).

An Argo CD AppProject is a tenancy boundary. It lists which Git repositories its Applications may deploy from, which destination clusters and namespaces they may deploy to, and which resource kinds they may create. The built-in default project allows all of those.

prune lets automated sync delete live resources that were removed from Git; selfHeal lets it re-apply Git over changes made directly in the cluster. With both off, automated sync only applies new Git revisions and reports everything else as OutOfSync without touching it.

Argo CD resource hooks are ordinary Kubernetes manifests annotated with argocd.argoproj.io/hook so they run at a chosen point of a sync: PreSync, Sync, PostSync or SyncFail. A schema migration is a Job annotated PreSync, so the sync stops if it fails.

Flux splits image automation across three objects: ImageRepository scans a container registry and lists its tags, ImagePolicy selects the newest tag matching a rule, and ImageUpdateAutomation writes that tag back into the Git manifests Flux deploys from.

Flux splits fetching from applying. source-controller pulls a repository (GitRepository, OCIRepository, HelmRepository) and publishes a verified artifact; kustomize-controller takes that artifact, builds the manifests and applies them to the cluster on its own interval.

You mark the target lines yourself. Flux's Setters strategy only rewrites a YAML value carrying an inline comment that names an ImagePolicy, such as # {"$imagepolicy": "flux-system:app"}. Unmarked files under the update path are left untouched.

Work outward from the source. Check the GitRepository's Ready condition and the revision it fetched, then the Kustomization's condition, revision and suspend state. A failed fetch, a stale artifact, a build error, an unmet dependency or a long interval each stop delivery at a different, visible point.

interval sets how often kustomize-controller rebuilds and re-applies the manifests even when Git has not changed, which is what corrects drift. prune: true lets Flux delete cluster objects it previously applied once they disappear from the source.

In Octopus Deploy a release is an immutable, versioned snapshot of a project's deployment process, variables and chosen package versions. A deployment executes that release into one environment; promoting means deploying the same release to the next environment.

An Octopus Deploy lifecycle defines the ordered phases of environments a release must travel through. Each phase lists environments and how many must deploy successfully before the next phase unlocks, so Production stays unreachable until earlier phases pass.

Octopus Deploy snapshots a project's variables when the release is created, so later edits do not reach existing releases. Either use Update Variables on that release to refresh its variable snapshot, or create a new release.

An Octopus Deploy runbook is a separate operational process that runs against an environment's targets without creating a release or shipping an artifact. Use one for routine operations — restarts, cert rotation, restores — that must not wait for a deployment.

Kamal boots the new container alongside the old one, waits for its healthcheck endpoint to pass, and only then tells its proxy to switch traffic over, draining in-flight requests from the old container before stopping it. A container that never reports healthy never receives traffic.

kamal rollback takes a previous version tag, brings that container back up on each host, and switches the proxy to it — no rebuild, no registry round trip, so it is fast. It restores only the app container: not the database, not accessories, and not host state.

Kamal fits when your capacity is known, your service count is small, and nobody is paid to run a control plane: you get zero-downtime container deploys over SSH for one config file. You give up scheduling, autoscaling, rescheduling on host failure, and continuous reconciliation of drift.

Kamal needs only an SSH login that can run Docker on the host — no agent and no control plane. It builds your image, pushes it to a container registry, then drives docker commands over SSH so each server pulls and runs it.

GitHub Pages publishes either from a branch — it serves a chosen branch and folder, running Jekyll over it first — or from GitHub Actions, where a workflow uploads a built directory as a Pages artifact and a deploy step publishes that artifact.

A branch publishing source is run through GitHub's built-in Jekyll processor, which skips files and folders whose names begin with an underscore, so they never reach the served site. Committing an empty .nojekyll file at the publishing source's root disables that processing.

GitHub Pages serves static files and runs no code at request time: no API endpoints, no server-side rendering, no database, no server-held secrets, no configurable response headers or redirects, and no access control on the published site. That fits docs and marketing sites, not applications.

Point the apex at GitHub's documented Pages A and AAAA addresses (or an ALIAS record to <owner>.github.io), set the domain in the repository's Pages settings, wait for GitHub to provision a Let's Encrypt certificate, then enable Enforce HTTPS. Verify the domain to block takeover.

Build once, deploy many means the pipeline produces a single versioned artifact and moves that exact artifact through every environment. Rebuilding per environment means production runs bits nobody tested, so the staging result no longer proves anything.

A path filter compares the files a change touched against glob patterns and runs a job only when one matches. It sees file paths only, so it misses packages affected indirectly through dependency edges or shared root files.

A stage is a unit of ordering — a named phase that acts as a barrier before the next one starts. A job is a unit of allocation — one machine and one workspace, and the thing that runs in parallel. A step is a unit of execution — one command inside a job.

Semantic Versioning encodes compatibility: bump MAJOR for a backward-incompatible change to the public API, MINOR for backward-compatible new functionality, PATCH for a backward-compatible bug fix. The public contract decides the bump, not how much code changed.

A provider-hosted runner is a fresh machine the CI vendor creates per job, bills per minute, then destroys. A self-hosted runner is a machine you own and register yourself: usually cheaper at volume and able to reach private networks, but you inherit patching, isolation and cleanup.

Push delivery means the CI job holds a kubeconfig and runs kubectl or helm against the cluster. Pull delivery means an agent inside the cluster reads manifests from Git and applies them itself, so no outside system holds cluster credentials.

Promotion is a Git commit, not a deploy job. You change the production manifests to reference the exact image the staging environment already runs, merge that pull request, and the cluster agent converges production onto it.

App-of-apps is a root GitOps definition whose content is more GitOps definitions: the controller reconciles the root, the root creates the children, and the children deploy the workloads. Adding a component becomes one commit.

That pipeline satisfies two of the four GitOps properties: the desired state is declarative and versioned in Git. It misses the other two, since nothing pulls that state automatically and nothing reconciles continuously, so drift between merges is never seen or corrected.

Under push, the runner holds cluster credentials for every environment, so the attacker gets immediate admin-level access to all of them. Pull removes that credential, but not a poisoned image or a malicious commit, which the in-cluster agent will apply faithfully.