Куда привели 2 года работы с EDT

Публикация № 1720616 01.09.22

Приемы и методы разработки - EDT

EDT позволяет работать с кодовой базой конфигураций напрямую – использовать GIT, помещать изменения в ветки и запускать тесты до попадания в основную кодовую базу, чтобы добиться «зеленых ночных сборок» для конфигурации. Разработчик из компании «Первый БИТ» Валерий Дыков на конференции Infostart Event 2021 Post Apocalypse рассказал, как безболезненно перейти на EDT и получить преимущества работы с GIT, продолжая работать в конфигураторе.

Меня зовут Валерий Дыков, я разработчик из компании «Первый БИТ», офис БИТ:ERP. Расскажу про наш опыт использования EDT, который уже насчитывает два года.

 

 

Вначале давайте познакомимся.

Я занимаюсь 1С с 2000-го года – начинал с простого разработчика, прошел путь до директора франчайзи, работал в фирме «1С» и последние девять лет работаю в компании «Первый БИТ».

Немного про наш офис БИТ:ERP – это будет важно для дальнейшего повествования.

  • Мы работаем по проектам, которые ведутся по двум направлениям деятельности:

    • проекты на ERP – от 100 до тысячи пользователей;

    • и коробочные продукты.

  • У нас есть особенности:

    • мы изначально удаленщики;

    • и мы любим использовать разные новые технологии на практике.

 

 

Хочу рассказать про наш опыт:

  • как мы начинали работать с EDT, и к чему это привело сейчас;

  • как мы работаем с GIT;

  • какие инструменты мы придумали, чтобы упростить работу с GIT и с EDT для наших сотрудников;

  • как мы используем автотесты, и насколько это помогает нам при работе с GIT.

  • чем все закончилось, и как у нас все выглядит сейчас.

Давайте начнем.

 

Начало работы с EDT. БИТ.Адаптер

 

 

EDT мы начали использовать два года назад при разработке проекта БИТ.Адаптер. Это – идеальный проект для использования EDT.

Какие у него особенности?

  • Это – коробочный продукт.

  • Он самописный, в нем даже БСП нет. И небольшой – над ним одновременно работает небольшая проектная команда из одного-двух человек.

  • Мы всегда этот проект использовали как полигон для исследований. Два года назад мы внедрили на нем BDD с использованием Vanessa Automation, начали писать и запускать автотесты. Но у нас была одна проблема – нам никогда не удавалось добиться «зеленого» мастера, потому что при использовании конфигуратора и хранилища мы вначале помещаем изменения в хранилище, а потом тестируем. И в результате получается, что тесты часто не проходят – т.е. у нас в хранилище лежит конфигурация, на которой не проходят все тесты. Переходя на EDT с использованием GIT мы хотели побороть именно эту проблему, потому что GIT позволяет класть изменения в ветки, тестировать конфигурации в ветках, а в master класть уже консистентную конфигурацию.

 

 

Я заскриншотил, как все начиналось. Вот так выглядело появление нашей первой ветки с использованием GIT в ноябре 2018 года.

 

Следующий шаг – БИТ.MDT

 

 

Нашим следующим шагом в сторону использования EDT был выбор коробки побольше – это был наш продукт БИТ.MDT, я про него рассказывал на секции по мобильной платформе.

  • Продукт БИТ.MDT состоит из мобильной платформы и расширения для типовых конфигураций.
  • Он тоже небольшой – над ним одновременно работает 5-6 человек, из которых три разработчика. Мы начинали его делать год назад «с нуля».

При использовании хранилища мы видели следующие проблемы.

  • Так как при разработке «с нуля» добавляется куча новых объектов, возникала конкуренция за корень и за эти объекты, а EDT позволяет решить эту проблему.

  • И второе – нам нужно было выпускать релизы быстро и ритмично. И исправлять ошибки – быстро и ритмично. А хранилище плохо позволяет это делать, потому что все время в хранилище находится не до конца доделанные задачи и нужно потом вырезать из них работающее – из того, что в хранилище лежит, чтобы собрать релиз.

  • Кроме этого, мы хотели сразу же предотвратить проблемы – сразу использовать на этом проекте BDD. Хотели всегда получать «зеленый мастер», а EDT это позволяет делать – мы уже на Адаптере потренировались.

 

Проблемы при работе в EDT

 

 

Уже на проекте MDT мы столкнулись с проблемами при использовании EDT.

Когда мы в самом начале развития проекта MDT делали расширение, которое работало только для УТ11, проблем с производительностью особых не было. И команда тогда была маленькой. Четырех ядер и 16 ГБ оперативки на машине разработчика хватало всем.

