Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Спасибо за подробное описание удобного инструмента.
ps. В последнем подкасте в темах слушателей обсуждался именно этот вопрос. Выводы к которому пришли ведущие: «не так важнО описание коммита как атомарность содержимого коммита» Посыл такой: по дифам можно понять кто и что сделал в интересах какой задачи но для этого коммит должен содержать только изменения конкретной задачи. Плохая практика, по мнению ведущих, решить задачу и поправить еще что то, не относящееся к задаче в одном коммите.
(1)
Согласен.
Для себя давно выработал стратегию коммитов:
1. Или закончил функционал.
2. Или сделанные изменения возможно придется откатить.
Но все равно бывает что-то да подмахну) Особенно когда видишь что вот этот кусок надо исправить. И чтобы не выходить из контекста — приходится исправлять.
Была бы возможность работать только в исходниках — нет проблем. Сделал прямо сейчас отдельную ветку, исправил то, что попалось на глаза. А дальше черрипикнул в рабочую ветку и дальше пилить фичу. Но с 1с пока такой трюк не проходит. У нас, по крайней мере.
(2)
а Вы как с гитом работаете?
У нас такой подход вполне себе работает 🙂
(3) Разработка внешних обработок. Используем precommit1c на oscript.
У нас такой подход вполне себе работает 🙂
(3) А как Вы с гитом работаете? ))
Если через конфигуратор, то не поделитесь последовательностью шагов при начале и завершении работы над фичей?
В частности интересны такие вопросы:
1) Обеспечивается ли как-то блокировка одних и тех же форм/макетов для изменения двумя разработчиками одновременно?
Если обеспечивается, то как?
Если не обеспечивается, то как мерджите формы и макеты?
2) Ведёте ли параллельно работу с хранилищем или только через гит?
3) Обеспечивается ли как-то блокировка корня конфигурации от одновременного добавления объектов в двух разных ветках?
Если да, то как?
Если нет, то как в этом случае мерджите в master/develop две ветки, одновременно изменившие корень?
4) Встречали ли проблемы с тем, что при выгрузке-загрузке конфигурации из репозитория меняются идентификаторы объектов метаданных?
5) Ведётся ли работа на конфигурации, основанной на типовой и находящейся на поддержке исходного поставщика?
Если да, то как организовали работу в этом случае? Все объекты сняты с замка? Как обеспечиваете обновление на новый релиз поставщика?
(4) Ну так черрипикнул, пересобрал обработку и дальше поехал, время на сброку обработки то минимально.
(7) Да. Если не работать с ОФ. А при работе с ОФ, каждая форма эта конфликт. И форм в проекте бывает от много до слишком много.
(8) С ОФ тут конечно печаль беда, не спорю)
(6) Большое спасибо за развёрнутый ответ. Звучит классно и действительно как применимый на практике процесс. Даже пул-реквесты в процесс разработки включили! Это наверняка требует умения и желания работать с git каждого разработчика.
Получается, что в новых версиях платформы проблема с изменением идентификаторов решена, а мерджа форм избегаете на уровне договоренности между разработчиками.
Позвольте ещё один вопрос. Вы работаете с одним репозиторием, в котором исходники конфигурации и расширения разнесены по отдельным каталогам, или с двумя отдельными репозитоиями, отдельно для конфигурации и отдельно для расширения? Не принципиально конечно, но всё же интересно. Кажется, что при отказе от хранилища подход с одним репозиторием был бы удобнее.
По следам статьи из блога Яндекса на Хабре 🙂 Провели эксперимент с использованием этого подхода в комментариях к коммитам. Оправдал себя. Теперь внедряем во всей команде.
(11)
Да, хотелось добавить личного опыта. Потому что ребята из Яндекса очень не любят им делиться.
«По всем рекомендациям надо сделать так» — а как делают сами, редко пишут.
(10)
Триггером было отсуствие (тогда) хранилища для расширений, так же нужно было версионирование обработок, при этом мысль, что с конфой будем работать через хранилище, а с остальным через GIT вызвало отторжение.
К тому же город у нас не крупный и скажем так не всегда можно найти квалифицированного разработчика, за которым не надо следить, а ревью кода можно делать уже постфактум, когда доработка попала в хранилище, либо постоянно залезать в чужие конфигурации, так же прием с несколькими хранилищами который продвигало 1С в статьях на ИТС очень не понравился, особенно когда работал с другими ЯП и знал что вот есть GIT и с ним работать довольно комфортно и там куча плюшек вместе с ним приходит.
А разрабы кстати не особо восприняли такую идею, довольно сложно иногда тру 1Снику объяснить про все эти CI GITы тесты и тд, но за несколько скайп конференций я донес до них полезность перехода на GIT, особенно все в восторге о того, что не надо писать идти звонить другому разрабу с просьбой «осободи мне МД Х и Y»
Кстати Валерий вроде из BIA tech выступал на последней инфоконфе, вот его история почти как у нас, только размеры команд разные, даже порог входа ~7 дней, про которые он говорил у нас повторяются.
ЗЫ. Спасибо за статьи по Ванессе, мы как раз через ваши статьи сейчас основы тестирования до разрабов доносим)
да у нас «монорепозиторий», и конфа и расширения и обработки все по разным папкам лежит
(10) Добрый день! Владимир Литвиненко, как можно с вами связаться?
Добрый день, подскажите, пожалуйста, совет, рекомендацию, личный опыт при разработке с использованием git и precommit1c.
Например, ведется разработка внешней обработки, относительно последнего коммита были внесены изменения, но вдруг разработчика отвлекают, и он переключается на другую задачу. Когда он возвращается к свой первоначальной разработке, было бы удобно с помощью любимого приложения (sourcetree и т.д.) посмотреть внесенные изменения относительно последнего коммита. Я понимаю, что можно вручную запустить precommit1c и увидеть необходимый результат. Но очень хочется, чтобы не приходилось выполнять ручных операций.
Также очень хочется до помещения коммита видеть различия для дополнительного контроля помещаемых изменений, а precommit1c разбирает обработку на исходники, только при помещении коммита в репозиторий.
У кого какие практики?
(15) Для начала — с какими формами работаете: ОФ или УФ?
Если УФ то вполне можно работать с исходниками (Файл-Сохранить как-Внешняя обработка в XML формате). Тогда все изменения будут отражены сразу в читаемом виде. Ну или работать в EDT.
Если ОФ — то пока без альтернатив.
Как делаю сам. Если не закоммитил изменения и не помню что это — делаю коммит! )) Только надо отучится от практики — коммит и пуш. Тогда можно отменить ненужные изменения.
Дальше. В sourcetree есть механизм CustomAction — можно добавлять свои скрипты. Так проще вызывать разбор файла, чем лезть в консоль каждый раз.
Я перешел с SourceTree на SmartGit. В SmartGit на Custom actions можно установить комбинации клавиш. В ближайшем будущем есть желание перейти на работу только с исходниками.
Поработал, вызвал скрипт разбора, зафиксировал то что нужно. После смены ветки — вызвал скрипт сборки.
(16) Спасибо за развернутый ответ. Разработка на УФ. CustomAction — неплохой вариант, и думаю потихоньку можно уже двигаться в сторону EDT.
(17)у меня было дикое отторжение от edt. Но поставил 10 версию, действительно хорошо оптимизирована. Заставил себя неделю поработать и привык, есть много интересных фишек, которых теперь недостает в конфигураторе
(18)Вот ещё один вопрос, который меня мучает: при разработке внешней обработке хранить в репозитории саму обработку или хранить только ее стабильные версии как релизы?
С одной стороны во всех репозиториях программ на других языках, которые я видел, нет бинарных файлов, они прикладываются как релизы. Но с другой стороны, гораздо удобнее в каждом коммите уже иметь готовую для использования обработку.
(19) Пока храним обработки во всех коммитах. За 2500 коммитов размер репозитория вырос до 1,5 Гб. Но мы работаем и с ОФ.
В ближайших планах перейти на хранение только кодов. Ничто не мешает пересобирать обработку после смены ветки. Или можете хук на checkout повесить, чтобы сразу собирал
(6) Спасибо за статью и пояснения! Есть небольшой вопрос по рабочему процессу, поясните пожалуйста:
1) Чтобы перейти из пункта 2 в пункт 3 пользуетесь стандартной выгрузкой конфигурации в файлы? А дальше уже коммит этих файлов и ПР?
2) При выполнении пункта 1 делаете апдейт своей локальной ветки из удаленного репозитория, а потом изменения как попадают в конфигурацию? Так же загрузкой конфигурации из файлов?
(21) Не за что, только статья не моя)
Да, синхронизация GIT <> конфа происходит, через выгрузку загрузку XML, по факту это делается не из самого конфигуратора (да и загрузить из конфигуратора мы не сможем ибо конфа на поддержке), а скриптами из source tree.
Отсюда и особенности процесса, что обновляем из апстрима по утрам, т.к. операция долгая довольно и по мимо сборки и загрузки CF еще делается бэкап текущего состояния конфы, т.к. некоторые люди у нас (в том числе и я) забывали выгрузить изменения и затирали кучу работы пару раз 🙂
Ну и уже ребята со скиллом и пониманием гита, делают несколько фич сразу (если они небольшие), а потом раскидывают нужное по коммитам, т.к. выгрузка бывает тоже не быстрой, особенно когда еще не создан ConfigDumpInfo (он удаляется после загрузки конфы из гита, и в целом находится в гитигноре), ну либо сразу правят исходники через VS Code
(20) Хук скорее перебором будет, особенно если надо просто перейти на ветку для каких-то действий относящихся к гиту непосредственно, обработки и так собираются довольно быстро, так же можно сделать проверку хешей файлов, на предмет того, что обработку надо действительно пересобрать, мы в общем то так и сделали, работает отлично)
(22) Спасибо за пояснения. Правильно понимаю, что запускаете скрипт из sourcetree, который обновляет файлы локального репозитория из удаленного, затем из этих файлов собирает cf, и далее этот cf натягивается на конфигурацию разработчика? Предварительно делая бэкап конфигурации разработчика.
(24) да, все так 🙂
скрипт банальный что то типа
git fetch upstream && git rebase upstream/develop && git push —force && oscript tools/git/main.os -update
(6)
Жесть! А можете подсказать, в чём преимущество такого подхода по сравнению со стандартным хранилищем? Если честно, после того как поработал с гит в 1С и после вашего описания пока впечатление «гит ради гита». Не проще сделать хранилище 1С, программистам работать с хранилищем, потом для дженкинсов и прочих авторабот выгружать уже в файлы и дальше по сценарию? В результате — программисты работают с нормальным хранилищем, не нужны никакие договорённости, не нужен специально обученный человек для мёрджей и прочего контроля, не нужно решать кучу проблем на уровне неприспособленности платформы (прыгающие свойства, идентификаторы и т.п., не факт, что в новой платформе не прилетит чего-то нового-интересного).
(26) мы перешли ради код ревью и блейма, хотя блейм в через гитсинк можно получить с хранилищем. Но вот код ревью — нет, плюс блокировки МД достали, а возня с несколькими хранилищами вызвала дикое отторжение, т.к. некоторые кейсы вот вообще не как не воспроизвести.
Например когда 2 разраба, пилят фичи, которые потом нужны другому, через гит это решается банальным черри пиком, с хранилищами уже не как. Писать можно много, главное скажу, что наши разрабы не страдают, все банально просто, не сложнее понимания работы с хранилищем, а для продвинутых разрабов открываются большие возможности и это для нас жирный «+».
ЗЫ Воркфлоу может и жестью показаться, но он довольно простой.
это не баг, а фича, это касается ConfigDumpInfo, а он актуален только для конкретного состояния ИБ и должен быть в гитигноре, какой нибуть node_modules тоже всегда в гитигноре, не кто ж не ноет, что там что-то меняется))
В целом с 10 платформы уже все довольно стабильно, очень редко всплывают баги
(27)
В каком смысле? У вас два программиста одну форму параллельно пилят??
Хотя нет, вот же вы пишите:
О каких блокировках вы говорите?
Для код ревью, опять же, элементарно, есть хранилище, есть отдельная рабочая, при сравнении-объединении всё это видно, причём в удобном, разработанном для 1С виде, а не в текстовых файлах или, упаси боже, в консоли.
Я ездил на отдых в ОАЭ, страну из топ 3 самого дорогого интернета в мире, поэтому работать через удалённый рабстол было невозможно. Соответственно, точно также, сделал гит-хранилище, выгружал туда изменения, загружал на битбакет, забирал локально, работал, потом в обратную сторону. Трафик я, конечно, сэкономил, цель была достигнута, не пришлось выгружать-загружать каждый раз гиговый цф. Но в остальном я проклял гит, 1С и всех адептов гита в 1С. Потому что выгрузка конфы в файлы занимает Ж = «жесть сколько времени», гит статус, гит адд, гит коммит занимают каждый по Ж времени (на каждой стороне!), на принимающей стороне должна быть развёрнута отдельная база, которая загружается (за Ж времени) из файлов, потом оттуда выгружается цф и объединяется с целевой базой на той стороне. Да, кстати, на моей стороне тоже была отдельная база для заливки из файлов, потому что тоже на поддержке.
И эффективность всего этого алгоритма — Ж большое! Прям огромное. Поэтому для работы с гитом вместо хранилища должны быть реальные основания. У вас, насколько я понимаю, примерно такое же Ж времени уходит на все танцы с гитом. При этом система — «все работают в хранилище 1С, кодревью происходит при заливке в рабочую» — просто таки в разы быстрее. Да, для всяких дженкинсов надо в файлы, но это можно действительно ночью без пользователя делать. А в работе программиста — я, если честно, так и не понял, какой выигрыш вы получили?
(29)
Вы бы статью написали с вашим случаем, с картинками, командами, инструментарием и т.п. Я думаю, не только мне было бы интересно. Потому что я сейчас с гитом работаю только по внешним обработкам, по полной конфе (это была БП!) было Ж большое. Сейчас уже точно не вспомню, но очень приблизительно половина цикла (перенести из одной базы изменения в другую) занимало от получаса до полутора. Т.е. я утром запускал этот процесс, и также занимался своими делами, ходил на завтрак и т.п. Так вот, кто-то из команды вдруг что-то критичное менял и выкладывал в течение дня, мне было проще или код с экрана у себя переписать, или из выгрузки выдернуть файлы, которые изменены и через файловой хостинг перекинуть к себе.
(26) думал об этом не раз, ибо подобный разбор полётов веду не первый раз, наверное в ближайшем будущем сделаю это уже)
(31)
Буду ждать, потому что сам бы хотел применить в некоторых местах гит, но пока что этот печальный опыт не особо обнадёживает.
(19)
Всегда же можно откатиться и собрать из файлов. Для получения готовой обработки определённой версии всё равно нужно откатиться, так что действия всё равно одни и те же (пару кликов добавляется), а размер страдает очень сильно.
Мы раньше хранили в двух хранилищах отдельно — в одном обработка, в другой её выгрузка. В результате выгрузка занимает копейки, а хранилище с обработкой пухнет. В результате первое забросили, только выгрузку храним. Надо будет получить историческую версию — откатимся, сделаем.
(20), (23) — я думаю, вам можно написать статью (или цикл) с полным разбором от «Что такое гит» до «Хуки-блеймы-полный цикл». И рейтинга наберёте, и денег с инфостарта срубите, и карму поднимите)
Интересный инструмент, но работает только в консоли виндовс. В git bash виделение цветом не происходит, но выбор стрелками происходит. Это только у меня так?