Модель ветвления
git-flow хорош, но для небольших проектов он не нужен. Здесь гораздо легче применять упрощенную модель:
- Для каждой отдельной задачи создается новая ветка со ссылкой на Issue.
- После выполнения задачи создается PR и происходит ревью.
- После ревью и внесения всех правок ветка тащится в главную ветку разработки (можно даже master) по стратегии Squash and Merge, а затем удаляется.
Такая модель позволяет избежать обилия активных веток и большого количества коммитов в главной ветке разработки. Становится легче отслеживать изменения.
Работа с Issues
Этот раздел идет в связке с предыдущим. Давайте создвать Issue на каждый баг или улучшение, которое необходимо сделать, а затем назначать исполнителя как можно скорее.
Если задача большая, то можно создать Issue с чек-листом под базовую задачу, а затем отдельные Issue под каждый шаг ее выполнения, и в них вписать ссылку на базовую задачу.
Docker-образы
Давайте переберем Docker-образы для Viewer и бэкенда.
Сначала бэкенд:
- Dockerfile должен лежать в основной директории проекта. Это облегчает написание путей при сборке и деплое.
- Два Dockerfile на один проект точно не нужно. Если хочется разделить базовый и рабочий образы, можно использовать сборку под разные таргеты.
- Не нужно пихать конду в образ. Да, она удобна для разработки, но для деплоя и тестирования она бесполезна и только нагружает образ, увеличивая время сборки и пожирая больше ресурсов. Лучшая практика - использовать конду локально для разработки, а образ наследовать от обычного образа python и устанавливать зависимости через любой менеджер зависимостей (да хоть pip).
- Хардкодить зависимости в Dockerfile не нужно. Их лучше отдать менеджеру зависимостей. Я рекомендую poetry, но можно использовать и pip.
Насчет Viewer:
- Очень не нравится цельная Multistage сборка сразу с nginx. Можно разделить сборку на два таргета. Первый будет собирать и запускать nodejs-приложение, второй - настраивать nginx и соединять его с приложением из первого таргета через обратный прокси.
- Обе сборки можно соединять для интеграционного тестирования или продакшена через композ (см. следующую секцию). Это упростит развертку кластера в перспективе.
docker-compose
А давайте использовать docker-compose. Он избавит нас от необходимости собирать и запускать образы вручную и облегчит интеграционное тестирование. Можно поднять один нетворк для бэкенда и фронта, чтобы тестировать их вместе, если такая возможность потребуется.
CI
В Viewer уже есть конфиг для CircleCI, но мы его не используем. Там доступен бесплатный план на 2500 кредитов в неделю, что более чем достаточно для нас.
Шаги пайплайна:
- Build
- Test
- Publish (только на основной ветке)
- Deploy (только на основной ветке)
Джобы:
- Build - сборка нового docker-образа проекта. Шаг - Build.
- Code Health - проверка стиля кода. Для JS реализуется с помощью StandardJS и prettier-standard. Для питона - flake8, black, isort и mypy. Шаг - Test.
- Unit Tests - модульные тесты проекта. Шаг - Test.
- Integration Tests - интеграционные тесты проекта. Включают в себя тесты взаимодействия между компонентами и тесты сложных составных процессов. Выполняются с помощью docker-compose. Шаг - Test.
- Tag and Publish - постановка тега для последнего образа и
docker push
в репозиторий. Шаг - Publish.
- Deploy to Demo Server - развертка на демо-сервер с помощью Ansible. Шаг - Deploy.
База знаний и документация
Для написания доков и создания "базы знаний" можно использовать рабочий воркспейс (например Notion). Это позволит писать доки в удобоваримом формате (гораздо более удобном, чем Markdown), вести учет глобальных задач, структуры и текущего состояния проекта.
Дополнения и правки приветствуются