Но когда мы в рамках проекта MDT начали делать в EDT расширение для ERP и затянули в него конфигурацию ERP, таких ресурсов уже для комфортной текущей работы хватать перестало.

  • Машина разработчика для использования ERP в EDT – это 32 ГБ оперативки, 8 ядер, и то, EDT ресурсы кушает неравномерно, в некоторых сценариях он кушает все ресурсы и тормозит. Но в большинстве случаев ресурсы простаивают, мы их не утилизируем полностью.

  • Следующая особенность – мы стали подключать к разработке «старых» сотрудников с других проектов. Они оказались не такие энтузиасты, как разработчики MDT, им EDT не понравился как среда разработки – непонятны термины, непонятный GIT, непонятный интерфейс.

  • И EDT нас тоже «радовал» разными редкими, но меткими ошибками. Основные проблемы, с которыми мы сталкивались, происходили при слиянии конфигураций, потому что мы использовали ветки и часто мержили их. А EDT любит ошибаться при мержинге. В результате получается неработоспособная конфигурация, которая EDT смержила. Это проявляется не сразу, а позже, когда вы уже попробовали протестировать то, что получилось.

  • Еще одна проблема, с которой мы столкнулись – это то, что EDT при выгрузке конфигурации в базу для тестирования неожиданно по сложным условиям хочет делать полную выгрузку. Если использовать платформенный механизм частичной выгрузки, выгрузка из EDT – это минуты. А если EDT решил делать полную выгрузку, то выгрузка базы ERP целиком из EDT, чтобы собрать базу – это один час по времени. А нам нужна ритмичная разработка.

Поэтому уже на этапе разработки MDT мы придумали некие свои механизмы, которые позволили нам вести разработку из конфигуратора, используя при этом тот же репозиторий, что и разработчики, которые работают в EDT.

 

Предпосылки перевода разработки проектов на ERP в EDT

 

 

Следующий этап – это перевод на EDT проектов по внедрению ERP. Мы перевели их на EDT осенью прошлого года.

Я уже говорил, что у нас много проектов по внедрению ERP от 100 до 1000 пользователей. Мы в основном внедряем типовую ERP – там доработок мало.

В проектной команде у нас в среднем 7 человек, из которых 3 разработчика, параллельно работающих с кодом в EDT – до этого они так же успешно работали с хранилищем.

С переходом на EDT мы на ERP-шных проектах хотели решить следующие задачи:

  • Ускорить донесение изменений релиза до заказчика. Мы работаем по скраму, длина спринта две недели, мы хотели выпускать релизы не реже, чем раз в две недели. А лучше – каждый день.

  • И хотели сократить количество ошибок, чтобы потом их в проде не исправлять.

 

 

Я здесь специально заскриншотил, как выглядел процесс сборки релиза и переноса изменений в прод раньше, при использовании хранилища.

Был такой магический отчет, который показывает, какие задачи, лежащие в хранилище, проверены успешно или неуспешно.

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

Этот процесс – сложный, трудоемкий, несет в себе кучу ошибок и т.д. От этого процесса мы хотели избавиться при переходе на EDT.

 

 

Как выглядит разработка на проектах по доработке ERP (идеальный сценарий)

  • Проект начинается с дорожной карты, формируется бэклог задач. Для ведения задач мы используем Jira.

  • Дальше, как я говорил, у нас скрам. Период планирования у нас 2 недели. И раз в две недели мы должны собирать релиз.

  • Разработка по каждой задаче ведется в EDT или Конфигураторе и помещается в GIT. Jira с GIT хорошо интегрируются – если в коммитах вы указываете номера задач, то дальше из Jira вы можете подтянуть весь код, который относится к этой задаче.

  • Изменения по всем задачам помещаются в ветки, и только того, как все задачи проверены, изменения из веток переливаются в мастер. Таким образом в мастере у нас гарантировано только работающий релиз. В любой момент времени можем из мастера собирать релиз для клиента, ему передавать – сложная операция «выкрыжить все неработающее из конфигурации» не требуется.

  • Также у нас используется так называемая staging-база – это копия рабочей базы заказчика, которая обновляется из веток. На ней мы демонстрируем задачу клиенту до того, как их мержить в мастер.

  • После того как задача продемонстрирована клиенту, проверена на ветке. Из ветки делается пул-реквест и задача попадает в мастер.

  • И среда разработки у нас отделена от рабочей среды. Из мастера мы собираем cf-файл, который дальше передаем в рабочую среду и накатываем там на рабочую базу, в рабочее хранилище и т.д. – в зависимости от того, как устроено.

  • Сама разработка у нас ведется либо в EDT (мелкие задачи) либо в конфигураторе через специальные скрипты изменения помещаются в GIT.

 

 

