> For the complete documentation index, see [llms.txt](https://dinush-chathurya.gitbook.io/kustomize-e-book/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dinush-chathurya.gitbook.io/kustomize-e-book/gitops-and-ci-cd/11-ci-cd-pipelines.md).

# CI/CD Pipelines

A robust CI/CD pipeline automates validation, packaging, and deployment of your Kustomize manifests. In this chapter, we’ll cover how to integrate Kustomize into modern CI/CD systems—using GitHub Actions and GitLab CI as examples—to ensure safe, repeatable, and auditable deployments.

***

## Why CI/CD for Kustomize?

* **Automated Validation**: Lint and dry-run your manifests on every change.
* **Consistent Builds**: Guarantee the same generated YAML is deployed.
* **Fast Feedback**: Catch errors early before they reach production.
* **Audit Trail**: Every deployment is tied to a commit or PR.

***

## Pipeline Stages

1. **Checkout** – Pull code from Git.
2. **Lint & Validate** – Use `kustomize build` + `kubectl apply --dry-run` + linters.
3. **Unit Tests** (optional) – Validate YAML schemas or custom policies (e.g., OPA/Gatekeeper).
4. **Build Artifacts** – Package generated YAML as release assets or push to a GitOps repo.
5. **Deploy** – Apply to dev/staging clusters or create PR for production.
6. **Notifications & Rollback** – Notify teams and handle failures.

***

## 1. GitHub Actions Example

**`.github/workflows/deploy.yml`**:

```yaml
name: CI/CD Kustomize

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Set up Kustomize
        uses: imranismail/setup-kustomize@v1

      - name: Lint Kustomize
        run: |
          kustomize build kustomize/base | kubectl apply --dry-run=client -f -
          kustomize build kustomize/overlays/dev | kubectl apply --dry-run=client -f -

  deploy-dev:
    needs: validate
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Deploy to Dev
        run: |
          kubectl config use-context dev-cluster
          kubectl apply -k kustomize/overlays/dev
```

🔑 Use `--dry-run=client` or `--dry-run=server` for pre-deployment checks.

## 2. GitLab CI Example

**`.gitlab-ci.yml`**:

```yaml
stages:
  - validate
  - deploy

variables:
  KUSTOMIZE_PATH: "kustomize/overlays/$CI_ENVIRONMENT_NAME"

validate:
  image: bitnami/kubectl:latest
  stage: validate
  script:
    - kubectl version --client
    - kustomize build kustomize/base | kubectl apply --dry-run=server -f -

deploy:
  image: bitnami/kubectl:latest
  stage: deploy
  environment:
    name: $CI_ENVIRONMENT_NAME
  script:
    - kubectl config use-context $CI_ENVIRONMENT_NAME-cluster
    - kubectl apply -k $KUSTOMIZE_PATH
  only:
    - main
```

🔑 Use `$CI_ENVIRONMENT_NAME` (e.g., `dev, staging, prod`) to target overlays dynamically.

## 🧪 Testing and Rollback

* Dry-run all changes:

```bash
kustomize build overlays/prod | kubectl apply --dry-run=server -f -
```

* Diff preview:

```bash
kustomize build overlays/prod | kubectl diff -f -
```

* Rollback by reverting the Git commit or PR that updated the manifests.

## Security & Secrets

* Use `GitHub Actions Secrets` or `GitLab CI` Variables for `KUBECONFIG` or tokens.
* **Don’t store** kubeconfigs in the repo—inject at runtime.
* **Least privilege**: CI service accounts should only have permissions for target namespaces.

## Best Practices

* **Parallelize** validation and deployment jobs where possible.
* **Promote via Pull Requests**: Deploy to dev/staging automatically; require PR approvals for prod.
* **Use environment protection rules** (branch or environment locks) to prevent accidental prod deploys.
* **Archive build artifacts** (generated YAML) for auditing and rollback.
* **Integrate notifications** (Slack, Teams) on CI/CD success or failure.

## Summary

Integrating Kustomize into CI/CD pipelines brings repeatability, safety, and speed to your Kubernetes deployments. Whether you choose GitHub Actions, GitLab CI, or another system, following these patterns will help you build robust, production-ready workflows.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://dinush-chathurya.gitbook.io/kustomize-e-book/gitops-and-ci-cd/11-ci-cd-pipelines.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.