Evrika Standarts - Стандарты написания коммитов и управления версиями в компании Evrika

• О важности стандартов работы с Git в процессе разработки
• Что такое Evrika Standarts?
• Какие стандарты написания коммитов мы используем?
• Валидация и проверка коммитов на соответствие стандартам
• Использование инструментов для автоматического управления версиями
• Зачем вести и использовать changelog ?
• Вклад каждого члена команды
• Инструкция по установке и использованию

О важности стандартов работы с Git в процессе разработки

Стандарты в команде являются тем что помогает нам иметь четкое и истинное представление по работе с той или иной состовляющей процесса разработки.Работа с системой контроля версий Git, по сути является ныне устоявшемся стандартом в мире разработки. На основе Git строятся такие важные процессы как Code Review , CI/CD, и сама командная разработка в целом.Правила и соглашения это некий фундамент, и чем лучше он сделан тем крепче будет устойчивость здания.Так и в команде, правила и соглашения по работе с Git это фундамент для многих командных процессов, и чем лучше они обдуманы и сделаны, тем быстрее команда сможет двигатся вперед.

Из чего же складываются стандарты работы с Git? Стандарты по работе с системой Git можно условно разделить на две группы :

• Первые которые строятся поверх самого "Гита", вроде модели управления проектом (Git Flow, GitHub Flow, Trunk Based Development), соглашений по Code Review и созданию pull requests
• И вторые которые формируются по средствам работы (написание коммитов ,установка tags, ведение журнала изменений).

И здесь можно заметить связь, что чем больше процесс интегрирован с командным взаимодействием тем выше его важность.Получается процессы написания коммитов, ведения журнала изменений это та вещь которая должна быть автоматизирована и занимать как можно меньше времени, чтобы разработчик мог занятся более важными задачами.И здесь мы опять вспоминаем стандартизацию, по скольку именно она лежит в основе автоматизации работы с Git.Создание и использование таких стандартов позволяет улучшить командное взаимодействие и сделать другие процессы, такие как Code Review, CI/CD, автоматическое управление версиями более понятными и простыми для всей команды.

Что такое Evrika Standarts?

Не для кого не секрет что современные процессы разработки программного обеспечения стремятся к автоматизации всех аспектов разработки,от написания кода и до его автоматического развертывания.Evrika Standarts это пакет с конфигурацией для следующего набора инструментов автоматизации включающего в себя: Commitizen, semantic-release, Commitlint а также пояснением о том как их использовать и кастомизировать, тем самым внедрив, улучшив и автоматизировав такие процессы разработки как:

• Соглашение по написанию коммитов
• Валидация и проверка коммитов на соответствие стандартам
• Семантическое версионирование проектов
• Ведение журнала изменения (Changelog)

Этот пакет может послужить основой и образцом для создания вашего собственного набора конфигураций для ранее упомянутых инструментов.В конце описания находится подробная инструкция по уставновке пакета , дополнительных расширений и настройки их взаимодействия между собой

Какие стандарты написания коммитов мы используем?

Мы придерживаемся Conventional Commits — популярный стандарт написания коммитов, который определяет шаблон и набор ключевых слов для сообщений коммитов. Структура Conventional Commits включает тип коммита, необязательную область и описание изменений.В качестве инструмента автоматизации процесса создания коммита мы используем Commitizen за его гибкость и возможность собственной конфигурации. Мы используем следующие типы коммитов:

• build - изменения процесса сборки
• package - добавление или удаление внешних зависимостей
• change - стандартные изменения по проекту
• ci/cd - конфигурация CI или изменения CD параметров
• docs - добавление или изменения документации
• feat - создание нового функционала
• fix - исправление багов(именно багов не фич)
• perf - улучшения направленные на производительность
• refactor - реструктуризация и улучшения кода
• revert - отмена и возврат на предыдущий коммит
• style - правки по стилю кода и линтированию
• test - добавление тестов или изменение процесса тестирования
• custom - изменения имеющие специфичную область действия
• security - исправление уязвимостей или улучшение безопасности
• BREAKING CHANGE - координальные изменения в архитектуре или в системе проекта

Стоит отметить что как правило тип коммита указывает на определенную область изменения : feat(components) .Такой формат коммитов позволяет быстро понять, какие изменения вносились в проект и какие семантические изменения они вносят. У нас в команде область действия для типа коммита носит необязательный характер но его использование с кастомным значения радует.Так же мы стараемся соблюдать и соглашение по стилевому оформлению самих коммитов. Оно включает в себе такие казалось бы мелочи вроде - максимальной длины тела коммита, регистр символов, обязательные и не обязательные состовляющие, следует ли ставить в конце коммита точку.

Валидация и проверка коммитов на соответсвие стандартам

Проверка коммитов имеет важное значение для поддержания согласованности и структурированности истории изменений в проектах нашей команды.Мы используем Commitlint , он обеспечивает единообразие формата сообщений коммитов, тем самым повышая их читаемость и помогая лучше понять внесенные изменения.Его правиала позволяют уловить ошибки написания коммита как во время создания, так и в момент отправки коммита.

Использование инструментов для автоматического управления версиями

В процессе разработки проекта для соблюдении стандартов коммитов наша команда старается соблюдать и спецификацию по семантическому версионированию проектов.Использование инструментов управления версиями тесно интегрировано с соглашением по коммитам , наш выбор пал на инструмент semantic-release. Он обеспечивает всестороннюю поддержку принятых нами соглашений и имеет большой набор конфигураций и плагинов.Основные детали версионирования на которые влияет соглашения по оформлению коммитов:

• fix - коммит типа исправления ошибок соответствует PATCH в Cемантическом Версионировании. 1.2.3 - 1.2.4
• feat - создание нового функционала соответствует MINOR в Cемантическом Версионировании. 1.4.7 - 1.5.0
• BREAKING CHANGE - координальные изменения в архитектуре или в системе соответствует MAJOR в Cемантическом Версионировании. 2.3.4 - 3.0.0

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

Зачем вести и использовать changelog ?

Еще одной хорошей практикой грамотно выстроенного процесса разработки является ведение и использование журнала изменений.Это позволяет нам фиксировать каждое изменение, включая новые функции, улучшения и исправления, по мере их внесения в код.При ведении Changelog , наша команда опирается на следующие правила и соглашения.Мы используем систему версионирования для управления изменениями и версиями наших проектов. Каждое обновление в changelog связано с конкретной версией, что облегчает отслеживание и связывание изменений с определенными релизами.

Для генерации CHANGELOG.md мы используем уже ранее упомянутый semantic-release вместе с плагином для поддержки принятого стандарта форматирования коммитов

Вклад каждого члена команды

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

Мы стремимся поддерживать стандарты коммитов и использовать инструменты управления версиями, чтобы наши проекты были лучше структурированы, более управляемыми и способствовали эффективному сотрудничеству между всеми разработчиками компании Evrika

Инструкция по установке и использованию

Инструкция по установке и использованию - Evrika_Standarts package