Напомню, ради чего затевался переход на EDT

  • Это быстрые релизы (от одного релиза в две недели до нескольких релизов в день)

  • И сокращение количества привнесенных ошибок

 

Как выглядит процесс разработки

 

 

Итак, переходим дальше – как у нас выглядит структура нашего репозитория на примере проекта MDT.

Мы используем моно-репозиторий. Что это такое? У нас в одном репозитории лежит сразу несколько конфигураций. Это касается как MDT, так и других проектов. Если проект подразумевает обмен между несколькими базами и одновременную разработку нескольких конфигураций, мы все эти конфигурации кладем в один репозиторий.

Что это позволяет сделать?

  • Во-первых, упростить саму разработку. Если нужно доработать обмен данных из одной базы в другую, у тебя обе конфигурации находятся в одном интерфейсе – ты можешь сразу подправить и в одном, и в другом модуле. Исправляешь в одном контексте.

  • Также ты можешь тестировать изменения, которые касаются нескольких баз, в отдельной ветке – тестировать в этой ветке обмен и все остальное. Это позволяет делать консистентные изменения.

  • Когда ты делаешь пул-реквест, у тебя за раз в мастер попадают изменения сразу во всех конфигурациях, которые на этом проекте используются. Это очень удобно.

На слайде показан пример с проекта MDT, но на проектах ERP подход аналогичный.

 

 

Как у нас выглядит процесс разработки?

Разработчик берет очередную задачу в Jira, и дальше у него есть два пути.

  • Если задача большая, то он в EDT создает отдельную ветку с номером задачи, подключает к ней отдельную базу, и дальше у него есть один час заняться какими-нибудь другими делами пока конфигурация базы подтянется к конфигурации ветки.

  • Если задача небольшая, у нас у разработчиков есть отдельная своя ветка для текущих работ, а к ней уже подключена отдельная база. В этой ветке разработчик может быстро исправлять мелкие задачи. Он просто обновляет свою ветку из master и актуализирует изменениями свою базу разработки – как правило, это происходит достаточно часто, поэтому полное обновление базы не требуется, ждать ничего не нужно.

И как я говорил, вся разработка ведется в отдельной ветке, в master напрямую никакие изменения класть нельзя.

 

 

В процессе разработки разработчик вместе с консультантом готовит новые BDD-тесты либо адаптирует существующие:

  • Для тестирования мы используем Vanessa Automation,

  • Тесты у нас лежат в том же репозитории, где и код – соответственно, у нас в одной ветке измененные тесты и измененный код. И одним пул-реквестом мы принимаем измененные тесты и измененный код.

После того как код написан, разработчик оформляет pull request в master:

  • еще раз забирает конфигурацию из master и мержит ее в свою ветку;

  • запускает тесты;

  • и только после этого делает pull request.

Такая последовательность обязательна, она позволяет избежать мерж-конфликтов на этапе мержинга, сокращает затраты на создание и работу с пул-реквестом

 

 

Принимается пул-реквест средствами того облачного репозитория, который вы используете.

  • Создается пул-реквест – его можно создавать сразу из EDT или из веб-интерфейса.

  • В тексте пул-реквеста мы сразу указываем ссылку на отчет Allure, который подтверждает, что тесты в этой ветке прошли. Сюда же в пул-реквест у нас также подключен SonarQube, чтобы сразу видеть ошибки в коде.

  • После проверки пул-реквеста тимлид мержит его в master.

 

Минусы разработки в EDT

 

 

С какими минусами, проблемами мы столкнулись, и зачем нужно сделать что-то еще.

  • Первая проблема – это то, что вносить изменения при помощи EDT получается медленнее, чем при использовании конфигуратора. В EDT очень неудобно отлаживать. Когда ты накодировал какую-то задачу и тебе нужно ее отлаживать – многократно запускать конфигурацию с мелкими изменениями – если это делать в конфигураторе, это делается достаточно быстро. А в EDT запуск отладки занимает значительно дольше времени, чем из конфигуратора. Поэтому наши разработчики стали жаловаться, что после того как ты написал задачу и ее нужно отладить с многочисленными повторными изменениями, из EDT это занимает гораздо больше времени. Но если ты разрабатываешь маленькие конфигурации, то проблемы нет – из EDT они запускаются с той же скоростью, что и из конфигуратора.

  • Дальше – про ошибки. Ошибки в EDT, связанные с мержингом, с полным обновлением – не исчезли, они так и остались. Свежий пример – в EDT 2020.6 наше решение в принципе не открывалось. Привнесли ошибку. А в EDT 2020.6.2 эту ошибку уже поправили. Т.е. ошибки EDT появляются и исчезают – в целом ситуация не сильно улучшается.

  • И обычные разработчики, которых мы привлекаем – «старые» 1С-ные разработчики – им с EDT сложно, они привыкли решать задачи клиентов, а не разбираться в новых технологиях и в EDT.

 

