Check: CI/CD

CI means developers frequently merge changes into a shared branch, and automation runs a build and tests on every change. The goal is for a break to surface minutes after the commit, not a week later. Deploying to production already belongs to CD.

In both approaches, the pipeline prepares a verified artifact that can be rolled out at any moment. The difference is in the last step. In Continuous Delivery, a human starts the release to production, usually with one button. In Continuous Deployment, a green pipeline deploys to production by itself, with no manual step. Kubernetes has nothing to do with it: both approaches work with any deploy target.

The longer a branch lives on its own, the further it drifts from main: colleagues have time to change the same files in the meantime. Small frequent merges (trunk-based development) are easier to review, they almost never conflict, and if something breaks, the guilty commit is small and easy to find.

A runner (in GitLab it's the GitLab Runner, in Jenkins an agent) picks up a job, runs its commands, and reports the result. Most often a job runs in a clean container from a specified image, so every run starts from scratch. The configuration file (.gitlab-ci.yml) only describes what to do.

Secrets live in CI's variable storage: in GitLab that's Settings > CI/CD > Variables, in GitHub Actions it's the Secrets section. Masked means the value gets replaced by a mask in job logs. Protected means the variable is only available to pipelines on protected branches and tags. Anything that made it into the repository is visible to everyone with access to the code, and stays in the commit history. That's why a token that was ever committed is treated as compromised and reissued.

An environment is a named deploy target: staging, production. GitLab remembers which version went out to each environment and when, and can repeat any past deploy, meaning roll back to it. The image, tests and passwords are described elsewhere in the job.

In GitOps, the cluster's desired state is described in git, and that's the only source of truth. An agent inside the cluster (the pull model) regularly reconciles the cluster against the repository and applies changes from git. It notices a manual kubectl edit as drift. Flux, by default, reverts such edits back to the state from git. Argo CD, by default, only marks the application as OutOfSync, and only starts rolling back manual edits on its own if self-heal is turned on.