Управление версиями в «1C:Предприятие 8» (git)
Управление версиями в «1C:Предприятие 8» (git)

Статья является переосмыслением и дополнением к предыдущим трудам «Управляем версиями в «1C:Предприятие 8» (Git)» и «Управляем версиями и тестированием «1C:Предприятие 8» (Git, часть 2)». Как оказалось, многие не понимают зачем такие сложности и почему? Попытаюсь ответить на эти вопросы и описать подход git-flow.

Разработка качественных продуктов для «1С:Предприятие 8» довольно большая проблема. Для начинающих программистов и специалистов средней руки вопрос не стоит так остро, они не отвечают за работу огромных, высоконагруженных, сложных и нестандартных механизмов, где иногда часы простоя стоят огромных денег. Естественно все это создается не одним человеком и не за один день, когда случается переход от простых задач к глобальным и цена ошибки велика, вот в этот момент возникают вопросы взаимозаменяемости специалистов, совместное владение кодом и даже просто владение, регистрация и учет изменений, сроки реализации функционала, тестирование, списки приемных тестов и т.д.

Что же мы имеем в «1С:Предприятие 8»

Хранилище конфигурации:

  • довольно спорный инструмент (в моем опыте несколько раз хранилище становилось полностью не рабочим);
  • совместное удобство работы сомнительное;
  • выполнить привязку к трекеру задач нельзя;
  • код ревью делать не удобно, да и отметить спорные изменения нельзя;
  • нет понятий release, hotfix, feature;
  • и многое-многое другое;
  • хорошо описано здесь.

Чего же всё-таки хочется

  • выполнять изменения без захвата объектов;
  • при попытки внесения изменений, их должен принять человек с черным поясом по код ревью;
  • каждый разработчик работает независимо от того, что делает другой программист;
  • возможность использовать ветвления и выпускать продукт из комбинации удачных веток;
  • при закрытии задачи в системе разработки, изменения кода можно просмотреть в трекере задач;
  • комментирование построчно кода с оповещением человека, который пытается поместить изменения.
В данном случае большинство запросов решает связка: Git-flow + Redmine + Bitbucket \ GitHub. Теперь перейдем к самой статье.

Установка Git

Git берем отсюда http://git-scm.com/download. С установкой не должно возникнуть проблем. Как пользоваться Git можно прочесть здесь.

Что такое контроль версий, и зачем он вам нужен?
Система контроля версий (СКВ) — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов.

Выбираем BITBUCKET.ORG или GITHUB.COM

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

Что выбрать, и зачем это нужно?
Сервисы позволяют провести код ревью, выполнить объединение, синхронизацию, оповестить трекер задач об изменениях по определенной задаче, выслать извещение участникам проекта и т.д. В каждом сервисе есть свои плюсы и минусы — выбор остаётся за вами.

Необходимые вещи

Хранить в Git бинарные файлы можно, но практической пользы от этого мало, их нужно распаковать в текстовые файлы понятные простому обывателю. С конфигурацией сделать это просто с помощью команды «Выгрузить конфигурацию в файлы…». С внешними обработками и отчетами это сделать сложнее, на помощь приходит сообщество c инструментами V8Commit или precommit1C, последний умеет собирать внешние обработки и отчеты из файлов.

Что выбрать?
Сейчас precommit1C активно развивается и дорабатывается, по моему, выбор очевиден. V8Commit развивается «закрыто» и пока не ясно под какой лицензией будет распространяться в дальнейшем, так же нужно обязательно в commit включать бинарные файлы (*.epf, *.erf).

Когда осилены предыдущие пункты

Примерный результат будет таков (в данном примере bitbucket.org):Git-flow в «1С:Предприятие 8»

К каждой строчке можно оставить комментарий, этот текст придет участникам проекта на почту (можно перенастроить), если это pull-request, только тому кто запросил внести изменения. Красным цветом помечено, что удалено; зеленым цветом, что добавлено; ярко-зеленым, что добавлено новое в этой строке по сравнению с предыдущей версией.

Терминология Git-flow

  • fork — использование кодовой базы проекта для старта нового или доработки с последующий объединением;
  • pепозиторий — место, где хранятся и поддерживаются какие-либо данные;
  • push — отправить\обновить новые или измененные объекты в удалённый репозиторий;
  • pull — получить\обновить новые или измененные объекты из удалённого репозитория;
  • pull request — запрос на объединение fork c кодовой базой стартового проекта;
  • alias — используется для сокращение команд;
  • branch — направление разработки, независимое от других;
  • master — в данной статье стабильная\рабочая\используемая ветка;
  • develop — в данной статье ветка которая разрабатывается и в будущем изменения будут перенесены в ветку master, после успешной демонстрации заказчикам;
  • hotfix/number — ветка, которая предназначена для внесения правок напрямую в master, по сути это ветка быстрых исправлений критических ошибок, number — номер задачи трекера;
  • feature/number — ветка, которая предназначена для реализации нового функционала, после того как задача предположительно готова — выполняется pull request в ветку develop. При удачном код ревью, выполняется объединение с веткой develop, иначе отсылается на доработку. number — номер задачи трекера;
  • code review — проверка кода на оптимальность, соответствия техническому заданию и стандартам http://its.1c.ru/db/v8std.

Git process flow​

1

Перед тем как включить нового разработчика в команду, ему нужно дать право на чтение необходимого репозитория компании на bitbucket\github и сделать fork с которым ему придется работать в разрезе спринта\продуктового цикла разработки. Обязательно задать email в настройках git, который должен совпадать с email на bitbucket\github для однозначной идентификации при выполнении pull request и для получении обратной связи от черного мастера код ревью.  Git-flow в «1С:Предприятие 8»

Если разработка идет по верному пути, нижний слайд понадобиться всего 1 раз.

Git-flow в «1С:Предприятие 8»4567

Позитивные стороны

  • Подход серьёзно уменьшает количество ошибок и недоделок;
  • Только качественные продукты попадут в работающую систему;
  • Такая разработка сводит с ума быдлокодеров;
  • Основные процедуры по обновлению можно планировать;
  • Всегда можно заглянуть в fork разработчика и вместе навалится на противную задачу;
  • Не нужно никого ждать, что кто-то захватил объект в хранилище, каждый работает со своей конфигурацией;
  • Всегда быть в курсе изменений используя интеграцию bitbucket\github с slack\hipchat.

Негативные стороны

  • Сложность внедрения. Без сторонней помощи тяжеловато, как выход вливаться в тусовку https://github.com/xDrivenDevelopment или посещать тематические мероприятия;
  • Как минимум должен быть выстроен правильный процесс разработки (мы используем agile);
  • Придется потратится на SSD для каждого разработчика, «Выгрузить конфигурацию в файлы…» не столь быстро работает как бы хотелось;
  • Конфликты объединения бывают, придется планировать разработку и разделение на task’s, например, форма\модуль объекта\модуль менеджера\модуль команды и т.д. (У нас задач много, последний конфликт был около 2-х месяцев назад)

Вначале упомянул Redmine, так вот, если при commit добавлять «#номер задачи» (из трекера) и настроить интеграцию с bitbucket\github — можно будет прямо из задачи (на трекере) видеть изменения, какие были сделаны для ее решения. Вот несколько скриншотов. К сожалению, все описать детальней нет времени и сил, но начало положено. Надеюсь после статьи в наших рядах (https://github.com/xDrivenDevelopment) появится больше новых людей с новыми идеями.r1r2

От pbazeliuk

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *