
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_PASSWORDonly exists when the job hasenvironment: productionset." - 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:
- Trigger Variables (Highest - from the API)
- Scheduled Pipeline Variables
- Project Variables (The UI)
- Group Variables
- YAML Block Variables (The
.gitlab-ci.yml) - 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
- List the variables in your current project. Do they follow the "Prefix Rule"?
- Create a variable and scope it ONLY to the
productionenvironment. - Try to access that variable from a job in the
stagingstage. Does it work? - 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).
- 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.