Скрипты, чтобы разрабатывать в конфигураторе, а вести разработку в GIT

 

 

Что мы сделали, чтобы решить эту проблему?

Обычная работа из EDT с GIT выглядит так: мы в EDT нажимаем кнопку «Получить изменения из GIT» и «Положить изменения в GIT». И дальше EDT все делает само – EDT фактически работает с исходным кодом как есть.

Мы сделали два скрипта, которые позволяют делать то же самое из конфигуратора. Эти два скрипта мы добавили как заявки в наш Service Desk.
 

Первый скрипт – поместить изменения в ветку


Что делает этот скрипт?

Разработчик разрабатывает в конфигураторе как обычно, отлаживается в конфигураторе. И хочет поместить свои изменения в GIT. Он в Service Desk запускает заявку и говорит: «Хочу поместить изменения из этой базы в эту ветку в GIT».

  • Скрипт делает копию базы – у нас базы SQL-ные, поэтому из конфигуратора выходить не нужно.

  • Из копии выгружает конфигурацию в файлы.

  • Запускает утилиту ring, которая конвертирует код в формат EDT.

  • И кладет ветку в GIT.

Таким образом, с одним и тем же репозиторием мы можем работать и из конфигуратора, и из EDT.

Часть разработчиков – молодые, модные, современные – работают в EDT, а часть разработчиков работает в конфигураторе и пользуется заявками в Service Desk
 

Второй парный скрипт – позволяет получить изменения из GIT в конфигуратор


Этот скрипт тоже представлен в виде заявки в Service Desk. При выполнении он:

  • получает исходный файл из GIT;

  • конвертирует с помощью утилиты ring в платформенную выгрузку;

  • забирает конфигурацию в cf;

  • и эту cf-ку отдает разработчику.

Дальше, если разработчик хочет эти изменения включить в конфигуратор в свою ветку, через Сравнение-Объединение он из этой cf эти изменения получает.

Таким образом, мы обеспечили работу с одним и тем же репозиторием – как с использованием конфигуратора, так и с использованием EDT.

Таким образом, мы можем подключать разработчиков, использующих разные инструменты при своей работе.

 

 

В каких случаях мы используем один подход, а в каких случаях – другой?

  • Новые сотрудники, которые с EDT не знакомы, которых мы привлекаем с других проектов, начинают работу с конфигуратора. А потом или переходят на EDT, или не переходят.

  • Мелкие простые задачи мы стараемся делать в EDT, потому что это сделать просто.

  • А длинные сложные задачи, которые делаются несколько дней (неделю или две недели), мы стараемся сейчас делать в конфигураторе.

  • Если в очередной версии EDT возникают какие-то проблемы, мы просто все переходим на конфигуратор и ждем, пока выйдет версия EDT, где эти проблемы исправлены. А потом часть людей возвращается назад на EDT. Т.е. мы в любой момент можем переключиться туда или сюда.

Важно отметить, что использование GIT очень хорошо сочетается с автотестами.

  • В EDT как только ты положил изменение в ветку, ты можешь автоматически их проверить и результаты приложить к пул-реквесту.

  • Наиболее эффективно работать с GIT когда ветки долго не живут – важно сразу, как только ты изменения в ветку внес, протестировать и положить в master. Потому что иначе в master успеют положить изменения другие разработчики или тебе придется тратить отдельное время, чтобы объединить твои изменения с чужими изменениями, которые там уже оказались.

  • А быстро помещать ветки в мастер позволяет как раз использование автотестов. Наши ушлые разработчики, особенно, когда изменение маленькое, вообще в режиме «1С:Предприятие» свои изменения не отлаживают. Он в EDT внес изменения в какой-то простейший модуль, положил в GIT, запустил автотесты и пошел заниматься другими задачами. Он в режиме 1С:Предприятие даже не запускал эту базу. Но автотесты прошли, все зеленое, изменения мержим в мастер.

