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