CI/CD setup and automated deployment with GitLab, Jenkins and ArgoCD

CI/CD Pipelines: a practical guide

Which GitLab Runner executor: shell, Docker or Kubernetes?

The executor decides where and how pipeline jobs run. The shell executor runs commands directly on the runner host. It is simple, but jobs can affect each other's files and tools, and tool versions clash between projects.

The Docker executor starts every job in a fresh container and suits most teams. If a job builds images, we avoid privileged Docker-in-Docker, which effectively gives the job root on the runner host, and use Buildah or rootless BuildKit instead. If you already run Kubernetes, the Kubernetes executor runs each job as a pod, so runner capacity grows and shrinks with the cluster.

GitLab CI/CD variables and the mistakes that leak secrets

A variable defined in project settings isn't automatically safe. Without the Masked option, a stray echo or a script run with set -x prints it into the job log for anyone with log access. Without Protected, any developer can push a branch with a job that reads the production SSH key.

Another frequent problem is one shared runner for every project, holding keys to the main servers. Keep sensitive projects on separate runners and deploy to production from a dedicated runner selected by tag. Artifacts without expire_in are a slower problem: the GitLab server's disk fills up a few months later.

What to decide before building a CI/CD pipeline

A pipeline automates your release process, so that process needs to be clear first. Decide on a branching model, whether everyone works on main or you keep develop and release branches, and list your environments with their servers and how each is accessed.

Write down the commands used today to build and test, even if they only exist in one person's head. Decide whether database migrations run automatically or after approval, and who is allowed to approve a production release.

ArgoCD, Helm and GitLab CI: who does what?

In the usual setup, GitLab CI builds and tests the image, pushes it to the registry and updates only the image tag in a deployment config repository. ArgoCD watches that repository and syncs the cluster to it. The pipeline never needs a cluster-admin kubeconfig, which takes direct production access out of CI.

We keep a values file per environment in the Helm chart, such as values-staging.yaml and values-production.yaml, and each ArgoCD Application renders from its own file. If someone changes the cluster by hand with kubectl, ArgoCD marks the app OutOfSync and, with selfHeal enabled, reverts it.