Если вы будете делать такие скрипты у себя – на что хочу обратить внимание.

  • Желательно все кешировать. Как правило, разработчику нужно получать текущую конфигурацию из master-ветки, поэтому как только первый разработчик такой cf-ник с последним коммитом из master сформировал, мы можем сохранить его в кеше. И дальше, когда следующий разработчик захочет получитть текущую конфигурацию, мы можем сразу отдать ему готовый cf, а не формировать его заново. Это ускоряет работу с этими заявками.

 

Теперь о грустном – что у нас в результате получилось

 

 

Напомню, какие цели мы ставили – это ускорить выпуск релизов и сократить ошибки в продуктиве. На всех новых проектах, начиная с осени, мы попробовали использовать GIT и EDT.

С какими препятствиями мы столкнулись?

  • Когда у сотрудников появился выбор – пользоваться в качестве хранилища GIT, но кодить либо в конфигураторе, либо в EDT – выяснилось, что большинство сотрудников в качестве IDE выбрали кодить в конфигураторе. Сейчас по факту EDT использует где-то 10% наших сотрудников. А GIT используется на всех наших коробочных продуктах и только на 20% ERP-шных проектах.

  • Дальше выяснилось, что разработка с использованием GIT хорошо зашла на коробочных продуктах – там, где у нас используются автотесты. Это произошло из-за того, что нам удалось там поменять процесс разработки и выстроить его так, чтобы задачи делались быстро и ветки мержились в master быстро. У нас фактически на коробочных продуктах ветки больше 1-2 дней не живут, они попадают в master.

  • На проектах ERP так сделать не получилось, там автотестов нет, задачи проверяют пользователи, и ветки живут долго. Так как мы работаем спринтами, у нас есть план задач на спринт, на две недели. И получается так, что остается два дня до конца спринта, и большинство задач не в master, они проверяются или только что проверены пользователями. И в последние два дня всем разработчикам проекта нужно взять и смержить свои изменения в master одновременно. А что такое смержить изменения в master? Это сравнить и объединить свои доработки с теми изменениями, которые уже есть в master и потом только положить туда. Т.е. на ERP-проектах ветки живут до конца спринта, накапливается куча изменений и потом в конце спринта возникает очередь – все выстраиваются по одному, чтобы положить свои изменения в один общий мастер. Эту проблему мы пока победить не смогли.

Когда планируем сделать следующую попытку перейти в EDT в части ERP-шных проектов?

  • Первое – мы ждем, что EDT станет стабильнее и радикально быстрее работать с конфигурациями уровня ERP. Наша основная конфигурация – ERP, нам нужно, чтобы EDT стабильно и быстро работала с ERP.

  • Возможно, нам станет проще, когда разработку для ERP-шных проектов мы сможем вести только в расширениях. Сейчас расширения не поддерживают весь набор объектов, который есть в конфигурации, но если они будут поддерживать, то в принципе, работать с расширениями для ERP в EDT можно достаточно быстро, и проблем нет. EDT сохраняет только расширение – расширение, как правило, маленькое. Даже если в нем ведется много доработок по проекту, само расширение гораздо меньше, чем основная конфигурация. Поэтому если в ERP вы вносите изменения только в расширение, проблем со скоростью работы нет, в EDT работать можно.

  • И мы научимся делать эффективные автотесты, которые сможем использовать повсеместно на ERP-шных проектах.

 

Используйте CI/CD

 

 

Теперь немного про CI/CD и почему его важно использовать, если вы используете GIT и EDT.

  • Во-первых, это легко. У нас весь исходный код уже есть в репозитории, нам не нужно его ниоткуда брать, ниоткуда конвертировать.

  • Дальше – у нас запуск тестов сделан через отдельную заявку, тесты выполняются в отдельных базах и никак не мешают разработке. Разработчик разрабатывает в своей базе, положил изменения в ветку, запустил заявку на тестирование и все – дальше оно само где-то тестируется. Разработчика это никак от работы не отвлекает.

  • И, соответственно, при использовании автотестов можно быстро мержить ветки в master. А это является узким местом при использовании EDT и коллективной разработки. Вы можете быстро проверить свои изменения автоматически, не ожидая проверки от пользователей, и положить свои изменения в master.

  • И дополнительный бонус – EDT дает много возможностей по рефакторингу. И если у вас есть автотесты, рефакторинг гораздо проще делать, особенно в EDT, которая часто ошибается при рефакторинге. Т.е. вы что-то отрефакторили средствами EDT, запустили автотесты и убедились, что ничего не сломали. Без этого рефакторингом заниматься сложно.

 

