I've created a tool to help handle the frustrating "works on my machine" situations that occur when environment variables are missing during staging. The issue is that misconfigurations in environment variables can slip through CI processes, leading to deployment failures or worse, silent runtime errors. There's no type safety, no validation, and no centralized truth for these values.
To tackle this, I developed `zenv`, which validates .env files against a JSON schema. This tool quickly fails in CI if it detects bad configurations before they reach production. For example, the schema (`env.schema.json`) defines expected environment variables like `DATABASE_URL`, `LOG_LEVEL`, and `WORKER_COUNT`, specifying their types and whether they're required.
During CI, you can validate these variables using a simple GitHub Actions step:
```
- name: Validate environment
run: zenv check --env .env.production --schema env.schema.json
```
The command returns an exit code of 0 for valid configurations and 1 for invalid ones, identifying missing required variables, type mismatches, invalid enum values, or unknown variables not in the schema (which helps with detecting configuration drift).
Additionally, `zenv` offers features for generating schemas from existing .env files and can create documentation from these schemas. It's straightforward to install:
```
cargo install zorath-env
```
The tool is a compact 2MB binary with no runtime dependencies, compatible with any programming language. I'm intrigued to hear what others in the field use for validating environment variables in CI. Many teams I've encountered seem to be going with a trial-and-error approach and hoping for the best.
2 Answers
Great tool! I think a lot of teams still rely on manual .env variable management, which can lead to silent failures like missing required keys or having outdated keys. It's refreshing to see a solution like `zenv` that automates this validation, especially for development teams already under pressure. It encourages best practices in configuration management.
Using something like Docker is key to avoiding the 'works on my machine' issue since it allows consistent environments. CI/CD should execute the same scripts in the same containers as developers do locally, ensuring that everything is appropriately tested. But there's still a gap when it comes to passing environment variables into the container. While the Dockerfile may be the same, the .env file or the variables you pass in can vary between environments.
I get your point about Docker enhancing consistency. However, it doesn’t eliminate the risks associated with missing or incorrect environment variables. You could still end up with issues if your staging or production setups are not properly synchronized with what's defined in your .env files.
Totally agree! Automation like this can save teams a lot of headaches, especially when working with multiple environments. Anything that helps ensure consistency is a win in my book. Keep up the good work!