• Полный список команд, необходимых для развертывания в dev/prod/etc средах, а также дополнительных необходимых команд (миграции, сброс кеша и проч.) в README или Confluence репозитория проекта.
  • Актуальный список програмных зависимостей приложения в README или Confluence, если они явно не указаны в конфигах для сборки (например в composer.json).
  • Список инфраструктурных зависимостей в README или Confluence (rabbitmq, postgresql и проч.) с указанием точной мажорной версии, а так же описанием необходимых прав доступа.
  • Сборка каждого типа сервиса (например бекенда и фронта) должна быть независимой, за исключением случаев, когда сервисы используют общую кодовую базу. Код НЕ МОНТИРУЕТСЯ в контейнер, за исключением специально оговоренных случаев.
  • Все параметры приложения должны определяться ПРИ СТАРТЕ ПРИЛОЖЕНИЯ, конфигурирование должно происходить через переменные окружения
    • В случае с фронтами, все переменные (вроде урлов) должны быть вынесены в отдельный статический конфиг файл, который собирается вместе с остальным кодом. Это необходимо для того, чтобы без пересборки была возможность использовать один контейнер для разных сред разработки.
    • В случае в бекендами все параметры должны быть определены из переменных окружения в рантайме. Контейнер с приложением должен иметь возможность запускаться в разных окружениях, вне зависимости от параметров сборки.
  • Крайне рекомендуется отказаться от использования разделения параметров окружения через APP_ENV или аналогичные методы, за исключением локальной разработки.
  • Ни одно приложение НЕ ДОЛЖНО ПИСАТЬ В ФАЙЛОВУЮ СИСТЕМУ. Все данные должны храниться либо в S3, либо в БД. Это правда важно. Исключение - различные кеши и прочие временные файлы, потеря которых не критична.
  • Экземпляры одного приложения не должны конфликтовать, если нет объективных архитектурных ограничений. Необходимо, чтобы приложение горизонтально масштабировалось.
  • Необходимо избегать создания cron-заданий. Регулярно-выполняемые команды должны быть оформлены как незавершающийся процесс.
  • Время запуска приложения должно быть минимальным. Внезапная остановка приложения не должна приводить к какому-либо сбою, особенно нарушению целостности данных.
  • Задания, выполняемые приложением должны иметь свойство идемпотентности.
  • Все логи приложения должны выводиться в stderr.
  • Приложение должно иметь healthcheck'и, которые должны быть описаны в README или Confluence.
    • Liveness check - проверка, с помощью которой можно определить, что приложение запущено и полностью функционирует.
    • Readness check - проверка, с помощью которой можно определить, что приложение завершило инициализацию, и на него можно пускать трафик.
  • Маршрутизация трафика никогда не должна требовать rewrite'ов на стороне proxy-сервера.