Немного картинок

 

 

Покажу, как у нас это выглядит. На слайде – пример коммита, сделанного в репозиторий EDT.

 

 

Вот так выглядит наш Service Desk, из которого мы запускаем заявки.

  • Если этот коммит нужно протестировать, разработчик кладет изменения и запускает интерактивное тестирование в этой ветке.

  • Здесь же, в этом же Service Desk есть возможность получить cf-ник из GIT по команде «Собрать конфигурацию из ветки».

  • И здесь же есть заявки на помещение изменений в ветку, когда нам нужно из какой-то базы поместить изменения в ветку.

Разработчик пользуется этим Service Desk, чтобы работать с GIT. В принципе, разработчику не нужно знать ни команды работы с GIT, ни разных особенностей работы GIT. В общем случае, он пользуется конфигуратором и пользуется заявками.

 

 

Вот так у нас выглядит заявка на запуск интерактивного тестирования.

Пользователь выбирает, по какому проекту из какой ветки взять тесты, из какой ветки взять код, и запускает тесты на копии своей базы.

 

 

В результате после того как все тесты прошли, разработчику приходит об этом сообщение. У нас все уведомления уходят через Slack – это наш основной мессенджер.

 

 

И дальше отсюда же из Slack разработчик идет в отчет Allure, находит, где именно упало, исправляет код, заново кладет его в репозиторий и заново запускает тесты. Процесс разработки в картинках выглядит таким образом.

При этом неважно, где разработчик кодит – он может это делать либо в конфигураторе, либо в EDT, но изменения все попадают в один и тот же репозиторий.

 

Выводы

 

 

Какие выводы можно сделать из всего этого?

  • На данный момент самый идеальный вариант для использования EDT на нашем опыте – небольшие самописные конфигурации, над которыми работает один-два, максимум три человека. В этом случае никаких проблем не будет, использовать можно, никаких сложностей, все отлично.

  • EDT можно использовать и для более крупных проектов, в том числе для ERP. Но в этом случае требуются разные ухищрения. Например, наши скрипты, которые позволяют из конфигуратора помещать изменения в репозиторий и извлекать изменения из репозитория. И прочие фишки – можно к каждой ветке привязывать отдельную информационную базу в EDT, в этом случае между ветками можно быстро переключаться, не ждать кучу времени.

  • Дальше – разработка с использованием GIT хорошо сочетается с автотестами. Во-первых, проще принимать пул-реквесты, потому что они автоматически проверены, и можно делать короткоживущие ветки, которые потом просто мержить.

  • И хорошо использовать некий свой Service Desk или некий интерфейс, куда можно спрятать всю сложность работы с GIT от разработчиков, и пользоваться просто заявками из Service Desk.

 

Вопросы

 

Почему вы использовали какой-то свой Service Desk при наличии Jira? Там же тоже есть все компоненты CI/CD.

В 2020 году еще мы использовали Service Desk в Jira Server, у нас была доработанная функциональность – доделаны эти заявки с запусками по плану и т.д. Но, как вы знаете, с 2021 года Jira стала только облачной, они больше десктопные серверные лицензии не продают. Поэтому в связи с общей политикой Jira мы решили, что мы переедем в облако, кучу кода, который был написан для старого Service Desk, выкинем и будем пользоваться простеньким 1С-ным Service Desk.

Но кроме Jira можно же использовать в GitLab компоненты CI/CD – runner и все эти моменты?

Но мы же говорим про интерфейс, с которым работают конечные разработчики – им нужно по-простому быстро что-то запустить. Конфигурация на 1С – это временное решение, связанное с тем, что мы переезжали с нашего Service Desk в Jira Server. Сделали себе по-быстрому в 1С такой же интерфейс.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.

Больше статей можно прочитать здесь.

 


 

