Начнем.
Уже давно обещал поделиться нашим опытом по работе в новой среде разработки. Наконец нашел время и подготовил краткое описание – небольшой отчет и некоторые мысли. В качестве источников информации для осмысления были взяты:
- вопросы с партнерского форума;
- мнение коллег на основе практики работы;
- мнение коллег из сообщества;
- интернет;
- мои собственные мысли.
Пока сообщество в целом настороженно смотрит в сторону EDT, но постепенно свыкается с мыслью что он есть и будет. Надеемся, что данная статья поможет вам сделать шаг или еще один шаг в сторону начала работы в этом новом инструменте.
О чем мы хотим рассказать (обзорно):
- Интерфейс и возможности EDT;
- Ключевые моменты при работе с GIT;
- Процесс разработки;
- Полезные советы.
Готовы? Поехали!
I) Основное про интерфейс и возможности EDT.
Скажу сразу, что заядлый разработчик 1С при переходе в EDT почувствует себя «не в своей тарелке»: больше вкладок, другой интерфейс, другие горячие кнопки, другие баги) Возможно у кого-то будет отдаленное ощущение, что вы как Алиса попали в зазеркалье. Поэтому советую переходить постепенно и пробовать новое блюдо небольшими порциями.
Отметим отдельно — работа в EDT это теперь не только «сидеть в конфигураторе», теперь это жизнь в полноценном окружении и в рамках процесса разработки.
Переспективы.
Первое на что следует обратить внимание и то с чем вы сразу сталкиваетесь, когда окажитесь внутри – это переспективы. На них расположены основные рабочие пространства:
• 1С пространство.
• GIT пространство.
• Debug пространство.
1С пространство.
Это основной рабочий экран, в котором вы будете проводить большую часть времени. Он удивительно похож на конфигуратор, но с «небольшими» отличиями.
Навигатор проекта. В дереве метаданных, мы можем теперь загружать произвольное количество конфигураций, а не одну как ранее. Теперь в навигаторе проекта можно открыть множество конфигураций, внешние обработки и отчеты. К недостатку можно отнести, то что расположено вся эта красота линейно и нет возможности делать какие-либо группировать по папкам. В связи с данным фактом советуем не активные проекты в текущий момент закрыть, чтобы не отъедались лишние ресурсы.
Подсветка ошибок. Большим плюсом можно рассмотреть возможности синтаксис контроля. Теперь проблемы отображаются не только в отдельной вкладке, но и в каждом узле дерева метаданных.
Задачи по коду. Можно создавать мини задачки для себя внутри конфигурации (для полноценного управления задачами все же стоит использовать взрослую систему). Они отображаются на панели вкладки «Задачи». Для их добавления пишем в коде конструкцию:
//TODO: Вот тут позже допилю, сейчас некогда)
Синтаксис помощник автоматически позиционируется по выбранному коду. На мой взгляд стало удобнее.
Сравнение кода, конфигураций. Возможности сравнения гораздо более продвинутые, правда довольно непривычно относительно привычного инструмента из конфигуратора. Теперь вы без труда сможете сравнить текущее состояние конфигурации с конфигурацией в проекте, с конфигурацией из файла или с любой версией в гит. Сравнение с историей теперь выглядит гораздо удобнее и практичнее. Для этого необходимо выбрать проект и в выпадающей командной панели по правому клику мышки ищем «Сравнить с…»(Compare with…) и выбираем один из доступных вариантов.
Горячие клавиши. Клавиши работы в EDT изменились и теперь придется переучиваться или запоминать второй набор. Чтобы вызвать список доступных горячих клавиш нажмите комбинацию «Control+Shift+L». Приведем набор наиболее полезных сочетаний:
- Подсказка «Ctrl+Space»
- Закомментировать «Ctrl+/»
- F3 перейти к определению
- F11 отладка и Ctrl+F11 запуск.
- И другие.
И еще много чего интересного, устал писать. Попробуйте посмотреть сами.
GIT пространство.
Мы занимаемся командной разработкой, а тут без работы с распределенными хранилищами и вресионированием никуда). Интерфейсно упрощенно и немного спартански местами. Позволяет выполнять стандартный функционал + некоторая специализация по назначению IDE. Интерфейс SourceTree или GitHubDecktop поприятнее и удобнее.
Очень большая плюшка заключается в том, что вы теперь можете в один клик в дереве веток переключиться на другую версию и конфигурация изменится по мгновению) Однако не всегда стоит запускать обновление конфигурации базы, иначе ее можно сломать.
Более подробно про работу с GIT напишем ниже.
Пространство отладка.
Для отладки в EDT серверной базы у вас в настройках кластера должен стоять атрибут «-debug» и «-http», по умолчанию если не указано считается «tcp/ip».
В конфигураторе придется изменить настройки также по пути на вариант http – «Сервис»-> «Параметры»-> вкладка «Отладка»-> «Протокол отладки» изменить на «Отладка по протоколу HTTP» и «Сервер отладки» установить, как «Использовать сервер отладки кластера».
Чтобы подключить клиент браузера необходимо выполнять запуск с параметром «debug». Пример: http://localhost/demo?debug&debuggerurl=127.0.0.1 или http://localhost/demo?debug
Процесс отладки теперь выглядит немного иначе, но основная суть осталась та же. Ждем дальнейших улучшений возможностей в этом направлении в EDT.
Другое.
Авто обновление. В настройках EDT по умолчанию стоит авто обновление конфигурации информационных баз в режиме «Обновление в процессе редактирования». Советую никогда не использовать данный режим.
Что делать, когда пока не поддерживаются некоторые особенности платформы? К примеру, работа с внешними источниками данных в EDT не поддерживается, но в силу обстоятельств работать с данным функционалом необходимо. В этом случае закрываем EDT и открываем конфигуратор (снова здравствуйте) и вносим требуемые правки, а затем снова возвращаемся в EDT и при попытке запуска он нам сообщит, что произошли изменения и предложит один из трех вариантов. Мы выбираем получить изменения в хранилище и наслаждаемся процессом. Весь неподдерживаемый функционал платформа сохраняет в папку рядом с проектом с наименованием «unknown» (неизвестные). Вручную редактировать в блокноте модули не советуем).
Поддержка поставщика. Увы изменять настройки поддержи в EDT пока нет возможности. В данном случае вы или снимаете «замочки», или разрабатываете расширения. И снять «замочки» рекомендуем до импорта проекта в EDT в старом добром конфигураторе.
Оборудование для работы. Конфигурация «Тестирование 3.0» достаточно легковесная поэтому работает достаточно успешно на средненьких мощностях. Мне удалось на ней работать в «VirtualBox» на ноутбуке i7-4500U 2,6 ГГц (3,1 ГГц boost) с 8ГБ, для виртуальной машины я выделил 2 ядра и 4 Гб памяти. На стандартной машине разработчика работа идет комфортно, даже отлично.
ERP запускали на сервере разработки с Xeon E5-16300 3,7 ГГц и 128 Гб памяти. По ощущениям не уступает конфигуратору, но потребляет значительно больше процессорных ресурсов и памяти. И количество одновременно работающих пользователей на этой машине разработки снизилось до 3х-4х человек с временным пожиранием ресурсов процессора до 90-100%.
Что в итоге?
Подведем резюме сравнения с типовым конфигуратором.
Преимущества:
• Новые возможности разработки
• Механизм сравнения в целом, а также сравнение форм, ролей.
• Новое хранилище, основанное на GIT
• Возможность создания плагинов
• Система редактирования запросов и возможность сохранения комментариев после редактирования конструктором
• Более удобная и наглядная отладка
• Есть структура модуля, иерархия вызовов, er-diagram и всякие удобства, которые не планируется на старом конфигураторе
Недостатки:
• Нет пока поддержки части функционала, доступного в старом конфигураторе (приходится использовать сразу две среды)
• Жрет ресурсы, использует Java и пока кажется более медленным
• Более нагруженный интерфейс
• Непривычная среда исполнения
• Новые баги) а также куча мелких надоедливых багов, как разбегающиеся тараканы ночью на кухне)
• Еще не готов к комфортной разработке крупных проектов типа ЕРП.
В целом EDT выглядит обнадеживающе, про недостатки можно сказать так: со временем стерпится и слюбится)
II) Про работу с GIT и процесс разработки
Про GIT.
Надеюсь вы крайне отрицательно воспринимаете утверждение, что «Настоящие гуру не использую хранилище, а правят по живому». Тогда использование этого механизма покажется вам настоящим удовольствием и качественным переходом. Мне нравится следующая мысль: «Может быть это маленький шаг в мире разработки ПО, но это большой скачек для сообщества 1С)»
Сейчас в сообществе поднимается хайп по вопросам, связанным с GIT (смотрим на количество упоминаний слова GIT в рамках предстоящей конференции 2024), но на мой скромный взгляд, использование данного функционала самого по себе без привязки к процессу разработки не полноценно. В связке с EDT это уже выглядит как закономерное и полезное явление.
Хранилище GIT. Используем GIT на GitHub с публичным репозиторием, если хотите приватный, то придется доплатить. Можно получить бесплатный приватный репозиторий на botbucket, только тут другое ограничение – бесплатно можно использовать только на команду в 5 человек.
Инструменты для работы с GIT. Это список из следующих приложений:
• старый добрый GIT GUI. Довольно аскетичен и прост, можно сказать ничего лишнего, а если вам надо что-то более сложное, то берем консоль Git Bush и решаем те задачи, которые не по силам графической части.
• GitHub Desktop. Инструмент, оптимизированный для работы в облаке Git Hub. Если используете хранилище в этом облаке, то это будет хороший выбор.
• Встроенный в EDT. Он есть, и он работает. Его функционала вполне достаточно для реализации поставленных задач по разработке.
• Source Tree. Мощный и популярный бесплатный инструмент от Atlassian. Красив и практичен.
• И последний это TortoiseGit. К его преимуществам можно отнести тот факт, что он хорошо встраивается в контекстное меню проводника. Благодаря этому вы сразу в нем сможете для конкретного файла получить подробную информацию об его изменениях или выгрузить копию из истории.
Все инструменты пригодны для работы и у нас коллеги используют несколько комбинаций. Те, которые нравятся в силу тех или иных индивидуальных особенностей.
Ветки (brunches). Основополагающая сущность. При решении задач или внесении изменений, которые не должны появляться в рабочей базе сразу мы создаем ветви. Тут есть даже немного магии: хотите переключиться на другую версию — двойной клик и мы уже в параллельной версии конфигурации. Если вы используете системы управления разработкой как jira, то создание новой ветки можно выполнить непосредственно из браузера со страницы с задачей) — система все сделает автоматически.
Получение изменений (fetch/pull). Примите за правило получать изменения из облака – fetch+merge или pull!
Передача изменений (push). Сделали работу и завершили задачку, тогда отправляем наши изменения в основное хранилище.
Тайники (stashes). Очень удобный инструмент. Необходимость возникает в нем в том случае, когда вы работаете над какой-то задачей и вдруг вынуждены переключиться на блокирующую или срочную, но помещать код в ветку облака не хочется. У нас есть правило не работающий код мы не коммитим и не помещаем. Откатывать свои изменения или делать копию текущего состояния невыход или не удобно. Поэтому смело создаем тайник, в который скроются все изменения. Потом, когда вернетесь к текущей задаче, то смело сможете достать прерванные изменения и продолжить работу.
Про процесс работы.
В качестве процесса разработки для конфигурации "Тестирование 3.0" мы выбрали «Git Hub Flow» (показан на рисунке ниже). Это наиболее простой из существующих процессов разработки, если не сравнивать с анархией. Думаю, еще вас могут заинтересовать «Git Flow» и «Git Lab Flow», но об этом в другой раз.
Процесс разработки «Git Hub Flow» — теория.
Реальная картинка с рассматриваемого проекта – практика)
Что хорошего в этом процессе?
- новые возможности добавляются сразу по готовности;
- ошибки исправляются довольно оперативно и добавляются в текущий режим;
- простой рабочий процесс: минимальное количество правил, наличие одной основной ветки (master).
Рекомендации для успешной работы в рамках процесса:
- содержимое ветви master должно быть всегда работоспособно;
- любая доработка должна отражаться задачей и формировать ветку из мастера с номером задачи в наименовании. Наименование задачи должно отражать краткую суть происходящего;
- всегда создавайте pull-request;
- используйте в разработке обязательно код-ревью, вы же команда! Не стоит следовать мыслителю с картинки ниже по тексту.
Как мы перешли с конфигуратора? У нас есть два хранилища релизное и разработческое, или рабочая конфигурация и хранилище разработки:
- На первом шаге в ветку мастер выгружаем рабочую конфигурацию;
- На втором шаге делаем ветку с именем "Старое хранилище" и туда загружаем хранилище разработки;
- Далее при необходимости сливаем изменения из бранча старого хранилища в ветку develop или mater (в зависимости от процесса).
Что в итоге?
Какие плюсы:
- Наконец появилась возможность нормального командного процесса работы и разработки;
- Это GIT, с конфигуратором это было не реально! Хранилище не считается);
- Возможность просмотра истории изменений в один клик и быстро;
- Дополнительные бонусные возможности настройки правил работы с репозиторием из облака (github — защита ветки, необходимость pull-request, обязательность code-reviw и др.);
- Другие преимущества использования GIT.
Что из минусов:
- В некоторых случаях усложняется процесс разработки;
- Это не привычно и нужно подстраиваться;
- В EDT пока еще баги и это несколько портит впечатление.
А какой процесс использовался при работе с конфигуратором? Некоторые коллеги, с которыми я общался, вообще не использовали хранилища для разработки или в давние времена изменения отправляли прямо в production. В конфигураторе вести разработку с использованием веток или ветвления возможности не было поэтому это огромный плюс, который появляется с приходом EDT в мир разработки 1С.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
норм, для пары разрабов…
(1) с каждым новым релизом EDT работает быстрее и быстрее) К тому же, рынок CPU не стоит на месте, производительность предложений постоянно растет.
И я думаю через несколько лет, данные характеристики будут уже казаться чем-то обыденным и устаревшим.
Большое спасибо за обзор, пара вопросов:
1. Какого уровня конфигурации Вами редактируются в EDT — самописки, небольшие типовые конфигурации 1С или большие (УТ, ЗУП, ERP)?
2. Какую версию EDT сейчас применяете? Если последнюю (1.9) — есть ли заметные наш взгляд изменения в ней (сокращение ошибок, рост скорости)?
(3) 1. Используем версию 1.8.4.9, с нетерпением ждем 1.9.0, в ней поправлено определенное количество значимых для разработки багов и она еще не вышла) Как выйдет, то перейдем на нее.
2. Используем сейчас для разработки кастомные конфигурации и все мобильные разработки
3. Как я писал ранее, пробовали работать в ERP, но не устроили в работе некоторые баги EDT (иногда не верно перестраиваются формы при смене веток, приходилось открывать и закрывать, зависало построение) — для легковесных конфигураций это не заметные проблемы, но для такого уровня конфигурации выходит ощутимо.
В целом впечатления сугубо положительные.
Актуальная статья, надо ждать 1.9.0.
(0) ivanov660, Вы — сотрудник 1С?
Обращает внимание использование слова «зазеркалье» в названии статьи.
(2)
Есть мнение, что через эти несколько лет устаревшим окажется как раз EDT 🙂
Счастье для всех настанет, когда группу разработки ERP внутри самой 1С переведут на EDT.
(6) нет, это просто аллегория, игра слов)
(8)Все относительно. Возможно они станут лучше работать и не только над ЕРП, и нам с вами будет доставаться меньший кусок хлеба. Счастье ли это?
(5)Уже есть в бетте, но ссылка не рабочая. Что к сожалению, не удивляет 😉
Почему дерево конфигурации не на русском языке?
По умолчанию запускается на языке системы, у нас английская, но вы можете принудительно настроить язык на русский в EDT. Дополнительный бонус для статьи.
Для этого есть два варианта:
1. В ярлыке прописываем к строке запуска «-nl ru»
2. В файле ini для конфигурации добавляем строчку «-Duser.language=ru»
(10) скажите честно, вы верите в это? Конфигурации идут по пути усложнения и конца и края этому нет.
Если не секрет, где работаете? Интересно узнать, в какой фирме используется столько классных штук, как EDT, Git, тестирование, да еще МП занимаетесь.
(12) я вчера норм скачал и поковырял 1.9
Кроме гитхаба, где приваты платные и битбакета, где приват сильно ограничен, есть еще очень популярный нынче гитлаб. Его можно и себе поставить и не сильно ограничиваться в размерах и в конвейерах, а можно использовать ихний хостинг. Там ограничение в 10Гб на проект, вроде б только. По пользователям не было и конвейеров дают на 2000 минут в месяц.
(15) Дык это от людей зависит, а не от фирмы. Хочется использовать классные штуки? Берешь и пользуешься. ЕДТ, Гит, скрипты, дженкинс и тестирование бесплатно. Просто мало кто любит изучать что то новое просто так, не по принуждению.
(17) Руководство обычно косо смотрит на вещи, не приносящие сразу деньги. «Работать, негры!»
Мое мнение о EDT из гиттера
«Поработал я полноценно в ЕДТ дня 4. Разрабатывать конечно можно, но все плюсы от новой иде перевешиваются кучей мелочей, привычных с конфигуратора.
Шаблонов кода нет (точнее они есть какие то свои, но как их получить — хз), работать с формой и с объектами неудобно, горячие кнопки многие другие, особенно в отладке.
Отладку вести не удобно, особенно неудобно смотреть таблицы — сначала нужно много кликать, а потом открывается небольшое окно, которое не развернуть на весь экран, и из которого нельзя сделать экспорт в табличный документ/ексель или еще куда.
Поиск по конфе я так и не нашел, только по модулю.
Ошибок левых выдает тонну, а когда реально продолбал КонецЕсли, то список ошибок мне в этом вообще не помог. На конструкцию дерево = Новый ДеревоЗначений(); ругается, что возможно будет null . Показывает, что в форме есть ошибки, но не показывает где.
Синтаксис-помощник какой то вообще не удобный и не получилось что то искать в справке просто спозиционировавшись на слове.
из явных плюсов
все таки динамическое типизирование иногда помогает, имена колонок в ТЗ подсказывает, можно работать с гит, отладка за счет большого вывода инфы может быть проще, просто у меня все через коллекции работало.
Построение иерархии вызовов как замена глобальному поиску использования метода.
Более умное форматирование, которое и длинные строки разбивает, и лишние пустые строки удаляет. Правда мне мой onestyle больше нравится.
Иногда ошибки и предупреждения по конфе реально помогают, особенно когда тебе сразу отображается красным подчеркиванием какие строчки ты сломал добавлением нового параметра в метод.
Создание конструкций по шаблону, где между параметрами переключаешся табом иногда очень даже удобно. А иногда это жутко бесит, когда в методе 10 необязательных параметров и нужно все лишнее поудалять.»
Интересное положение сложилось, конфигуратор «забросили», EDT в работе использовать невозможно.
P.S. Сам жду не дождусь EDT. На Java приходилось работать в Eclipse, весьма понравилось.
(18)Уметь продать руководству новые инструменты тоже надо уметь 😉 ну или в подходящий момент сделать предложение.
(20)как я и писал, к EDT нужно привыкнуть. Мы работаем, иногда мелкие баги мешают, но особых проблем нет.
(15) Посмотрите видео уроки — в них мы немного рассказываем про инструментарий, заодно и компания упоминается (есть в других статьях), так же можете меня поискать в списке голосования на конференцию)
1.9.0 уже есть тестовая
(21) Жаль что с JetBrains не скооперировались, недавно провел в андроид студии неделю на работе, после нее что на конфигуратор, что на эклипс смотреть больно было((
(2)Вот он современный подход к программированию в действии, просто классика, — «Мы сейчас накодим неповоротливое жрущее кучу ресурсов нечто, а через годик появится железо на котором наше творение начнет работать по-настоящему»
(28) Не раньше, чем сама 1С на него перейдет на 100% :))
(27) И этот подход экономически оправдан. Собственно 1с как раз продукт этого подхода: уровень абстракции на максимум, разработчика ограничить чтобы «фигней» не страдал с их точки зрения, а на производительность можно и подзабить.
(30)Согласен, только с одним «маленьким» уточнением, экономически оправдан для разработчика, все остальные участники цепочки пожинают плоды этой оправданности.
Чайниковый вопрос — а где настраиваются / отключаются лишние сообщения об ошибках?
(31) Как раз оправдан больше для заказчиков, потому что хоть что то хоть как то работающее лучше чем отсутствие продукта вообще. P.S. Я как разработчик как раз предпочел бы кучу всего выкинуть вроде js, php, 1С и подобного.
(33)Под разработчиком я имею ввиду все-таки не одного программиста, а группу под руководством. А отсутствие продукта вообще легко нивелируется правильным планированием, скорость разработки для потребителя и внедряющего имеет большое значение, но не решающее, если брать усреднено, без крайностей
(28) Скорее обратное — конфигуратор никуда не денется, а EDT свернут как неудачный проект.
(35)Учитывая сколько средств они в него вложили и слухи о директиве развития от 1С в данном направлении, сомневаюсь в данном утверждении.
К тому же, в данном подходе есть свои плюсы для компании, они теперь работают на плагином к IDE а не над всем инструментом в целом.
Для меня, как специалиста, большой интервал проработавшего с другими IDE — Visual Studio, Emercadero, Elipse — переход с конфигуратора на EDT не стал трагедией.
(36)
Не так уж много. Времени много убили, это да.
(37)Вспоминается поговорка «Время-деньги». Вы согласитесь, что это два ресурса, т.ч. существует формула перевода T в $.
(32)К настройке проверки конфигурации можно перейти через свойство проекта. В них вы можете установить те проверки, которые необходимы:
(38) Узким местом?:) Простите, а вы точно 1с программист?
(38) простите, а почему за последнее время родилась куча костылей для конфигуратора — снегопат, турбоконф, ванессы? Оттого что конфигуратор — венец IDE, которому завидуют всякие Vusual Studio? А хранилище 1С заставляет всякие GIT бледнеть от зависти?
p.s. И почему в 1С решили избавиться от кучи денег, забросив конфигуратор и вложив столько сил в принципиально новую разработку с посторонней командой.
(40) Спасибо, нашёл. Хорошо спрятали.
(42) снегопат был рожден тогда, когда конфигуратор имел мало возможностей и удобства, турбоконф — это вообще для единиц, им никто не пользуется. Хранилище 1с тут вообще не при чем.
ПЫСЫ: ничего они не забросили, просто решили для таких как вы выпустить новую среду =)
(44)
(42) снегопат был рожден тогда, когда конфигуратор имел мало возможностей и удобства, турбоконф — это вообще для единиц, им никто не пользуется. Хранилище 1с тут вообще не при чем.
ПЫСЫ: ничего они не забросили, просто решили для таких как вы выпустить новую среду =)
А почему конфигуратор не догнал и обогнал Снегопат (и товарищей) а так и остался неудобным и недофункциональным?
(45) Вопрос из рода… а зачем расширения придуманы… зачем в браузере их использовать…
Скажите, какого функционала вам не хватает и чем он неудобен? Может я просто чего-то не знаю или не использую. Буду благодарен.
(46) Мой вопрос звучал — почему родной конфигуратор не развивается, зато создан и активно развивается посторонний продукт?
Насчёт функционала: Человеческий автокомплит (без дурацких Ctrl+Enter и без вываливания левых вариантов) — посмотрите как это работает в снегопате и как этого жутко не хватает тем, кто хоть раз это попробовал. Ну и Git вместо хранилища.
(28)
Пока больше напоминает трактор.
(48) Да потому что сама 1С не в состоянии развивать конфигуратор (например из-за нехватки кадров по С++). Если вам не нужен нормальный автокомплит — то сидите в конфигураторе, его нескоро убьют. Но не равняйте всех под свою гребенку, возможности конфигуратора на сегодня — сильно отстают от ожидаемого.
(38)
Ручка без чемодана мало чем лучше.
(50) Ну так я и пытаюсь выудить у вас, от чего сильно они отстают.
Используйте шаблоны!
А вообще, такое ощущение, что вы кодер в пятом поколении и скорость набора кода и подставновка не успевает за вашей мыслью.
Я обычно 100 раз отмерю, а затем уже кодю =) Не спеша, а «с чувством, с толком, с расстановкой» (с).
(28)
Возможно, даже если и не свернет в ближайшие 10 лет, то многим и не будет надобности пересаживаться в «кабриолет». Многим не нужен «кабриолет», их вполне устраивает «велосипед».
Не будем далеко ходить:
— 1С 7.7 уже много лет как устаревает и никак не может устареть ))
— Механизм расширений уже вполне себе ничего работает, а про него многие даже не слышали )).
(53) 1С может легко применить свой специфический добровольно-принудительный подход по форсированию событий, который успешно применяется на примере ЗУП, БУХ, ЕРП.
Честно говоря никак не пойму что все носятся с этим GITом.. большинство разработки на 1с это команды разработчиков до 10 чел, там хранилища выше крыши. Я хранилище использую даже в тех базах где только я один разработку веду, просто ради истории объектов. По поводу недоработанного функционала который предполагается делать ветками в гите — так в продуктовое хранилище не кладите объекты недоделанные и все. Все что в общем хранилище — все считается готовым и все. Иногда бывает что нужно положить в хранилище и чать не готового функционала, опять же не беда — решается обновлением продуктовой базы через сравнениеобъединение (у нас рабочая база не подключена к хранилищу).
ИМХО: EDT выпущен ради зарубежного рынка, где конфигуратор представляет собой некую вендервафлю которую никто не принимает, им проще работать с какой нибудь привычной IDE, например Eclipse. Ну и второе — EDT как корпоративный инструмент для разработки в больших командах, думаю его сделают платным когда доведут до вменяемого состояния, но судя по темпам будет это не скоро.
По мне так добавили бы отбор по ролям в дереве метаданных.. это то что вызывает боль каждый день.
(42) ну вот я использовал снегопат на одной из работ (ну просто потому что он там был куплен до меня), удобно.. сейчас не использую уже несколько лет (просто потому что не куплен) и как бы без него прекрасно обхожусь. Но тут каждому свое конечно.
(55)1. Вы правильно поступаете, использовать хранилище необходимо в любом проекте.
2. Когда, вы вынуждены объединять через сравнение и объединение с рабочей базой, вы используете каким либо образом тестирование?
3. Конфигуратор конечно можно было бы довести до ума, для счастья не хватает совсем немного: работа с ролями, сравнение форм и пару других вещей.
(56) Некоторые в работе редактор vim используют и не понимают, зачем кто-то покупает MS Office.
(57) автоматизированное тестирование не используем. Если нужно протестировать функционал до внедрения на продуктовой базе (например какой то крупной подсистемы) то у нас есть серверная копия базы свежая, туда накатываем релиз и даем это дело консультантам на тестирование и описание функционала (составление инструкции)
(58) редактор никак не влияет на качество кода, к сожалению.. снегопат помогает, не отрицаю, но тут 99% успеха не в снегопате а в прокладке между стулом и клавиатурой. Та же история и с EDT, в верю что оно кому то ближе, привычнее, понятнее, но это никак не влияет на качество производимого продукта в EDT (за исключением каких то очень крупных систем с сотней разработчиков, где на первый план выходит организация работ — где EDT с его GITом может здорово помочь)
(60)
Поймите, пожалуйста — конфигурации усложняются, и единственное, что будет выручать в текущей ситуации — обвешиваться электронными помогалками.
(59)Рекомендую все же пересмотреть отношение к автоматизированному тестированию. Ручное тоже неплохо, хотя ему свойственны определенные ограничения.
(62) а у меня очень положительное отношение к автоматизированному тестированию, другое дело что культура тестирования только прививается в сообществе 1С и я не спешу бежать впереди паровоза, пока смотрел в сторону OneScript например, но его применить в реалиях нашего предприятия пока нереально. Написание теста то же занимает время, а у нас это критично, пока шквала ошибок нет невозможно убедить руководство что нужно увеличить сроки разработки в ущерб бизнесу что бы писать тесты.. а до шквала ошибок доводить не хочется. Больше спасает практика code review.
Опубликован EDT 1.9.
Что могу сказать? В общем — ничего нового. Та-же платформа Eclipse годовой давности, те-же бредовые ошибки и глюки.
Я не разочарован — никаких иллюзий не было. Надеюсь лет через 10 доведут до ума.
(63)
1. Молодцы код-ревью — это хорошо )
2. Тесты бывают разного уровня и полезности:
— мы используем юнит тесты, но они идут со скрипом. Не любят 1С-ники тестирование. Приходится придумывать модели тестов, чтобы часть из их исполнения переложить на сторонние плечи с программистов. Дойдут руки, напишу статью с примером на инфостарте.
— сценарные тесты. эти тесты у нас пишут не программисты, знаний в программировании не нужно никаких, только знание куда и в какой последовательности нажимать согласно БП. У меня для создания полноценного теста ушло не более 30 минут. А по факту, мы этот тест уже запустили порядка 1000 раз.
итого экономия (-10 000 руб актуализация и анализ ошибок-2000 руб стоимость разработки + 1000 раз*100руб стоимость прогона ручками = 88 000 руб)
(64) Улучшения есть и они очевидны, особенно для тех кто в ней работает, вот что понравилось:
— наконец можно указывать каталог сохранения обработок и отчетов;
— указывать имя файла обработки (ранее был равен имени проекта) — из-за этого пришлось переправить шаблоны в открытом проекте;
— визуализация ошибок в проекте стала заметно лучше;
— уменьшилось количество багов/глюков при отображении форм, при открытии;
— улучшилась работа с помощниками комментирования.
По багам станет ясно через несколько дней.
Спасибо большое за работу, реально хороший материал.
Ниже опишу свои проблемы, связанный c 1c git flow 😉
У себя в команде перешли на гит с костылями. Используем gitlab + обычный конфигуратор.
Цель была — получить нормальный брэнчинг, так как сравнивать дев хранилище с прод стало просто нереально сложно.
Проблемы которые сейчас испытываем:
1. При малейшем изменении структуры дерева метаданных происходит полная выгрузка конфигурации в исходники(даже если делать выгрузку через ключ /DumpConfigToFiles –listFile. А это все отчеты, формы, макеты. Соответственно получаем кучу pain in the ass с мержем.
Обходим след образом : выгружаем в паралельный каталог конфу, и копипастим реально измененные файлы данных( конечно гемор, но результата добиваемся)
2. Переключение между ветками. Долго и муторно. чекаут выполнить на необходимую ветку — быстро, а /LoadConfigFromFiles мутоно долго, так как опять же переколбашивает всю конфу.
Вопросы к Вам:
1. Как вы эти два момента отрабатываете сейчас в EDT ?
2. Как EDT дружит с отладкой?
Вышла 1.9.0.
(68) Спасибо за информацию бро.
(67)
1. На первый вопрос:
— В случае EDT, то все хранится в каталоге — выгрузка не нужна.
— Само переключение между бранчами GIT выполняет быстро, для мелких конфигураций практически незаметно.
— Перестройка отображаемого дерева метаданных для больших конфигураций особенно подмораживает, версию 1.9 еще не щупали особенно, однако у коллег и у меня уже масса положительных впечатлений от некоторых улучшений.
— Изначально мерджить было непривычно после конфигуратора и тяжко из-за багов, однако разработчики оперативно устранили основные баги, в течении недели, мы получили работающую версию EDT с мерджем.
2. Про отладку:
— Как я писал выше в статье настройки окружения изменились
— Иногда в режиме http — на версии 8.3.11 отладчик мог зажевать 40% процессора под конфигуратором, видимо еще не обкатана технология
— Отладка стала удобнее, как в серьезных IDE:
— теперь параметры переменных всплывают при наведении курсора, а не модальное окно
— в перспективе сразу отображается предметы отладки (подключаемся в один клик), переменные, виден стек вызовов
— При проведении код-ревью (когда мало формы сравнения) достаточно переключиться на ветку и попрыгать по функциям без обновления базы. Иногда база может сломаться если всякий раз обновлять, но при необходимости всегда можно откатить базу на копию из архива.
P.S. Изначально сами пробовали работать в ERP с ежедневной выгрузкой конфигурации и пушем в гит, без загрузки, но из-за частых коммитов в хранилище и нереально долгой выгрузкой свернули этот функционал. Мы оставили гитить только обработки и отчеты — это быстро и удобно.
(70)
Спасибо за ответ.
Но с загрузкой конфигурации из файлов вы не распрощались ведь. Верно?
1. В EDT реализовали функционал
2. Загрузили из файлов конфигурацию на тестовый стенд
3. По http в EDT выполняете отладку к тестовому стенду
Алгоритм я правильно понимаю?
(71)Распрощались. EDT теперь делает все сама (это разработка 1С) и загружает только изменения, а не всю конфигурацию в целом. При желании можно установить флаг обновить всю конфигурацию.
т.е. теперь никаких костылей.
Статья интересная.
Автор, прошу вас развернуть эту фразу «Далее при необходимости сливаем изменения из бранча старого хранилища в ветку develop или mater (в зависимости от процесса)»
Ну то есть все красиво и понятно: мастер — это рабочий прод
ветка develop это хранилище разработки.
От ветки develop разрабы по задачам делают ветки, потом сливают их в develop.
Но основную боль вы не раскрыли, как будто у вас нет таких проблем.
А именно. Пример,
Два разработчика сделали по ветке на свои задачи. Только задачи связаны с одним объектом (модулем. формой).
Перед релизом все сливают свои задачи в ветку develop.
Как именно происходит слияние? Есть ли специально обученный человек, который принимает и обрабатывает pull-реквесты?
Вполне возможно, что оба разработчика сделают дублирующий функционал в месте где их задачи пересекаются или зависят друг от друга.
Как организационно это разруливаете? правила? запреты?
По шагам разложите? Кто и что делает?
Идеально было бы мой пример разложить по шагам в виде может быть отдельной статьи или публикации.
По шапкам-то оно понятно. вот только на практике когда пытаемся это делать, то » ну его на….».
(73) На сколько я понял вас интересуют уже технические вопросы мерджа и перехода, а также процесса разработки. Более подробно я планировал об этих вопросах рассказать на конференции.
Процесс разработки и взаимодействия между разработчиками у нас зависит от проекта (и конечно же для каждого случая будут свои индивидуальные моменты):
— Для проектов с открытым исходным кодом мы используем один подход и возможности предоставляемые облаком, т.е. обязательность pull request и защита ветки от не контролируемых помещений. Управляет процессом владелец и архитектор продукта.
— Для корпоративных решений — процесс «жизни» организован через систему багтрекинга, а сама схема процесса определена (взаимодействия пользователей) через инструкцию и описание в BPMN.
И вы правы объяснение подобных технических моментов это полноценная отдельная статья.
(74) Да, технические моменты интересуют.
Параллельная работа над одним объектом по разным задачам это краеугольный камень, который не дает переломить упорство разрабов и перейти на git и прочие ништяки
Нужен наглядный рецепт как мерджить такие задачи, чтобы ничего не сломалось.
Под это дело уже готовы выделить две команды, которые бы тянули один проект, но пока что все работают «по-очереди» в хранилище и никакого выигрыша от параллельности.
(75) Всегда есть вероятность, что что-то сломается (для того чтобы минимизировать возможный ущерб используются системы автоматизированного тестирования, и наиболее интересные в данном случае интеграционные тесты).
Наиболее жесткие в этом смысле системы контроля версий с пессимистическими блокировками — пример хранилище конфигуратора, когда доступ к объектам контроля блокируется, но в этом случае страдает параллельность работы.
Мы же рассматриваем системы контроля с оптимистическими блокировками, когда разрешение возможных конфликтов ложится на сторону пользователя/программиста. Зато появляется возможность параллельной работы.
Конфликты могут быть, а могут и не быть в последнем подходе. Если при выполнении слияния разработчиком происходит конфликт, то система попросит его выполнить объединение вручную, т.е. не позволит просто так залить код. Он засучивает рукава и принимается за работу.
После объединения, выполняем типовую проверку конфигурации. Далее запускаем автоматизированные тесты, которые подтвердят с определенной надежностью качество проделанной работы.
Если вы используете принципы гибкой командной разработки SCRUM, то согласно рекомендациям, разработчики обычно общаются между собой и обмениваются информацией, поэтому должны быть в курсе тех или иных изменений. Ну, и самый важный человек в данной цепочке — это архитектор, тот кто понимает как выглядит текущая архитектура и как она изменяется, что позволяет ему предвидеть конфликты в глобальном уровне и разруливать на уровне создания задач на разработку.
(66) Какой смысл от всех этих улучшений, если импорт типовой конфы УТ 11 так и завешивает EDT на час?
Им бы не следовало торопиться давать красивые названия минералов каждому релизу, а пока остановиться на «булыжнике» 🙂
А лучше пока еще не поздно, переносить наработки на IDEA, на эклипсе работать такой же прошлый век как и на 7.7. Тогда есть шанс и до «бриллианта» доулучшать, году к 2025-му
например
разраб 1 из города Москва создал на форме функцию
Функция СложитьОдиПлюсОдин()
КонецФункции
Разраб 2 из города Воронеж создал на форме функцию
Функция СложитьОдинИОдин()
КонецФункции
Что-то мне подсказывает, что гит нормально сольет это без конфликтов.
Но чувак, который пуллреквесты от обоих принимает должен это увидеть и что-то сделать?
Этот чувак будет второй из разрабов очевидно, потому что он сливая увидит такую же функцию в модуле и ему придется переписать свой код или заставить это сделать разраба 1.
Я не гвоорю, что должен быть третий чувак, который все это контролирует, т.к кадровый ресурс скажем ограничен и архитектор — это либо совмещение с ролью разработчик либо архиитектор не компетентен в вопросе слияния кода двух и более разрабов.
Основные вопли заключаются в том, что неохота перебирать за другими, когда у меня своих задач много.
Получается нужно выделять специально обученного человека, который и будет слияния веток контролировать ?
(78)1. Ваш пример сильно смахивает на «индусский кодинг» — бездумно лепить типовые функции общего назначения, да еще в модуле формы. По шеям обоим разрабам.
2. Да, гит автоматически замерджит, сработает автослияние.
3. Вопрос к культуре разработки. Организация процесса разработки — является важным вопросом, который и должен расставить все точки над ё.
К примеру, вы можете использовать обязательность код-ревью, когда каждый запрос подтверждается согласием из набора участников до принятия в ветку. В этом случае, пользователи просматривают изменения и подтверждают.
Соответственно, в этом случае, первый pull-request пройдет успешно (на самом деле должны были отловить подобный анахронизм и забраковать), а второй pull-request должен быть зарублен первым разработчиком с комментарием «дублирование функционала» и отправлен на доработку (хотя уверен, что также пройдет успешно).
Вопрос озвученный вами можно рассматривать как вопрос поиска дублирующегося кода перед принятием запроса на слияние и рефакторинга после (поиск дублирующегося кода постфактум).
(77)
1. Эклипс бесплатна.
2. Многие использованные готовые модули созданы для Эклипс, например, Xtext. Портировать — дешевле и быстрее с нуля написать.
И уж точно не объявлять final.
(77) Специально провел замеры по импорту типовой конфигурации УТ на EDT 1.9:
5-6 минут и EDT завершил импорт конфигурации
7 минут и дерево построено
далее запускается компиляция связей
12 минут открыл форму и открыл модуль формы, можно работать
чуть позже запустилась процедура валидации конфигурации
17 минут завершилось все
из оптимизаций можно:
каталог для временных файлов указать на скази или RAM диск
взять процессор мощнее 4.5-5.0 ГГц (предполагаю время может сократиться в 1.5 раза)
снять с поддержки
можно отключить некоторые действия
к тому же, импорт конфигурации и не обязан быть мгновенным, важен процесс работы и отладка.
Коллеги, кто уже начал разрабатывать, подскажите. Почему, когда я открываю конструктор запросов я не вижу там вкладки «Итоги», Если я руками допишу раздел итогов в запросе, то если открыть текст запроса, то система показывает ошибку и говорит, что запрос пишется по СКД и секции итогов быть не должно….
(82) Ну так, вероятно, ты запрос пишешь для СКД-отчета. Там все итоги самой СКД делаются. Поэтому в запросе они недопустимы.
(83) Нет, запрос пишу в модуле объекта…..
НА партнерском форуме написали, что это ошибка. Обещали поправить.
(13)Еще бонус. Если возникают проблемы с отладкой по причине длинного пути. Выглядит это так что в сообщении пишется о ошибке нахождения файла и в логе видно что путь обрезан. Это происходит из-за того что обычно путь к временному каталогу пользователя очень длинный. То рекомендуем:
1. Сменить для пользователя путь по умолчанию к temp папке
2. Настроить в файле 1cedit.ini короткий путь к каталогу временных файлов: -Djava.io.tmpdir=с: emp
Добрый день.
Подскажите, пожалуйста:
1. Как именно интегрировались с Jira. Какой плагин, как ставили, какие настройки.
2. Получилось ли настроить подключение к клиент-серверной базе, чтобы вносить изменения в конфигурацию в нее из EDT. С файловой все понятно, работает.
(87) со вторым вопросом разобрались. Все должно быть на 8.3.12. А у нас база была на сервере 8.3.11.
(87) В JIRA встроенная интеграция с хранилищем версий bitbucket, которым мы пользуемся.
(20) Здравствуйте! Не подскажите, есть ли сейчас возможность прямо из EDT собирать релиз 1с (комплект поставки, дистрибутив) ? Или данный инструмент остался в режиме Конфигуратора?
Появился ли в последних версиях инструмент редактирования текстов интерфейса?
Я не самый продвинутый разработчик. Но иногда мне интересно попробовать новое. Периодически я пытаюсь поработать на этом приложении. Я не знаю, что там ускорилось и улучшилось, у меня проблемы с формами. Есть конфа, самопис полный. я пытаюсь сделать в EDT новый документ и 10 у меня ВООБЩЕ НЕ ОТРАЖАЕТ на экране ни одну форму… как-то так. на скриншотах там, где форма есть это 1.8.4.9. Где формы нет самый последний 1.10.0.1925 релиз 8.10.2667
(92)
удалось решить проблему с формами?
(92)попробуйте задайте вопрос на партнерском форуме, они там оперативно отвечают и правят.
Да Бог с ними 🙂 Перешел на 13 релиз платформы (очень заинтересовала встроенная история данных) а 13 релиз EDT в принципе не поддерживается. Ждем апреля, там вроде сразу поддержку до 14 анонсировали.
ps под старым ником вошел 🙂
(30) На фиг такое «абстрактное», когда каждый чих приходится описывать по 10-20 строк кода.
Иногда, так и вспоминается clarion добрым словом.
(96)
Ну, я в итоге и не выдержал.
Случайно зашел в тему. Ну раз уж здесь… Подскажите, пожалуйста, как включить английский для функционала git? У меня уже глаз дергается от этих Получить и слить, Фиксировать, Перебазировать. ПЕРЕБАЗИРОВАТЬ, Карл!!!
Спасибо.
(98)смотрите 13-е сообщение