При оформлении Pull Request в любую ветку происходит проверка на осуществление локального билда в GitHub Actions. В ходе данного билда выполняется проверка стиля добавленного программного кода. При обновлении main ветки происходит автоматизированный деплой проекта в следующих сервисах:

1. Фронтенд клиент размещается на CDN Netlify: https://thetruestore.netlify.app
2. Бэкенд сервис размещается в контейнере Heroku: https://thetruestore.herokuapp.com/swagger-ui/index.html Между собой сервисы интегрированы, деплой занимает не более 3 минут после обновления main ветки.

Настройка деплоя в CDN Netlify осуществяется в файле frontend/docker-compose.netlify.yml, где нужно:

• установить адрес бэкенда сервера в переменной окружения BACKEND_URL;
• указать субдомен размещения <subdomain>.netlify.app;
• В GitHub Secrets сохранить токен доступа в Netlify NETLIFY_ACCESS_TOKEN. Соответствующий токен доступа получается в админинстративной панели Netlify, приложение тоже должно быть создано заблаговременно (для этого можно в ручном режиме закачать пустой файл index.html).

Настройка деплоя в Heroku проводится в GitHub Secrets установкой:

• HEROKU_API_KEY - API ключ сервиса;
• HEROKU_APP_NAME - наименование приложения.

Также заблаговременно необходимо создать приложение в Heroku, подключить к нему Postgres в разделе Resources, подключить heroku/java а в разделе Buildpacks. Heroku при запуске контейнера автоматически инициализирует следующие переменные окружения:

• JDBC_DATABASE_PASSWORD - пароль базы данных;
• JDBC_DATABASE_URL - адрес базы данных в формате Spring: jdbc:postgresql://domain:5432/database;
• JDBC_DATABASE_USERNAME - пользователь базы.

Все указанные сведения содержатся в разделе Credentials созданной на Heroku базы данных Postgres.

Все сервисы контейнеризованы и запускаеются одной командой:

docker-compose up --build -d

После запуска на локальной машине доступны следующие службы:

1. Веб-клиент (80 порт): http://localhost
2. Бэкенд-сервис (8080 порт), OpenAPI: http://localhost:8080/swagger-ui/index.html

Остановка и удаление сервисов, запущенных на локальной машине:

docker-compose down -v

1. Разработка ведется в ветке develop, добавление нового функционала осуществляется через Pull Request в ветку develop из соответствющей feature-ветки.
2. В develop ветку сливается только полностью работоспособный код.
3. Feature ветка должна иметь осмысленное и краткое название, например:

• feature/some_name - наименование фичи;
• bug/some_name - багфикс или эксперимент;
• hotfix/some_name - хотфикс.

4. Pull Request в develop должен отвечать требованиям атомарности и содержать:

• заявленный функционал;
• осмысленный заголовок и желательно краткое описание;
• необходимые тесты для проверки функционала (как правило, юниит тесты и базовые интеграционные тесты);
• справочную информацию и информацию по развертыванию функционала.

5. Pull Request в develop ветку должен:

• не нарушать работу ранее добавленного функционала (проходятся все предыдущие тесты);
• не объединять несколько разноплановых фич (одна фича -- один PR);
• быть актуальным на момент создания (например, пока вы писали фичу ветка develop уже убежала вперед, был добавлен некоторый функционал. Ответственность создателя PR -- сделать merge или rebase от develop ветки и самостоятельно разрешить все конфликты слияния до отправки PR).

6. За слияние в develop ветку отвечает техлид, перед слиянием:

• проводится code review одним из членов команды, получается подтверждение;
• проверяется работоспособность функционала системы (автоматизированно или в ручном режиме);
• о проведенном слиянии информируются участники команды (автоматизированно или в ручном режиме).

7. Слияние develop в main ветку означает релиз на stage стенд, проводится техлидом.