EDT + УТ 11.4 + БП 3.0 + Расширения. ЧАСТЬ 03
Групповая разработка в EDT.
- Описание
- Подробнее
Описание
Продолжение 3 предыдущих частей:
EDT 1.16. Первые 20 часов работы
EDT + УТ 11.4 + БП 3.0 + Расширения. ЧАСТЬ 01
EDT + УТ 11.4 + БП 3.0 + Расширения. ЧАСТЬ 02
…в которых я с трудностями, но уверенно продвигался вперёд, несмотря на некоторые грабли. *броня крепка и танки наши быстры
Для первого знакомства) я уже попробовал и пощупал, в принципе, всё, что хотел и всё, что пришло на ум.
*Ну, возможно, ещё надо попробовать развернуть какую-нибудь новую конфигурацию, с использованием БСП 3.1. Чтобы уж окончательно закрыть этот EDT-гештальт.
А в этой части дело, наконец-то, дошло до групповой разработки.
Вводные данные
Платформа 8.3.14.1993 (x86-64)
Конфигурация УТ 11.4.10.94 (демонстрационная база из официальной поставки)
1C:Enterprise Development Tools EDT 1.16
Ноутбук: win10, i7, 8Gb, SSD
Подготовка
Репозиторий
Для начала нам требуется репозиторий.
Для этого надо зарегиться на GitHub и создать новый. Это предельно простая процедура.
После этого, надо скопировать в буфер (Ctrl+C) URL созданного репозитория и открыть EDT.
Подключение Репозитория в EDT
В EDT подключаем этот репозиторий:
Здесь нас ждут какие-то невероятные чудеса юзабилити от разработчиков EDT — если предварительно скопировать в буфер URL репозитория, то в EDT он автоматически подставится в окне настройки. *Они нас балуют — могли бы и как обычно сделать — чтобы только со 2-3 раза могло получиться.
Но нет, всё проходит мега-гладко и репозиторий успешно появляется в списке:
В истории этого репозитория сразу видим 1-ую запись. Круто:
Подключение конфигурации к групповой разработке
Теперь надо подключить к репозиторию нашу конфигурацию:
Всё просто:
Никаких сложностей, долгого ожидания и тому подобного, что уже инстинктивно ожидаешь от EDT.
Когда конфигурация подключится, можно вернуться в репозиторий и на закладке Индексирование Git увидеть, что нас уже ждут изменения, которые можно выгрузить:
Нажимаем кнопку , ждём какое-то время (минут 10, вроде бы, всё-таки всю конфигурацию будем "push’ить") вводим комментарий и отправляем наши изменения в серверный репозиторий:
Начинается фоновый процесс, который мы можем игнорировать и заниматься своими делами в EDT:
Когда отправка завершится, мы увидим (*я это увидел спустя примерно 10-15 минут после начала отправки — по времени норм):
*В GitHub есть ограничения на максимальный размер файла — 100Мб, при размере файла больше 50Мб — просто предупреждение.
Здесь мы его и видим.
На GitHub’е видим результат:
+ пункт в Истории
*Здесь, лично для себя, отметил ещё одну приятность: по привычке, если приходится что-то комментировать в простых текстовых полях, то 1-ой строкой пишу тезис, затем пустую строку и расшифровку.
Как оказалось, Git это дело уважает, рекомендует и автоматически понимает такое форматирование. В окне истории это видно — Название жирной строкой, а комментарий — ниже и мелко.
Выглядит всё понятно и просто.
Но жирная какашка, всё-таки, имеется.
Отправить конфигурацию в хранилище, пардон, репозиторий у меня получилось только с 3-го раза.
При 1-ой попытке, GitHub послал меня с reject’ом:
Оказывается, EDT разбирает всю конфу по косточкам, а файл поставщика оставляет 1 большой лепёхой, которую GitHub отказывается, и правильно делает, принимать. :facepalm:
Ну, логика дальнейших действий понятна (кажется):
- снимаю с поддержки в Конфигураторе *для меня-то, в данном конкретном случае, поддержка не принципиальна;
- импортирую изменения в EDT.
Для репозитория готовы изменения:
Выглядит, так, как будто всё должно получиться. Но нет:
Файл конфигурации поставщика остался.
Возможно, как-то хитро где-то что-то можно/надо щёлкнуть, чтобы помогло, но я уже не хочу тратить время на поиски и просто импортирую конфигурацию "с чистого листа" в новую рабочую область. После этого, проблем не возникало.
Простая доработка
Для примера добавляю в конфигурацию новые объекты и вношу изменения в 1 общий модуль.
*Т.к. ранее включил вот эту настройку:
То теперь кайфую от того, что конфигурация обновляется сама в фоне, а я только нажимаю Принять при необходимости.
Видим изменения:
Отправляем (продолжительность отправки не замерял, но быстро):
Не знаю, по-моему, проще некуда. В привычном Хранилище тыкать больше приходится.
В истории видим линию разработки, автора и т.п.
На GitHub’е, тоже, всё понятно:
До, после, во время отправки в репозиторий, можно сравнивать различные версии, смотреть детально характер изменений и т.п.
Ниже сравнение версий посмотрим в контексте групповой разработки.
Разработка группой
Появился ещё 1 разработчик для нашей конфигурации.
Он создал у себя новую рабочую область и клонировал репозиторий (выше показано, как), который был создан ранее.
Продолжительность этой процедуры для УТ 11.4 ~10-12 минут. Репозиторий на сервере скачивается/копируется в локальный репозиторий.
Далее, импортируем конфигурацию из этого репозитория:
Ждём, пока конфигурация импортируется. ~40 минут. *По времени, как при импорте конфигурации из информационной базы (описано в предыдущих частях).
После завершения импорта, с конфигурацией можно начинать работать.
*ЗАХВАТИТЬ (заблокировать) объекты, как это привычно делается в Конфигураторе при работе с хранилищем, нельзя. Интуитивно при первом использовании ищешь кнопку типа "Захватить в хранилище", но такой нет.
У Git логика другая и проблемы одновременной работы нескольких человек с 1 объектом требуется решать организационно-методологически. Как, в принципе, часто бывает и при работе с Хранилищем. Останавливаться на этом здесь я не стану.
Вносим изменения, отправляем в репозиторий *мелкие изменения по времени — секунды.
История на GitHub’е:
//Небольшое отвлечение на редактор кода
…сидишь ты кодишь, жмёшь как обычно Ctrl+Space, выбираешь подходящий вариант, а редактор кода сам уже и скобки расставил, и запятые, и точку с запятой в конце. Да ещё и сразу предлагает список выбора параметров — успевай только кнопками Вверх/Вниз выбирай, да Enter‘ом подтверждай!
Ну прям хочется всё бросить и сидеть программировать в этой среде)) Рукам приятно, как обогрев руля в машине)))
Бальзам на истерзанную душу нервного программиста
Или вот. Отметил себе тудушечкой место в коде, а программа сама его отметит и слева, как задачу, и справа маркером, чтобы по модулю сориентироваться.
А самое главное — покажет это в списке задач!
Теперь не надо глобальным поиском искать свои "зарубки" на страницах кода.
…а то, что ключи структуры через точку теперь видно, про это я вообще молчу!
Не знаю. Пусть кто-то засирает эту EDT, а мне по кайфу от всех этих мелочей!
…Возвращаемся к групповой разработке
Изменения 2-ой разработчик в серверный репозиторий выгрузил, всё ОК.
1-ый теперь может их загрузить у себя.
Но у 1-го, например, тоже есть какие-то изменения:
Логика Git’а: перед тем, как отправить (push) свои изменения в общий репозиторий, следует сначала получить (pull) изменения из репозитория.
Иначе, EDT не даст отправить свои изменения, Git ругнётся:
Поэтому:
- сначала получаем изменения (pull);
- мониторим полученные изменения и, при необходимости, приводим свои изменения в соответствие с ними;
- отправляем (push).
*Для меня, лично, такая последовательность привычна, т.к. при работе с Хранилищем использую такой же порядок — сначала получаю всё новое их хранилища, смотрю, что там парни наваяли, согласую (при необходимости) с новыми изменениями свои доработки и, затем, с чистой совестью выгружаю их в Хранилище.
Тут же происходит объединение 2 линий разработки. В истории всё красиво визуализируется:
На GitHub’е:
*По времени небольшие изменения синхронизируются быстро, а т.к. это происходит в фоне, то время синхронизации может быть вообще неинтересно — нажал и ушёл по своим делам в другие окна рабочей области.
Можно в истории выбрать строку и посмотреть, какие были сделаны изменения:
*при закрытии окна сравнения, если будет написано ‘No input’, надо щёлкнуть по строке репозитория (хотя, казалось бы, оно же и так выбрано):
Отдельная ветка
2-му разработчику поручили небольшое ТЗ.
Для этого он создал в репозитории отдельную ветку…
…и сделал в ней доработки:
- 10 новых справочников (в каждом по 5 реквизитов и 1 табличной части с 5 реквизитами);
- 10 новых документов (в каждом по 5 реквизитов и 1 табличной части с 5 реквизитами, по 1 форме, 1 коменде и 1 макету);
- 5 новых отчетов;
- 2 новых обработки;
- внес изменения в 3 общих модуля.
*Время, которое затрачивает EDT на подготовку, фиксацию и отправку — секунды.
1-ый разработчик получает новую ветку у себя и сливает её с основной веткой:
Я понятия не имел сколько по времени это будет длиться, но, казалось, что должно быть быстро.
Так и получилось.
Спустя ~10-15 секунд слияние было завершено:
Никаких эксцессов.
В основной ветке и в обновленной конфигурации появляются новые изменения:
В истории и на GitHub’е отображается последнее слияние:
*По времени процесс слияния занял ~10-15 секунд. Затем, в течение ~1 минуты, фоново выполнялись различные процедуры, в т.ч. и обновление конфигурации.
На данный момент, это всё, что хотелось своими чешущимися руками попробовать в 1С:EDT. В нулевом приближении, намеренно оставив методологические вопросы в стороне. Так сказать, взять в руки новый молоток, подержать его и попробовать забить им пару гвоздей.
P.S. Вообще, Git — отдельная большая и интересная тема.
P.P.S. …в Git можно и не без интереса "поиграть". Ссылка на игру.
P.P.P.S. Оставил памятку для установки и первоначальной настройки EDT тут.
Вместо послесловия
- Можно ли работать в EDT? Можно;
- Замена ли это Конфигуратору? Отчасти;
- Всем ли подойдет EDT, как всем подходит Конфигуратор? Нет;
- Есть ли у EDT преимущества перед Конфигуратором? Да;
- Перекрывают ли эти преимущества недостатки EDT и достоинства Конфигуратора? Зависит от целей и методологии использования;
- Стоит ли установить себе EDT и попробовать поработать с ним? Да.