Перед прочтением желательно ознакомиться с предыдущими статьями: Как мы управляем версиями (GIT+1C), Как мы управляем версиями и тестированием 1C 8.3 (часть 2)
Разработка качественных продуктов для 1С:Предприятие 8 довольно большая проблема. Для начинающих программистов и специалистов средней руки вопрос не стоит так остро, они не отвечают за работу огромных, высоконагруженных, сложных и нестандартных механизмов, где иногда часы простоя стоят огромных денег. Естественно все это создается не одним человеком и не за один день, когда случается переход от простых задач к глобальным и цена ошибки велика, вот в этот момент возникают вопросы взаимозаменяемости специалистов, совместное владение кодом и даже просто владение, регистрация и учет изменений, сроки реализации функционала, тестирование, списки приемных тестов и т. п.
Что же мы имеем в 1С |
Чего же все-таки хочется |
Хранилище конфигурации:
|
|
УСТАНОВКА 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 - использование кодовой базы проекта для старта нового или доработки с последующий объединением;
- commit - принять и сохранить последние изменения в репозиторий (хранилище);
- pепозиторий - место, где хранятся и поддерживаются какие-либо данные;
- push - отправить\обновить новые или измененные объекты в удалённый репозиторий;
- pull - получить\обновить новые или измененные объекты из удалённого репозитория;
- push 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.
Перед тем как включить нового разработчика в команду, ему нужно дать право на чтение необходимого репозитория компании на bitbucket\github и сделать fork с которым ему придется работать в разрезе спринта\продуктового цикла разработки. Обязательно задать e-mail в настройках git, который должен совпадать с e-mail на bitbucket\github для однозначной идентификации при выполнении pull request и для получении обратной связи от черного мастера код ревью.
Если разработка идет по верному пути, нижний слайд понадобится всего 1 раз.
Позитивные стороны
- Подход серьёзно уменьшает количество ошибок и недоделок;
- Только качественные продукты попадут в работающую систему;
- Такая разработка сводит с ума "быдло-кодеров";
- Основные процедуры по обновлению можно планировать;
- Всегда можно заглянуть в fork разработчика и вместе навалится на противную задачу;
- Не нужно никого ждать, что кто-то захватил объект в хранилище, каждый работает со своей конфигурацией;
- Всегда быть в курсе изменений используя интеграцию bitbucket\github с slack\hipchat (статья про slack).
Негативные стороны
- Сложность внедрения. Без сторонней помощи тяжеловато, как выход вливаться в тусовку или посещать тематические мероприятия;
- Как минимум должен быть выстроен правильный процесс разработки (мы используем agile, чуток о нашем процессе);
- Придется потратится на SSD для каждого разработчика, "Выгрузить конфигурацию в файлы..." не столь быстро работает как бы хотелось;
- Конфликты объединения бывают, придется планировать разработку и разделение на task's, например, форма\модуль объекта\модуль менеджера\модуль команды и т. п. (У нас задач много, последний конфликт был около 2-х месяцев назад)
Вначале упомянул Redmine, так вот, если при commit добавлять "#номер задачи" (из трекера) и настроить интеграцию с bitbucket\github - можно будет прямо из задачи (на трекере) видеть изменения, какие были сделаны для ее решения. Вот несколько скриншотов. К сожалению, все описать детальней нет времени и сил, но начало положено. Надеюсь после статьи в наших рядах появится больше новых людей с новыми идеями.
