Перейти к содержанию

Правила работы с git#

Эталонный репозиторий.

Структура репозиториев#

  • Наименование в соответствии с соглашением.
  • Иерархия вложенности групп репозиториев согласно WBC.
  • Репозиторий находится на нижнем уровне и содержит потоки данных конкретной "команды" (домена).
  • Каждый репозиторий обязан соответствовать следующей структуре

Скрипт для генерации шаблона репозитория

Скрипт для генерации шаблона директории с контрактом

Получение доступов#

После того, как дата-стюард создаст для вас репозиторий согласно шаблону, нужно запросить доступ уровня Developer через ServiceDesk

Публикация готового контракта#

  1. Создать ветку согласно правилам.
  2. Добавить все локальные изменения в репозиторий.

  3. Запустить .pre-commit-config.yaml из соответствующей репозиторию директории. 

    pip install pre-commit
pre-commit install
pre-commit run --all-files

  4. Сделать коммит согласно правилам оформления коммитов.

  5. Сделать Merge Request в ветку master.
  6. Контракт должен пройти согласование.
  7. Дата-стюард делает Merge в master.

Правила наименования веток#

  • Наименование веток, в которых ведется работа дата-стюардов, обязаны совпадать с идентификатором соответствующей задачи в Youtrack. Пример: dto-1417
  • Наименование веток, в которых ведется работа владельцами данных, обязаны совпадать с идентификатором соответствующей заявки в ServiceDesk. Пример: DTPL-007

Правила оформления коммитов#

Формат: type(scope:name): Добавлено описание на русском

  • Один файл - один коммит (Исключение - для chore/BREAKING CHANGE - если какие-то автоматизированные массовые изменения, допустимо создавать один коммит на весь репозиторий)
  • Коммиты должны быть однострочными
  • Изменения должны быть описаны одним предложением, действие должно быть страдательным причастием в прошедшем времени

Обязательные типы:

  • feat - добавление или расширение контрактов
  • fix - исправление ошибок в контрактах:
    • неверные типы данных
    • синтаксические/логические/орфографические ошибки
    • пустые/отсутствующие/неверные значения в ключевых словах
  • docs - любые изменения в документации, в частности в файлах README.md и info.yaml
  • BREAKING CHANGE - ломающие изменения:
    • изменение структуры контракта (например, приведение к плоской структуре)
    • изменения, связанные с обновлением спецификации (например, удаление ключевого слова из спецификации - удаление его из всех контрактов)
    • удаление/переименование полей
    • изменение состава primaryKey
  • chore - служебные изменения, не затрагивающие логику контрактов:
    • изменение названий файлов/путей
    • изменения, связанные с обновлениями naming convention
    • прочие изменения

Scope (опционально)

  • repo - изменения, затрагивающие весь репозиторий
  • contract - изменения, затрагивающие конкретный контракт

Примеры:

feat(contract:test-topic): добавлен новый контракт
feat(contract:test-topic): добавлено поле new_id

docs(repo:my_repo): обновлен файл README
docs(contract:my-topic): добавлены ссылки на документацию в info.yaml

fix(contract:position-changes): добавлено поле payment_type

chore(repo:my_repo): изменен ответственный Data Steward
chore(contract:another-topic): изменено наименование формата даты и времени

BREAKING CHANGE(repo:my_repo): добавлен новый контракт my-topic
BREAKING CHANGE(contract:test-topic): удалено ключевое слово utcOffset

Процесс согласования#

Владелец потока - сотрудник, указанный в contract_maintainer из info.yaml соответствуюшего потока, либо в соответвующем поле заявки ServiceDesk

  • Владельцы потока отвечают за актуальность контракта.
  • Владельцы потока отвечают за валидацию всех изменений, связанных с потоком.
  • Владельцы потока указываются в переменной репозитория CI OWNERS (согласно требованиям ИБ).
  • Merge Request не может быть вмержен без Approve от лиц перечисленных в CI OWNERS.
  • Merge Request может быть вмержен, только после успешной работы CI/CD Pipeline.

Все изменения проходят обязательное ревью перед вливанием.

CI / CD#

При создании MR запускаются:

  • Линтер на проверку соответствие спецификации
  • Линтер на проверку структуры репозиториев
  • Линтер на корректность yaml файлов и стилей форматирования
  • Проверка от ИБ на наличие approve от лиц перечисленных в CI OWNERS

После Merge:

  • helper на основе контракта генерирует Avro Schema и DDL для хранилища в артефакты репозитория