Комментарии
Избранное
Подписка
Сортировка:
Древо
Очень познавательно.
Я периодически натыкаюсь на статьи по TDD и BDD, но системного восприятия все равно нет и это мешает в полной мере оценить мощь этого подхода.
Автор, подскажите с чего по порядку можно начать изучение этой темы?
Например, как развернуть и настроить окружение (git+"черепаха"+Vanessa+1C) для разработки/доработки по описанной вами методике?
что такое Vanessa-behavior, feature файлы и как научиться с этим управляться?
может ссылки есть наготове?
Спасибо.
Я периодически натыкаюсь на статьи по TDD и BDD, но системного восприятия все равно нет и это мешает в полной мере оценить мощь этого подхода.
Автор, подскажите с чего по порядку можно начать изучение этой темы?
Например, как развернуть и настроить окружение (git+"черепаха"+Vanessa+1C) для разработки/доработки по описанной вами методике?
что такое Vanessa-behavior, feature файлы и как научиться с этим управляться?
может ссылки есть наготове?
Спасибо.
(1) Makushimo, ИМХО, начать лучше с изучения git и начала работы с ним. Так как это система версионирования, то она требует внимания. Затем начать курить мануалы по работе с docker и vagrant - они помогут быстро без особых усилий разворачивать рабочие пространства, которые будут требоваться в работе над разными проектами, дабы не засорять основную операционную систему.
После этого можно приступить к изучению методологий TDD и BDD.
Часто в личных разработках или на фрилансе методологии эти сложно применить, хорошо сработают работе в команде. ПОсле того как будет постигнут начальный уровень дзен разработки по промышленным стандартам можно начать изучать системы автосборок, скриптописания. Что касается Vanessa-behavior - это опенсорц фреймворк для автотестирования с написание БТ на языке геркин вот тут подробнее
Женя, это шикарная статья)
После этого можно приступить к изучению методологий TDD и BDD.
Часто в личных разработках или на фрилансе методологии эти сложно применить, хорошо сработают работе в команде. ПОсле того как будет постигнут начальный уровень дзен разработки по промышленным стандартам можно начать изучать системы автосборок, скриптописания. Что касается Vanessa-behavior - это опенсорц фреймворк для автотестирования с написание БТ на языке геркин вот тут подробнее
Женя, это шикарная статья)
Прикрепленные файлы:
(1) Makushimo, извините, но я не смогу вам ответить в полной мере, т.к. ссылки не храню, а доверяю их гуглу.
Как минимум на infostart есть пару статей обзорных
Есть даже курсы по обучению, насколько я знаю Никита Грызлов как раз готовит такой по непрерывной интеграции и научит вас готовить jenkins.
Могу только посоветовать гуглить precommit1c, vanessa-behavior (посмотреть вебинары Леонида Паутова по использованию инструментария), учить базовые понятия git и присматриваться к jenkins - это тот стек, который я использую.
Как минимум на infostart есть пару статей обзорных
Есть даже курсы по обучению, насколько я знаю Никита Грызлов как раз готовит такой по непрерывной интеграции и научит вас готовить jenkins.
Могу только посоветовать гуглить precommit1c, vanessa-behavior (посмотреть вебинары Леонида Паутова по использованию инструментария), учить базовые понятия git и присматриваться к jenkins - это тот стек, который я использую.
@updatetest
А где про него прочитать?
"Закупки (КоролевСВ)" и паролем ""
А как с точки зрения безопасности посмотреть на хранение данных к этой учетной записи?
Предположим нехороший человек внутри компании может узреть логин-пароль какой-нибудь "всевидящей" роли и просто похаживать под ней, посматривая на запрещенные для его статуса данные. Как-то ограничивать, наверное, надо? Какая здесь практика?
(6) kraynev-navi,
это просто теги, по которым в дальнейшем можно отфильтровать те feature которые хочешь запустить в определенный момент.
Использовать не рабочую базу, а если хотите использовать копию рабочей, то сделать простейшую обработку, которая сбросит пароли пользователям после копирования, а для БСП конфигураций, вам еще необходимо установить прокси на несуществующий или mock (soapUI) адрес, установить признак, что это копия информационной базы и т.д.
это просто теги, по которым в дальнейшем можно отфильтровать те feature которые хочешь запустить в определенный момент.
А как с точки зрения безопасности посмотреть на хранение данных к этой учетной записи?
Использовать не рабочую базу, а если хотите использовать копию рабочей, то сделать простейшую обработку, которая сбросит пароли пользователям после копирования, а для БСП конфигураций, вам еще необходимо установить прокси на несуществующий или mock (soapUI) адрес, установить признак, что это копия информационной базы и т.д.
(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 тоже поможет, но совесем по-другому. Например, не надо будет выполнять трёхстороннее сравнение без права на промежуточные сохранения (ага, я протычивал тыщи галочек при обновлении УПП, еще помню, больше не хочу).
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 файл, в котором как раз и есть актуальный срез конфигурации с конфигурацией поставщика, что-бы видеть замочки.
С расширениями тема пока вызывает вопросы, т.к. неизвестно как их сравнивать, как документировать и насколько может поменяться логика работы конфигурации после незначительного обновления, при этом забыли проверить расширение не переопределялся ли там модуль и т.д., пока проблем больше чем вариантов решений. И если с изменением конфигурации это можно выявить хоть примерно на этапе сравнения, то с расширением - беда.
просил у 1C xsd схемы для таких метаданных, но они сказали "в планах публикации такого нет", поэтому вскоре попробую сам создать пару примеров и попытаю счастья с merge EMF пакетов в Eclipse, возможно будет хорошее решение.
Для форм и предопредленных данных или метаданных помогает xmldiff консольная утилита, т.к. чаще всего это добавление в дерево нового узла.
1. Политика веток/меток чересчур упрощенная, если она точно такая же в боевой работе, то это не гуд.
Да на практике, конечно их больше, но это уже зависит от моих "извращений", есть ветки висящие мертвым грузом. Но стараюсь придерживаться: master - то что в продакшине, develop - в разработке, ну и куча feature/* от hotfix пока профита не получил, чаще проще было на develop обновится, она более или менее стабильна всегда.
2. Я правильно понимаю, что механизм поставки от 1С при этом выкидывается? Само по себе это нормально, пока итоговое решение на поставке одной конфы, но 2 конфигурации поставщика ваша схема без доработки не прожуёт. Про механизм расширений - не знаю, не могу сходу применимость оценить.
Да, сознательно выкидываю и в репозиториях прописываю в gitignore *.cf и Parent*.bin, т.к. нет нормального механизма описания поставки и только лишнее место занимают. При этом для разработчика выдается обязательно *.dt файл, в котором как раз и есть актуальный срез конфигурации с конфигурацией поставщика, что-бы видеть замочки.
С расширениями тема пока вызывает вопросы, т.к. неизвестно как их сравнивать, как документировать и насколько может поменяться логика работы конфигурации после незначительного обновления, при этом забыли проверить расширение не переопределялся ли там модуль и т.д., пока проблем больше чем вариантов решений. И если с изменением конфигурации это можно выявить хоть примерно на этапе сравнения, то с расширением - беда.
3. Самая вкусная тема механизма поставки
не рассматривали не мега коммит "Обновление типовой на 1.2.4.5" от имени 1C, а несколько коммитов по подсистемам и потом merge в origin1c, тогда можно как черри-пик, так и мелкий merge сделать (имхо в таком варианте merge будет предпочтительней с включенным модулем rere)
сравнение табличных документов, графических схем и прочей подобной ерунды
просил у 1C xsd схемы для таких метаданных, но они сказали "в планах публикации такого нет", поэтому вскоре попробую сам создать пару примеров и попытаю счастья с merge EMF пакетов в Eclipse, возможно будет хорошее решение.
Для форм и предопредленных данных или метаданных помогает xmldiff консольная утилита, т.к. чаще всего это добавление в дерево нового узла.
данную историю получил простой выгрузкой каждой версии 1с в файлы и коммитом в git
А мне вот интересно как вы поступали с переименованиями. К примеру, переименовали справочник из НенужныйСправочник в УдалитьНенужныйСправочник или форму или ещё что-нибудь. Как с этим быть?
Если в типовой конфигурации это в 90% будут переименования с добавлением приставки Удалить, то в моей разработке при рефакторинге бывают совершенно другие переименования. Я просто не знаю, что с ними делать, чтобы сохранялась их история. Вручную про них незабывать совершенно нереально.
И если в каком-нибудь старом коммите обнаружил, что переименование прошло как удаление и добавление, можно ли как-нибудь ручным приводом этот старый коммит исправить, чтобы всё встало на свои места?
(21) sashocq, обычно git сам определяет, что это переименование файла или каталога, конечно если вы не будете сильно менять содержимое файлов, но есть и ручная команда git mv староеИмя новоеИмя.
Если вам необходимо исправить историю, то тут только checkout на этот коммит, исправление и потом последующий rebase.
Если вам необходимо исправить историю, то тут только checkout на этот коммит, исправление и потом последующий rebase.
Не могли бы пояснить: как я понимаю для интеграции с репозиторием используется стандартный функционал конфигуратора по выгрузке (/загрузке) конфигурации в файлы xml.
А готов ли этот механизм для того чтобы заменить хранилище git-ом? Для примера, выгрузил cf из УТ11, потом выгрузил в файлы и собрал из них новый cf-ник (попутно получил предупреждения о каких-то картинках).
Итого:
1. Разница в размере cf - примерно 5Мб.
2. Если сравнить получившуюся конфу с cf, обнаруживаются различия в ряде обработок и нескольких документа (различия правда отображаются пустыми).
А готов ли этот механизм для того чтобы заменить хранилище git-ом? Для примера, выгрузил cf из УТ11, потом выгрузил в файлы и собрал из них новый cf-ник (попутно получил предупреждения о каких-то картинках).
Итого:
1. Разница в размере cf - примерно 5Мб.
2. Если сравнить получившуюся конфу с cf, обнаруживаются различия в ряде обработок и нескольких документа (различия правда отображаются пустыми).
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.