Статья является переосмыслением и дополнением к предыдущим трудам «Управляем версиями в «1C:Предприятие 8» (Git)» и «Управляем версиями и тестированием «1C:Предприятие 8» (Git, часть 2)». Как оказалось, многие не понимают зачем такие сложности и почему? Попытаюсь ответить на эти вопросы и описать подход git-flow.
Разработка качественных продуктов для «1С:Предприятие 8» довольно большая проблема. Для начинающих программистов и специалистов средней руки вопрос не стоит так остро, они не отвечают за работу огромных, высоконагруженных, сложных и нестандартных механизмов, где иногда часы простоя стоят огромных денег. Естественно все это создается не одним человеком и не за один день, когда случается переход от простых задач к глобальным и цена ошибки велика, вот в этот момент возникают вопросы взаимозаменяемости специалистов, совместное владение кодом и даже просто владение, регистрация и учет изменений, сроки реализации функционала, тестирование, списки приемных тестов и т.д.
Что же мы имеем в «1С:Предприятие 8»
Хранилище конфигурации:
- довольно спорный инструмент (в моем опыте несколько раз хранилище становилось полностью не рабочим);
- совместное удобство работы сомнительное;
- выполнить привязку к трекеру задач нельзя;
- код ревью делать не удобно, да и отметить спорные изменения нельзя;
- нет понятий release, hotfix, feature;
- и многое-многое другое;
- хорошо описано здесь.
Чего же всё-таки хочется
- выполнять изменения без захвата объектов;
- при попытки внесения изменений, их должен принять человек с черным поясом по код ревью;
- каждый разработчик работает независимо от того, что делает другой программист;
- возможность использовать ветвления и выпускать продукт из комбинации удачных веток;
- при закрытии задачи в системе разработки, изменения кода можно просмотреть в трекере задач;
- комментирование построчно кода с оповещением человека, который пытается поместить изменения.
Установка Git
Git берем отсюда http://git-scm.com/download. С установкой не должно возникнуть проблем. Как пользоваться Git можно прочесть здесь.
Что такое контроль версий, и зачем он вам нужен?
Система контроля версий (СКВ) — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов.
Выбираем BITBUCKET.ORG или GITHUB.COM
Регистрируемся в системе для бесплатного хостинга вашего кода. Выделить один из сервисов сложно, мы используем оба. Регистрация довольно простая, да и все вопросы настроек уже описаны сотни раз в интернете.
Что выбрать, и зачем это нужно?
Сервисы позволяют провести код ревью, выполнить объединение, синхронизацию, оповестить трекер задач об изменениях по определенной задаче, выслать извещение участникам проекта и т.д. В каждом сервисе есть свои плюсы и минусы — выбор остаётся за вами.
Необходимые вещи
Хранить в Git бинарные файлы можно, но практической пользы от этого мало, их нужно распаковать в текстовые файлы понятные простому обывателю. С конфигурацией сделать это просто с помощью команды «Выгрузить конфигурацию в файлы…». С внешними обработками и отчетами это сделать сложнее, на помощь приходит сообщество c инструментами V8Commit или precommit1C, последний умеет собирать внешние обработки и отчеты из файлов.
Что выбрать?
Сейчас precommit1C активно развивается и дорабатывается, по моему, выбор очевиден. V8Commit развивается «закрыто» и пока не ясно под какой лицензией будет распространяться в дальнейшем, так же нужно обязательно в commit включать бинарные файлы (*.epf, *.erf).
Когда осилены предыдущие пункты
Примерный результат будет таков (в данном примере bitbucket.org):
К каждой строчке можно оставить комментарий, этот текст придет участникам проекта на почту (можно перенастроить), если это 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
Перед тем как включить нового разработчика в команду, ему нужно дать право на чтение необходимого репозитория компании на bitbucket\github и сделать fork с которым ему придется работать в разрезе спринта\продуктового цикла разработки. Обязательно задать email в настройках git, который должен совпадать с email на bitbucket\github для однозначной идентификации при выполнении pull request и для получении обратной связи от черного мастера код ревью. 
Если разработка идет по верному пути, нижний слайд понадобиться всего 1 раз.
Позитивные стороны
- Подход серьёзно уменьшает количество ошибок и недоделок;
- Только качественные продукты попадут в работающую систему;
- Такая разработка сводит с ума быдлокодеров;
- Основные процедуры по обновлению можно планировать;
- Всегда можно заглянуть в fork разработчика и вместе навалится на противную задачу;
- Не нужно никого ждать, что кто-то захватил объект в хранилище, каждый работает со своей конфигурацией;
- Всегда быть в курсе изменений используя интеграцию bitbucket\github с slack\hipchat.
Негативные стороны
- Сложность внедрения. Без сторонней помощи тяжеловато, как выход вливаться в тусовку https://github.com/xDrivenDevelopment или посещать тематические мероприятия;
- Как минимум должен быть выстроен правильный процесс разработки (мы используем agile);
- Придется потратится на SSD для каждого разработчика, «Выгрузить конфигурацию в файлы…» не столь быстро работает как бы хотелось;
- Конфликты объединения бывают, придется планировать разработку и разделение на task’s, например, форма\модуль объекта\модуль менеджера\модуль команды и т.д. (У нас задач много, последний конфликт был около 2-х месяцев назад)
Вначале упомянул Redmine, так вот, если при commit добавлять «#номер задачи» (из трекера) и настроить интеграцию с bitbucket\github — можно будет прямо из задачи (на трекере) видеть изменения, какие были сделаны для ее решения. Вот несколько скриншотов. К сожалению, все описать детальней нет времени и сил, но начало положено. Надеюсь после статьи в наших рядах (https://github.com/xDrivenDevelopment) появится больше новых людей с новыми идеями.
