Module 10 Lesson 3: Variable Naming and Scoping
·DevOps

Module 10 Lesson 3: Variable Naming and Scoping

Precision in configuration. Learn the professional standards for naming your CI/CD variables and how to use 'Scoping' to prevent production secrets from leaking into dev builds.

Module 10 Lesson 3: Variable Naming and Scoping

Variables are the "Nervous system" of your pipeline. Poorly named variables lead to confusion, while poorly scoped variables lead to Security breaches.

1. Naming Conventions (The "Prefix" Rule)

In a big project, you might have 100 variables. Don't just use USER. Use prefixes:

  • DB_USER (Database)
  • AWS_SECRET_KEY (Cloud Provider)
  • CI_REGISTRY_USER (GitLab Built-in)
  • K8S_NAMESPACE (Kubernetes)

Rule of Thumb: All caps, with underscores, and always start with the Service Name.


2. Environment Scoping

This is the most important security check in GitLab.

  • You can say: "The variable DB_PASSWORD only exists when the job has environment: production set."
  • Result: Even if a developer hacks a "Test" job to print all variables, they will NOT see the production password because that variable doesn't exist in the "Test" environment scope.

3. Order of Precedence (The Conflict Resolver)

What happens if you define NODE_ENV in 3 different places? GitLab has a strict order:

  1. Trigger Variables (Highest - from the API)
  2. Scheduled Pipeline Variables
  3. Project Variables (The UI)
  4. Group Variables
  5. YAML Block Variables (The .gitlab-ci.yml)
  6. Built-in Variables (Lowest)

4. The "Dry Run" Variable Pattern

For dangerous jobs (like "Delete Old Data"), use a DRY_RUN variable.

cleanup-job:
  script:
    - if [ "$DRY_RUN" == "true" ]; then echo "Would delete data..."; else rm -rf /old-data; fi

By default, set DRY_RUN: "true". A user must manually change it to "false" to actually delete the data.


Exercise: The Variable Audit

  1. List the variables in your current project. Do they follow the "Prefix Rule"?
  2. Create a variable and scope it ONLY to the production environment.
  3. Try to access that variable from a job in the staging stage. Does it work?
  4. If you have two variables with the same name—one in the Group and one in the Project—which one will the runner see? (Review Section 3).
  5. Why is "Masking" (Module 3) necessary even if you use "Scoping"?

Summary

Variable Management is about Control. By following strict naming conventions and environment scoping, you build a pipeline that is self-documenting and "Secure by Default."

Next Lesson: Expecting the unexpected: Designing for Resilience.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn