При разработке приложений я всегда стараюсь придерживаться манифеста двенадцати факторов. Такой подход позволяет избежать большого количества проблем, связанных с развертыванием приложений и их дальнейшей поддержкой.
Один из принципов этого манифеста гласит, что все настройки должны хранится в переменных окружения. Это позволяет менять их под разные окружения (Staging, QA, Production) без изменения кода.

Однако, во время разработки могут возникать сложности при работе с такими переменными. С ростом проекта, обычно также увеличивается количество переменных окружения и с ними становится не так удобно работать. Нужно каждый раз указывать их все при запуске приложения:
$ RAILS_ENV=development REDIS_URL=redis://redis:6379 DATABASE_URL=postgres://postgres:postgres@db:5432 bundle exec rails server
И тут на помощь приходят .env файлы. Они предоставляют удобный способ хранения всех переменных окружения в одном месте:
# .env
RAILS_ENV=development
REDIS_URL=redis://redis:6379
DATABASE_URL=postgres://postgres:postgres@db:5432
Для работы с .env файлами есть довольно много библиотек на разных языках программирования. Всё что они делают — это загружают переменные из .env файла при запуске приложения:
- Rust: https://github.com/dotenv-rs/dotenv;
 - Golang: https://github.com/joho/godotenv;
 - Ruby: https://github.com/bkeepers/dotenv;
 - PHP: https://github.com/vlucas/phpdotenv;
 - Elixir: https://github.com/avdi/dotenv_elixir;
 - JavaScript: https://github.com/motdotla/dotenv;
 - Haskell: https://github.com/stackbuilders/dotenv-hs;
 - Python: https://github.com/theskumar/python-dotenv.
 
При использовании Docker и Docker Compose переменные окружения можно указать с помощью ключа environment в файле docker-compose.yml:
# docker-compose.yml
version: '2.4'
services:
  app:
    build:
      context: .
    environment:
      RAILS_ENV: development
      REDIS_URL: redis://redis:6379
      DATABASE_URL: postgres://postgres:postgres@db:5432
Но, как я уже писал ранее, с ростом проекта также увеличивается количество переменных, а вместе с ними и количество сервисов, которые необходимы вашему приложению, например Redis, RabbitMQ и т.д. И со временем, docker-compose.yml увеличивается в размерах и становится просто нечитаемым. В такой ситуации опять же могут помочь .env файлы, в которые можно вынести все переменные окружения и подключить их к docker-compose.yml с помощью ключа env_file:
# docker-compose.yml
version: '2.4'
services:
  app:
    build:
      context: .
    env_file:
      - .env
В процессе работы с .env файлами, часто могут возникать проблемы, которые можно не заметить с первого взгляда и даже пропустить при проверке кода, но которые могут стать причиной неправильной работы приложения:
1. Дублирование ключей
Такую проблему можно встретить, если в проекте есть .env файл, который содержит большое количество строк. В этой ситуации, легко не заметить появление новых переменных окружения с уже существующими ключами. В таком случае, новые переменные перезапишут старые значения:
# .env
FOO=BAR
# ...
FOO=FOO
2. Неправильный разделитель
Для удобства ключи переменных окружения можно разделять с помощью символа _. Однако в процессе разработки можно легко ошибиться и использовать другой символ, например -:
# .env
# Неправильно
FOO-BAR=FOOBAR
# Правильно
FOO_BAR=FOOBAR
3. Переменные без значения
Иногда бывают ситуации, когда нужно добавить новую переменную в приложение, но пока неизвестно, какое значение у неё будет. В таком случае обычно добавляют пустую переменную окружения. Но и здесь можно допустить ошибку, забыв указать символ =:
# .env
# Неправильно
FOO
# Правильно
FOO=
4. Некорректный первый символ
Не все знают, но есть ограничения при наименование переменных окружения. Они не могут начинаться с цифр и других символов, за исключением символа _:
# .env
# Неправильно
 FOO=BAR
