GitLab CI is CI/CD built directly into the GitLab platform. The pipeline is defined in a .gitlab-ci.yml file in the repository root. When you push code, GitLab automatically reads this file and runs the pipeline. No separate server, no plugins to manage. Key differences from Jenkins: GitLab CI configuration is in the repo itself — pipeline as code from day one. Jenkins requires a separate server, plugin management, and manual Jenkinsfile setup. GitLab CI has built-in container registry, artifact storage, and environment tracking. GitLab CI runners are simpler to scale on Kubernetes than Jenkins agents. Jenkins has more mature shared library ecosystem and more plugin options for complex enterprise workflows. When to choose GitLab CI: team is already using GitLab for code, issues, and merge requests — the integrated experience (code change directly shows pipeline status in MR) is valuable. When to choose Jenkins: very complex pipeline logic requiring Groovy, existing enterprise Jenkins infrastructure, or working across multiple source control systems.

Artifacts are files produced by a job that need to be passed to later jobs in the same pipeline. They are uploaded to GitLab server and downloaded by dependent jobs. Example: a build job compiles a JAR file, the deploy job needs that JAR. The build job declares it as an artifact, the deploy job automatically receives it. Artifacts expire (you set expire_in) and are deleted after that time. Cache is for speeding up pipelines across multiple pipeline runs — not for passing files between jobs. Cached files persist between pipeline runs so you do not re-download Maven dependencies or node_modules on every run. Caches are stored on the runner or in object storage. Cache can be stale (use cache:key to invalidate when pom.xml changes). The key distinction: artifacts = pass files between jobs in the same pipeline run. Cache = persist files between pipeline runs to save time. Common mistake: using cache to pass build artifacts between jobs — if the cache is not present, the job silently fails with missing files.

Multi-stage pipeline with environment protection. Structure: stages: build, test, security, package, deploy-staging, deploy-production. Build and test stages run in parallel using parallel keyword or by having multiple jobs in the same stage. Security stage runs Trivy image scan and SAST scanning. Package stage builds and pushes Docker image tagged with CI_COMMIT_SHA — never use latest tag in pipelines. Deploy-staging runs automatically on every main branch merge. Deploy-production is manual trigger only, restricted to protected main branch, with environment approval required in GitLab. Use include to share common job definitions across multiple service repos — put shared templates in a central repo, each service repo includes them. Review apps for merge requests: automatically deploy to a review-namespace-MR-ID URL on every MR, automatically cleaned up when MR closes. Environment tracking: GitLab → Deployments → Environments shows what version is deployed where, who deployed it, and links to the commit. Rollback: re-trigger the deploy job from a previous successful pipeline run.

Measure first: GitLab → CI/CD → Pipelines → click a pipeline → Pipeline Duration chart shows which jobs take longest. Main optimisations: One — enable caching. Maven .m2/repository, Node node_modules, pip cache. Use cache:key based on the dependency file hash so cache invalidates only when dependencies change. Save 2-5 minutes per run. Two — use needs keyword. By default GitLab waits for the entire previous stage before starting the next stage. With needs, a job starts as soon as its specific dependencies finish. A deploy job can start as soon as the build job finishes, without waiting for all test jobs. Three — use parallel matrix for test splitting. Large test suites split into N parallel jobs: parallel: matrix: with different test subsets. Four — use Docker layer caching. Pass --cache-from in docker build so unchanged layers are not rebuilt. Five — use rules carefully. Expensive security scans only on main branch, not every feature branch push. rules: if CI_COMMIT_BRANCH == main reduces scan runs by 90%. At scale with Kubernetes runners: pods spin up in parallel — you are no longer limited by runner count.