*************

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user1203706 01.09.22 22:39 Сейчас в теме
Так и запишем, EDT-в топку.
KilloN; pbahushevich; zannv; alexey-simf; kotlovD; Tigreno; 7OH; user1827801; SinglCOOLer; lunjio; immemor; papami; vano-ekt; asupsam; Yashazz; smit1c; Eugene_Elhaz; bykov.vsl; mrChOP93; PowerBoy; rpgshnik; sys1c; +22 1 Ответить
2. mrChOP93 82 02.09.22 06:39 Сейчас в теме
У меня есть прекрасная традиция: раз в год разворачивать EDT и, спустя пару дней, заворачивать ее обратно) Интересно, когда нибудь она выйдет из состояния вечной беты?
KilloN; user990914; lmm; NikeeNik; 7OH; Jeka44; kostik_love; Silenser; al.gerasimov; lunjio; rpgshnik; Eugene_Elhaz; +12 Ответить
3. kauksi 209 02.09.22 10:08 Сейчас в теме
(2) аналогично. EDT явно для мэйнфреймов )
20. KilloN 47 24.10.22 15:54 Сейчас в теме
(2) Как я тебя понимаю 3 раза разворачивал ((
4. booksfill 02.09.22 14:14 Сейчас в теме
В очередной раз получил подтверждение тому, что использовать EDT станет реально только после того как это станет единственным средством разработки коробочных продуктов в самой 1С и, соотв-но, за него возьмутся всерьез.

Потрачены тысячи часов дорогих разработчиков на С++ для разработки конфигуратора, для разработки и поддержки нормальной IDE потребуется не меньше, а денег хочется здесь и сейчас, да и страшно трогать тонны залежей легаси кода.

Теперь о веселом - а все равно сделают, т.к. выхода нет, а перспективы открылись серьезные.
По мере ухода с рынка "больших" игроков, и, соотв-но появления больших же свободных денег, у 1С не получится по-новому оставить все по-старому. Иначе найдутся те, кто сочтут целесообразным серьезно вложиться и предложить что-то лучше.
lunjio; rpgshnik; +2 Ответить
6. smit1c 106 02.09.22 15:31 Сейчас в теме
8. booksfill 02.09.22 16:36 Сейчас в теме
(6) Если есть перспектива заработать большие деньги, не имеет смысла гадать "откуда найдутся", есть смысл гадать "как быстро".
Разумеется, это IMHO, основанное на доступных познаниях как "это всегда было".
5. quazare 2592 02.09.22 15:28 Сейчас в теме
Меня всегда поражало - команда позиционирует себя как профессиональных разработчиков - лидеры отрасли и пишут - мы разрабатываем расширение…. 16 гб оперативки хватало всем….
9. roman72 306 02.09.22 17:43 Сейчас в теме
Много проблем с мёрджингом можно устранить, если перенести ряд решений по технологии разработки на стадию нарезки задач разработчикам и на ещё более раннюю стадию проектирования.
10. vano-ekt 850 03.09.22 07:57 Сейчас в теме
в 2015 было понятно, что никуда этот эклипс не вырулит 🤦‍♂️
pbahushevich; SinglCOOLer; al.gerasimov; lunjio; immemor; rpgshnik; +6 Ответить
11. triviumfan 37 03.09.22 12:09 Сейчас в теме
А кто-нибудь дочитал до конца?
pbahushevich; tolyan_ekb; Strobe; Krotov_Valery; check2; immemor; +6 Ответить
12. immemor 03.09.22 14:21 Сейчас в теме
я как то купил курс по ЕДТ , что бы быстро научится , это было пол года назад , месяц на нем проработал и забыл как страшный сон. Для командной разработки возможно это шаг вперед , но для программиста одиночки это лютый гемморой.
Очень забагованая и нестабильная штука.
KilloN; pbahushevich; smit1c; mrChOP93; +4 Ответить
13. lunjio 65 03.09.22 18:33 Сейчас в теме
(12)
я как то купил курс по ЕДТ , что бы быстро научится , это было пол года назад , месяц на нем проработал и забыл как страшный сон. Для командной разработки возможно это шаг вперед , но для программиста одиночки это лютый гемморой.
Очень забагованая и нестабильная штука.

Он мог уже за пол года устареть достаточно.
14. kostik_love 303 05.09.22 11:42 Сейчас в теме
Может правильнее будет в конфигураторе добавить возможность работать с гит-хранилищами и подключать дополнительные плагины для проверки кода и всякие плюшки отдельные добавлять)?
16. kotlovD 81 08.09.22 12:46 Сейчас в теме
(14) Возможность работать с гитом из конфигуратора - есть.
Выгрузить конфигурацию в файлы, указываешь папку локального гит репозитория, предварительно чекаут на нужную ветку. Далее PR в облако
Загрузить конфигурацию из файлов , предварительно все затягиваешь из облачного репо в свой локальный и из него грузишь конфигурацию, понятно что все тек доработки будут потеряны, это надо сделать до страта работы по задаче. Если надо промежуточно забрать к себе изменения в конфигуратор, то как в статье описано - забираем изменения из облачного репо, варим себе cf и руками объединяем.

Примерно так у ТС и работают заявки в SD, описанные в статье. Конечно в ручном режиме, все это очень не стабильно - большое пространство для ошибки, ведь надо не забывать делать переключения между ветками, затягивать, помещать, мержить.
15. 7OH 67 07.09.22 00:23 Сейчас в теме
Радует, когда в самом начале завязка на то, с чем работают единицы - не типовая или самописная база.
А вот когда дело доходит то самого нужного - для работы с базой на поддержке и прочими прелестями (особенно когда базе есть неподдерживаемые ЕДТ объекты) - вот тут всё возвращается к истокам - к вопросу - зачем она нужна основной массе ?
KilloN; kostik_love; +2 Ответить
17. Begemoth80 239 09.09.22 13:52 Сейчас в теме
(15) Как подружить типовые конфигурации и GIT, будет на инфостарт ивент в этом году :-) Общие принципы те-же, но есть "набор костылей"
18. KUAvanesov 09.09.22 15:22 Сейчас в теме
Забавно видеть свою фамилию на скриншотах спустя 1.5 года))
19. Begemoth80 239 09.09.22 19:10 Сейчас в теме
(18) Ну так это же прошлогодние выступления опубликовали ;-)
Оставьте свое сообщение

