Использование git для доработки типовых конфигураций 1С

Очень познавательно.
Я периодически натыкаюсь на статьи по TDD и BDD, но системного восприятия все равно нет и это мешает в полной мере оценить мощь этого подхода.

Автор, подскажите с чего по порядку можно начать изучение этой темы?
Например, как развернуть и настроить окружение (git+"черепаха"+Vanessa+1C) для разработки/доработки по описанной вами методике?
что такое Vanessa-behavior, feature файлы и как научиться с этим управляться?
может ссылки есть наготове?

Спасибо.

(1) Makushimo, ИМХО, начать лучше с изучения git и начала работы с ним. Так как это система версионирования, то она требует внимания. Затем начать курить мануалы по работе с docker и vagrant - они помогут быстро без особых усилий разворачивать рабочие пространства, которые будут требоваться в работе над разными проектами, дабы не засорять основную операционную систему.
После этого можно приступить к изучению методологий TDD и BDD.
Часто в личных разработках или на фрилансе методологии эти сложно применить, хорошо сработают работе в команде. ПОсле того как будет постигнут начальный уровень дзен разработки по промышленным стандартам можно начать изучать системы автосборок, скриптописания. Что касается Vanessa-behavior - это опенсорц фреймворк для автотестирования с написание БТ на языке геркин вот тут подробнее https://github.com/silverbulleters/vanessa-behavior

Женя, это шикарная статья)

(1) Makushimo, извините, но я не смогу вам ответить в полной мере, т.к. ссылки не храню, а доверяю их гуглу.
Как минимум на infostart есть пару статей обзорных http://infostart.ru/public/all/?public-filter%5Bsearch%5D=bdd
Есть даже курсы по обучению, насколько я знаю Никита Грызлов как раз готовит такой по непрерывной интеграции и научит вас готовить jenkins.
Могу только посоветовать гуглить precommit1c, vanessa-behavior (посмотреть вебинары Леонида Паутова по использованию инструментария), учить базовые понятия git и присматриваться к jenkins - это тот стек, который я использую.

На скриншоте http://infostart.ru/upload/iblock/a6a/a6aa74bb9c366c17ce7c579f005f2a37.png
процедура ЯОткрываюФормуСоСвойствомИЗначениемИСохраняюВКонтекст. Хотя по предыдущему рисунку там только Дано: я открываю форму "...ФормаДокумента" и сохраняю в контекст

(4) kraynev-navi, для уменьшения скрина я просто не включил эту процедуру, по факту она вызывает ЯОткрываюФормуСоСвойствомИЗначениемИСохраняюВКонтест, это можно посмотреть в самом файле patch https://github.com/pumbaEO/eprpatch/blob/master/patch/0004-optimize.patch#L775

А где про него прочитать?


А как с точки зрения безопасности посмотреть на хранение данных к этой учетной записи?
Предположим нехороший человек внутри компании может узреть логин-пароль какой-нибудь "всевидящей" роли и просто похаживать под ней, посматривая на запрещенные для его статуса данные. Как-то ограничивать, наверное, надо? Какая здесь практика?

(6) kraynev-navi, https://github.com/silverbulleters/vanessa-behavior/blob/develop/features/Core/FeatureLoad/%D0%97%D0%B0­%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0%D0%A4%D0%B8%D1%87%D0%9F­%D0%BE%D0%A2%D0%B5%D0%B3%D0%B0%D0%BC.feature
это просто теги, по которым в дальнейшем можно отфильтровать те feature которые хочешь запустить в определенный момент.


Использовать не рабочую базу, а если хотите использовать копию рабочей, то сделать простейшую обработку, которая сбросит пароли пользователям после копирования, а для БСП конфигураций, вам еще необходимо установить прокси на несуществующий или mock (soapUI) адрес, установить признак, что это копия информационной базы и т.д.

(6) kraynev-navi, фиче-файлы прогоняются на пустой минимально заполненной базы. Никакой пользы от демо-доступа в приемочную базу да ещё и на изолированном ci-контуре у злоумышленника не будет.

(7)(8) Да я ужо понял, что ерунду по утру спросил

(0)
1. Политика веток/меток чересчур упрощенная, если она точно такая же в боевой работе, то это не гуд.
2. Я правильно понимаю, что механизм поставки от 1С при этом выкидывается? Само по себе это нормально, пока итоговое решение на поставке одной конфы, но 2 конфигурации поставщика ваша схема без доработки не прожуёт. Про механизм расширений - не знаю, не могу сходу применимость оценить.
3. Самая вкусная тема механизма поставки - видеть одновременно старую конфигурацию поставщика, наши изменения относительно неё и новую конфигурацию. Собственно, задача "внести свои изменения в типовую, чтобы я всегда мог их видеть и идентифицировать" нормально решается и gitом, и поставкой - это лёгкий кейс. Кейс, который реально проверяет методику - "мы тут командой написали кучу кода для 1.2.3.4, а вчера 1С выпустила 1.2.4.5 и нам надо на неё быстро-быстро переезжать, потому что регуляторные требования". Сразу скажу, что "мега-черри-пик" хорошей идеей не выглядит :)
4. Еще одна печаль для git - сравнение табличных документов, графических схем и прочей подобной ерунды. Если формы еще как-то сравнибельны, то табличные документы....

