В этом отчете рассматривается часть мыслительного процесса, которым руководствовался наш шаблон проекта, который обсуждался на более высоком уровне в отдельном посте:
Независимость от технологий: большая часть нашего проекта использует различные технологии, такие как ruby, python, nodeJS и другие. Таким образом, наш шаблон проекта не должен был зависеть от этих технологий. Это основная причина, по которой шаблон использует в основном shell, docker и docker-compose. С контейнерами нам больше не нужны инструменты управления версиями, такие как rvm, rbenv, chruby, pyenv, virtualenv, nvm и т. д., потому что нам просто нужно изменить версию в Dockerfile.
Сценарии оболочки: Терминал является общей зависимостью всех наших сервисов. Следовательно, мы записали все наши типичные задачи на shell, а не на каком-либо конкретном языке, даже если сценарий оболочки просто вызывает задачу ruby или python. Наши общие задачи включают в себя:
- запуск проекта: эта задача помогает новым разработчикам запустить проект. Кроме того, это гарантирует, что проект очищен от артефактов предыдущей задачи/функции, поэтому при запуске новой задачи/функции проект/контейнер находится в ожидаемом состоянии.
- настройка приложения: Эта задача включает в себя такие вещи, как создание и миграция базы данных. Он также может заполнить базу данных, поэтому разработка функций пользовательского интерфейса будет проще, поскольку есть существующие данные для тестирования.
- запуск приложения: Эта задача запускает сервер. Такие детали, как указание портов и удаление PID предыдущих серверных процессов, также могут быть полезны в этом скрипте.
- тестирование приложения: эта задача запускает тесты, а также может запускать линтеры, средства проверки стиля/формата и другие статические анализаторы кода.
- Резервное копирование приложения: Эта задача выполняет резервное копирование данных и схем, необходимых для приложения. Приложение может использовать несколько баз данных, поэтому этот сценарий позаботится об этих типах вещей.
Чтобы разделить общие подзадачи между каждым из скриптов, мы определили shell функций. Такие вещи, как ожидание запуска сервера базы данных, поместятся в этот файл.
Еще одним преимуществом написания сценариев для этих общих задач является то, что они могут быть легко обработаны конвейером CI/CD.
Многоразовые контейнеры: наш подход заключается в максимально возможном использовании значений по умолчанию, чтобы оставаться в соответствии с предположениями, сделанными создателями инструментов. Так, например, наши основные файлы Dockerfile и docker-compose.yml находятся в корне проекта. Это упрощает использование таких команд, как docuer-compose up.
Однако, чтобы иметь возможность повторно использовать контейнеры, когда другому зависимому проекту требуется текущий проект, мы extend docker-compose.common.yml, который содержит общие конфигурации, необходимые для создания экземпляра службы. Это позволяет зависимым проектам включать текущий проект как git submodule и extend из одного и того же docker-compose.common.yml.
Еще одним преимуществом использования контейнеров со сценариями оболочки является то, что приложение загружается и настраивается одинаково каждый раз, что позволяет избежать проблемы оно работает на моей машине. Зависимости операционной системы указаны в файле Dockerfile. В development.env указаны переменные окружения, которые засасываются в контейнеры через docker-compose).
И это все. Это ядро шаблона проекта, который мы используем. Это помогает нам быстро набирать обороты и работать продуктивно в каждом из наших приложений, а также позволяет избежать потери велосипедов. Я надеюсь, что это будет полезно и для вас, и если вы знаете, как улучшить шаблон, сообщите мне об этом.