См. также

1C:Enterprise Development tools (EDT) или кодим в Eclipse Промо

EDT Платформа 1С v8.3 Бесплатно (free)

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

11.04.2015    81499    DitriX    297    

С конфигуратора на EDT. Привычки, которые придется поменять

EDT Языки и среды Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Решил перейти на EDT, чтобы повысить эффективность разработки? А теперь приостановись и выдохни! Я расскажу сейчас о том, из-за чего многие новички в EDT (будучи матёрыми кодерами в конфигураторе) воспринимают встречу с новшествами так, будто их с велосипеда пересадили за штурвал Боинга.

16.09.2021    10212    stas_ganiev    19    

1C: EDT: фиксим баги доработанной и устаревшей конфигурации УТ

EDT Платформа 1С v8.3 8.3.14 1С:Управление торговлей 11 Россия Управленческий учет Бесплатно (free)

В этом году у меня появилась возможность использовать 1С: EDT весь рабочий день. В работе конфигурация УТ 11.1, прилично доработанная. Целиком перейти на актуальную конфигурацию УТ 11.4 проблематично, поэтому переходим кусочками в ходе текущих работ.

13.08.2021    1914    pa240775    4    

1С:EDT. Куда пинать, чтобы полетело?

EDT Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 Россия Бесплатно (free)

Работал в 1С Конфигуратор и решил перейти на 1С EDT. Не получилось сразу. Потребовалась модификация компьютера.

19.08.2020    8520    pa240775    39    

Unit-тесты с помощью 1C:Enterprise Development Tools

EDT Платформа 1С v8.3 Бесплатно (free)

Концепция TDD требует перестроения подходов к разработке и наличия инструментов для запуска Unit-тестов. Про написание плагина для EDT, который содержит в себе инструменты написания, анализа результатов и запуска Unit-тестов для конфигураций 1С на конференции Infostart Event 2019 Inception рассказал ведущий специалист по внедрению компании 1С-Рарус Александр Капралов.

11.06.2020    7707    doublesun    9    

Enterprise Development Tools, версия 2020.2 для мобильной разработки. Бег по граблям (серия публикаций от чайника для чайников)

EDT Мобильная платформа Конфигурации 1cv8 Бесплатно (free)

Небольшие советы, которые сберегут время при работе с Enterprise Development Tools, версия 2020.2.

10.04.2020    6270    capitan    10    

Как мы разрабатываем в EDT

EDT Платформа 1С v8.3 Бесплатно (free)

EDT – это новая среда разработки, на которую сейчас перешли разработчики фирмы «1С». Однако до сих пор существует ряд «белых пятен», касающихся как теоретической, так и практической части применения этого инструмента. Про опыт перехода на разработку в EDT на конференции INFOSTART EVENT 2018 EDUCATION рассказал начальник сектора разработки в компании «Группа Полипластик» Владимир Крючков.

23.08.2019    17828    ivanov660    31    

1С:EDT. Первые шаги… или есть ли альтернатива конфигуратору?

EDT Платформа 1С v8.3 Бесплатно (free)

Заменить конфигуратор сложно, а в некоторых случаях невозможно, если, например, нужно оперативно подправить код непосредственно в рабочей конфигурации…

15.08.2019    47897    ellavs    115    

Взгляд на практику разработки в EDT из зазеркалья

EDT Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье расскажем о практическом опыте использования разработки в EDT: немного про интерфейс, командную разработку и GIT.

26.07.2018    30639    ivanov660    116