В задаче "с 1.2.3.4 на 1.2.4.5" git тоже поможет, но совесем по-другому. Например, не надо будет выполнять трёхстороннее сравнение без права на промежуточные сохранения (ага, я протычивал тыщи галочек при обновлении УПП, еще помню, больше не хочу).

(10) speshuric,

Да на практике, конечно их больше, но это уже зависит от моих "извращений", есть ветки висящие мертвым грузом. Но стараюсь придерживаться: master - то что в продакшине, develop - в разработке, ну и куча feature/* от hotfix пока профита не получил, чаще проще было на develop обновится, она более или менее стабильна всегда.

Да, сознательно выкидываю и в репозиториях прописываю в gitignore *.cf и Parent*.bin, т.к. нет нормального механизма описания поставки и только лишнее место занимают. При этом для разработчика выдается обязательно *.dt файл, в котором как раз и есть актуальный срез конфигурации с конфигурацией поставщика, что-бы видеть замочки.
С расширениями тема пока вызывает вопросы, т.к. неизвестно как их сравнивать, как документировать и насколько может поменяться логика работы конфигурации после незначительного обновления, при этом забыли проверить расширение не переопределялся ли там модуль и т.д., пока проблем больше чем вариантов решений. И если с изменением конфигурации это можно выявить хоть примерно на этапе сравнения, то с расширением - беда.
не рассматривали не мега коммит "Обновление типовой на 1.2.4.5" от имени 1C, а несколько коммитов по подсистемам и потом merge в origin1c, тогда можно как черри-пик, так и мелкий merge сделать (имхо в таком варианте merge будет предпочтительней с включенным модулем rere)


просил у 1C xsd схемы для таких метаданных, но они сказали "в планах публикации такого нет", поэтому вскоре попробую сам создать пару примеров и попытаю счастья с merge EMF пакетов в Eclipse, возможно будет хорошее решение.
Для форм и предопредленных данных или метаданных помогает xmldiff консольная утилита, т.к. чаще всего это добавление в дерево нового узла.

(0) Отличная практическая статья, давно такой не хватало! Подписываюсь на комментарии :)

На такие статья нужно подписываться в обязательном порядке!

Переопубликовал где только мог. Фундаментально!

Хорошая статья, спасибо, заинтересовало.

(15) necropunk, что именно git или тесты или и то и другое?

(16) pumbaE, с тестами вообще круть, но для меня пока недосягаемо. Работа с git впечатлило, тут пока папку разработки внешних обработок через OneScript к Git подключил - семь потов сошло, в статье вообще высший пилотаж, конечно...

А если серьезно, то давно пора взяться за изучение.

pumbaE, ты все-таки добил 1С своими патчами: https://wonderland.v8.1c.ru/blog/inkrementalnaya-vygruzka-konfiguratsii-v-xml/
Осталось дождаться 8.3.11 (

Вот тут интересней ;-) https://partners.v8.1c.ru/forum/t/1536592/m/1536647

А мне вот интересно как вы поступали с переименованиями. К примеру, переименовали справочник из НенужныйСправочник в УдалитьНенужныйСправочник или форму или ещё что-нибудь. Как с этим быть?
Если в типовой конфигурации это в 90% будут переименования с добавлением приставки Удалить, то в моей разработке при рефакторинге бывают совершенно другие переименования. Я просто не знаю, что с ними делать, чтобы сохранялась их история. Вручную про них незабывать совершенно нереально.
И если в каком-нибудь старом коммите обнаружил, что переименование прошло как удаление и добавление, можно ли как-нибудь ручным приводом этот старый коммит исправить, чтобы всё встало на свои места?

(21) sashocq, обычно git сам определяет, что это переименование файла или каталога, конечно если вы не будете сильно менять содержимое файлов, но есть и ручная команда git mv староеИмя новоеИмя.
Если вам необходимо исправить историю, то тут только checkout на этот коммит, исправление и потом последующий rebase.

Не могли бы пояснить: как я понимаю для интеграции с репозиторием используется стандартный функционал конфигуратора по выгрузке (/загрузке) конфигурации в файлы xml.
А готов ли этот механизм для того чтобы заменить хранилище git-ом? Для примера, выгрузил cf из УТ11, потом выгрузил в файлы и собрал из них новый cf-ник (попутно получил предупреждения о каких-то картинках).
Итого:
1. Разница в размере cf - примерно 5Мб.
2. Если сравнить получившуюся конфу с cf, обнаруживаются различия в ряде обработок и нескольких документа (различия правда отображаются пустыми).

(23) очень полезно:

* выгрузить УТ11 в git
* закомитить
* загрузить конфигурацию из git
* выгрузить после этого еще раз выгрузить конфигурацию в git
* сделать git diff
* офигеть ;-)
и пойти смотреть https://github.com/pumbaEO/undiff1c

(24) Спасибо за наводку. Однако, если закоммитить, загрузить и выгрузить снова - "nothing to commit, working tree clean"

(1) и не более. все это перекрывается одним костылем, следовательно малопригодно для практического применения

Евгений, а не поделитесь "простейшим скриптом" который помогает сделать необходимый нам mergeSetting из патча git? ;)
Спасибо за статью!