Правила

Стиль кода

Вся кодовая база должна иметь единый стиль кода, который определяется с помощью соответствующих утилит в репозитории.

Тестирование

На кодовую базу должны быть написаны тесты согласно документации.

Перед релизом тесты обязательно должны успешно проходиться.

Тесты должны покрывать:

• Основной функционал
• Части взаимодействия с пользователями

Версии приложений

Все релизы приложений версионируются согласно SemVer.

vX.Y.Z
 │ │ │
 │ │ └─> Patch version. Backward compatible bug fixes.
 │ └─> Minor version. Add functionality in a backward compatible manner
 └─> Major version. Incompatible API changes.

Про версии

Версии делают процесс обновления проще и удобнее.

Совместимость приложений

Приложения пришутся так, чтобы минимизировать проблемы обратной совместимости на несколько версий вперед.

Основная проблема с обратной совместимостью - база данных. Это значит:

• Все поля базы данных проектируются с учетом возможных изменений.

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

• Если сделать обновление без проблем со старой версией невозможно - продукт переводится на техническое обслуживание.

Плавающее обновление

Чтобы обновлять приложения без его остановки, необходимо проектировать изменения так, чтобы старое и новое приложения могли работать без ошибок.

Это позволят сделать обновление постепенным.

Контроль версий

Единой системой контроля версий является git.

Ветки

Вся кодовая база приложений разделена на две основные ветки: main и develop.

Код в каждой из них - протестирован, может собираться и запускаться. Отличие между ними в том, что main ветка содержит выпущеный в продакшен код, а develop - тестовую сборку новых функций, которые готовятся к релизу.

Для добавление нового кода используются любые другие ветки, например: feat-add-login-api, hotfix-login-process, fix-523 и другие.

Новые ветки сливают с main (в качестве быстрого исправления бага) или в develop только с помощью Pull Request на GitHub.

Коммиты

Все коммиты пишутся согласно Сonventional Сommits.

Заголовок и его тип является обязательным, а область применения, номер issue, тело коммита и футер коммита - необязательными.

<type>(<scope>): <summary> #XXX
  │       │         │        │
  │       │         │        └─> Issue number.
  │       │         │
  │       │         └─> Summary in present tense.
  │       │             Not capitalized.
  │       │             No period at the end.
  │       │
  │       └─> Commit scope: client|server|api
  │
  └─> Commit type: release|build|ci|feat|fix|ref|perf|style|test

[optional body]

[optional footer(s)]

Список поддерживаемых областей применения:

• client: изменение касающиеся клиенской части
• server: изменение касающиеся серверной части

Список поддерживаемых типов:

• release: изменение, которое обновляет версию кода для релиза
• build: изменение, которое влияет на систему сборки или внешние зависимости
• ci: изменение конфигурационных файлах или скриптах CI
• feat: добавление новой функции
• fix: изменение, которое исправляет ошибку
• ref: изменение, которое не исправляет ошибку и не добавляет функцию
• test: добавление недостающих тестов или исправление существующих тестов
• perf: изменение, которое улучшает производительность
• style: изменение, которые стилистически меняет код

Примеры

release: v1.0.0 #234
release: v1.0.0-rc #212

build: update deps #356
build: update Nuxt 3.12.2 to Nuxt 3.12.4 #357

ci: add deploy script #359

feat(client): add auth store of user data #756
feat(server): add middleware for loading user data into context #129
feat(server): add route to get active sessions #174

fix(client): lots loader on page load #471
fix(server): url path checker for s3 proxy #431
fix(server): image type validator for WebM ext #636

ref(client): update ui of user personal account page #550
ref(server): improve user validators #79

test: add e2e test for user authentication process  #1124

perf: improve image generation process #812

style: unify coding style

Пулл реквесты

Пулл реквест пишется в свободном стиле.

Обязательно долежн содержать ссылку на issue, с которым он связан.

Примеры

Add authorization functionality
feat: add authrization functionality
feat(#123): add authrization functionality