.FOO=BAR
*FOO=BAR
1FOO=BAR
# Правильно
_FOO=BAR
5. Ключи в нижнем регистре
Продолжая тему ограничений, нельзя не упомянуть, что все ключи переменных окружения должны быть в верхнем регистре:
# .env
# Неправильно
foo=bar
# Правильно
FOO=bar
6. Пробелы
Ещё одной проблемой могут стать пробелы. Особенно, если они присутствуют между ключом и значением переменной окружения:
# .env
# Неправильно
FOO = BAR
# Правильно
FOO=BAR
7. Сортировка по алфавиту
Сортировка, конечно, не является проблемой, но куда приятнее работать с .env файлами, где все ключи отсортированы по алфавиту:
# .env
# Неправильно
FOO=BAR
BAR=FOO
# Правильно
BAR=FOO
FOO=BAR
Все проблемы, описанные выше, взяты из реальных проектов. На протяжение всей своей работы я постоянно сталкивался с ними, что доставляло различные неудобства в процессе разработки, а в некоторых случаях даже приводило к неправильной работе приложений.
Поэтому в один прекрасный день я решил создать инструмент, который позволил бы мне избежать подобных проблем в будущем, раз и навсегда.
И вот так появился dotenv-linter — линтер для .env файлов. Он позволяет проверить .env файлы на наличие всех проблем, описанных выше — от дублирования ключей и до сортировки.
Его ключевые особенности:
- Молниеносно быстрый и всё благодаря тому, что он написан на Rust 🦀
 - Можно использовать на любом проекте, вне зависимости от языка программирования 🔥
 - Возможна интеграция с reviewdog и CI сервисами (включая GitHub Actions) 🚀
 
Установка
Есть несколько вариантов установки dotenv-linter. Самый простой вариант — скачать бинарный файл с помощью curl или wget:
# Linux / macOS / Windows (MINGW и т.д.). По умолчанию устанавливается в директорию ./bin
$ curl -sSfL https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s
# Можно указать директорию установки и версию
$ curl -sSfL https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s -- -b usr/local/bin v2.0.0
# Alpine Linux (wget)
$ wget -q -O - https://raw.githubusercontent.com/dotenv-linter/dotenv-linter/master/install.sh | sh -s
Другой вариант — установить через Homebrew:
$ brew install dotenv-linter
Так же есть возможность запуска dotenv-linter с помощью Docker:
$ docker run --rm -v `pwd`:/app -w /app dotenvlinter/dotenv-linter
Другие варианты установки можно найти на сайте проекта dotenv-linter.github.io.
Использование
По умолчанию dotenv-linter проверяет все .env файлы в текущей директории:
$ dotenv-linter
.env:2 DuplicatedKey: The FOO key is duplicated
.env:3 UnorderedKey: The BAR key should go before the FOO key
.env.test:1 LeadingCharacter: Invalid leading character detected
Чтобы проверить другую директорию, достаточно передать её путь в качестве аргумента. Этот же подход работает, если нужно проверить какие-нибудь файлы по отдельности:
$ dotenv-linter dir1 dir2/.my-env-file
dir1/.env:1 LeadingCharacter: Invalid leading character detected
dir1/.env:3 IncorrectDelimiter: The FOO-BAR key has incorrect delimiter
dir2/.my-env-file:1 LowercaseKey: The bar key should be in uppercase
Исключить какой-нибудь файл из проверки можно с помощью аргумента --exclude:
$ dotenv-linter --exclude .env.test
.env:2 DuplicatedKey: The FOO key is duplicated
.env:3 UnorderedKey: The BAR key should go before the FOO key
Интеграция
Отдельно стоит упомянуть про возможность интеграции dotenv-linter с reviewdog, что позволяет получать предупреждения от линтера в виде комментариев на GitHub или GitLab.
$ dotenv-linter | reviewdog -f=dotenv-linter -diff="git diff master"
При использование GitHub Actions, достаточно будет подключить к проекту dotenv-linter/action-dotenv-linter:
# .github/workflows/dotenv_linter.yml
name: dotenv-linter
on: [pull_request]
jobs:
  dotenv-linter:
    name: runner / dotenv-linter
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v1
      - name: dotenv-linter
        uses: dotenv-linter/action-dotenv-linter@v1
Больше информации вы можете найти на сайте проекта dotenv-linter.github.io.
С самого начала dotenv-linter разрабатывался силами Open Source сообщества.
Поэтому, если у вас есть желание поизучать Rust и заодно поучаствовать в разработке замечательного Open Source проекта, то dotenv-linter — это то, что вам нужно!
Мы будем рады любой помощи!