Проблемы при внедрении и разработке проектов 1С
В мире 1С я вращаюсь более 17 лет. При внедрении и разработке проектов на базе 1С всегда возникают различные проблемы. Часть этих проблем решается вручную, часть – автоматически.
Как правило, проблемы повторяются. Но решать те проблемы, которые часто повторяются, приходится:
- Долго;
- Дорого (потому что слишком часто);
- Неинтересно.
И они превращаются в рутину.
Если проблема превращается в рутину, которой заниматься неинтересно, мы часто отдаем ее так называемым «невезучим» людям или юным специалистам-падаванам.
Я считаю, что проблему, которая повторяется, нужно обязательно автоматизировать. Или, в крайнем случае, документировать.
Многообразие инструментов для автоматизации рутины
Для автоматизации рутины, возникающей в мире разработки 1С, есть очень много инструментов. Почему так получилось?
- Потому что проблем возникает много – у заказчиков всегда много запросов и различных потребностей;
- Создавать единый инструмент, который решает все проблемы, достаточно сложно, и, как правило, неэффективно;
- Поэтому под конкретную задачу часто делается конкретный инструмент. И когда у специалиста возникает эта конкретная задача, он, как правило, выбирает именно тот инструмент, который наиболее подходит для ее решения;
- В итоге возникает множество инструментов.
Это важно понимать, потому что у меня будет много информации, придется пробежаться некоторым образом «галопом по Европам». Но я постараюсь на каждый инструмент одну-две минуты выделить.
Немного воспоминаний:
Темой подбора, использования и классификации инструментов для разработки в 1С я занимаюсь достаточно давно. Еще в 2010 году я провел многомесячную работу, подготовился, заодно отправил жену в роддом и 10 февраля выпустил свою статью на тему своего выступления. Статья называется «Повышение удобства разработки в “1С:Предприятии”».
А 11 февраля жена подарила мне подарок – у меня родился третий ребенок.
Эти два события для меня по степени важности сейчас находятся рядом!
Прошло семь лет, дочь пошла в школу. Теперь можно подвести итоги – чему же мы за эти 7 лет научились, какие инструменты появились у нас за это время и какие мы используем до сих пор.
На этом слайде я попытался представить «облако тегов» из инструментов, методик и концепций, которые я использую в своей работе. Размер тега здесь зависит от частоты использования инструмента и частоты упоминаний о нем. Наиболее крупно выделены техники, которые всем наверняка знакомы – это тестирование, автоматизация, дымовые тесты, CI/CD (возможно, этот термин большинство из присутствующих тоже уже знает). Останавливаться на этих определениях я сейчас не буду, постараюсь подробнее рассказать о них на следующих слайдах.
Классификация проблем
Проблемы, требующие автоматизации, я разделил на несколько блоков и буду рассказывать о них поэтапно.
Первый блок – это разработка, затем тестирование, потом – развертывание и администрирование в разных видах.
На самом деле эти блоки сильно между собой связаны, но я постараюсь рассказать о них по отдельности.
Разработка
Какие же инструменты есть для автоматизации разработки?
Условно можно разделить разработку на три этапа – это проектирование, прототипирование и сама разработка (кодирование). С функцией прототипирования у нас отлично справляется конфигуратор.
- Для проектирования можно использовать различные инструменты:
- Рисовать карту маршрута бизнес-процесса в конфигураторе. Мы недавно на двух проектах сразу рисовали бизнес-процессы в конфигураторе, а потом реализовывали для них программную часть;
- Использовать для проектирования «1С:Документооборот» или какие-то другие инструменты – ничего конкретного я сейчас рекомендовать не буду.
Теперь непосредственно о разработке. При разработке у нас возникает много различных проблем.
- Помимо кода конфигурации у нас есть различные тексты и коды – это, например:
- Документация;
- Внешние отчеты и обработки;
- Какие-то тестовые сценарии;
- Командные файлы, которые нам нужны для выполнения каких-то действий.
- Файлы настроек и т.д.
Все это нужно учитывать, хранить и использовать в коллективной разработке.
Как правило, над проектом в 1С работают не один-два человека, а больше. В небольших командах, конечно, может быть и один разработчик, но, как правило, все-таки больше. Поэтому требуется организация коллективной разработки.
И есть потребность, чтобы весь этот набор текстов и файлов версионировался. Чтобы всегда можно было получить актуальную версию от другого разработчика, или «откатиться» на предыдущую версию, если возникли какие-то проблемы.
Также нам нужно, чтобы все наши изменения были привязаны к конкретным задачам, которые возникают при ведении проекта. Например, чтобы мы могли провести аудит и понять, какие изменения были сделаны в рамках определенной задачи, чтобы дальше с этой задачей мог разбираться другой специалист, а не только автор, вносивший изначальные изменения.
Первое действие, с которого необходимо начать при разработке, – это подготовить проект.
Сейчас есть такая парадигма, что все должно являться кодом – все тексты, все описания, все командные файлы – все это код, все это нужно учитывать и версионировать.
Обязательно нужно выстроить структуру проекта – разложить его файлы по определенной структуре папок:
-
- Здесь будут находиться исходники конфигурации;
- В этом месте – исходники различных вспомогательных инструментов;
- Здесь – настройки,
- Здесь – тестовые сценарии и т.д.
Для подготовки проекта у нас есть инструмент, который предлагает наиболее удобную и проверенную структуру проекта, показывает, как разложить файлы по каталогам – для наших команд это уже некий стандарт. Название этого инструмента vanessa-boostrap.
Итак, все файлы проекта мы учитываем в одном месте/репозитории. У нас есть хранилище 1С, где мы ведем разработку конфигурации. Дополнительно у нас есть внешние обработки, расширения и т.д., которые в хранилище не помещаются. Здесь приходят на помощь другие системы версионирования. Часто используется Git.
Система версионирования Git
Git – это система версионирования.
- Она позволяет вести историю различных текстовых файлов.
- На скриншоте показано, как выглядит просмотр файла в Git:
- Видно, кто, когда, какие строки, и в связи с какой задачей менял;
- Мы можем видеть автора конкретной строки кода – этого вообще нет в хранилище конфигурации.
- Git – это сейчас практически стандарт системы версионирования для всех сред разработки. При использовании Git у нас появляется уверенность в том, что мы данные сохранили. Помните, есть пословица – «все люди делятся на тех, кто еще не делает бэкапы, и тех, кто уже делает бэкапы». Здесь мы всегда автоматически сохраняем все свои данные.
- И работа через Git является основой для других инструментов. Чуть позже я расскажу об этом подробнее.
Есть несколько способов положить исходники в Git.
Основное, с чем мы работаем – это, конечно, исходники конфигурации. И главный путь коллективной разработки, который мы предлагаем – это работа в хранилище 1С. Помещение в хранилище выполняется штатным образом в конфигураторе. Затем вступает в действие инструмент, который называется gitsync.
Gitsync – это средство для автоматического переноса истории изменений из хранилища 1С в хранилище Git. Переносится все:
- Изменения;
- Модули, формы и прочее из метаданных;
- Имя автора коммита/помещения;
- Время коммита/помещения.
В результате в репозитории Git оказываются все наши исходники, и для них выстраивается вся история разработки, полностью аналогичная той, что в хранилище 1С.
Gitsync может работать в фоновом режиме, т.е. не занимая ресурсы разработческих машин – независимо от разработчика или команды разработчиков. Например, его можно развернуть на отдельном небольшом сервере или виртуалке, и далее настроить его периодический запуск для синхронизации хранилища 1С и репозитория Git.
Следующий инструмент, precommit1C, служит для того, чтобы выкладывать в репозиторий Git внешние файлы. Это могут быть внешние обработки, внешние отчеты и расширения.
Такая операция выполняется при ручном помещении необходимых внешних файлов в Git с помощью команды git commit. При этом инструмент precommit1C автоматически разбирает внешние обработки, внешние отчеты и расширения на исходники с помощью типовых средств конфигуратора.
Очень важно, что и gitsync, и precommit1С используют штатные средства конфигуратора. Затем полученные исходники можно через конфигуратор загрузить обратно во внешние бинарные файлы.
Потребности разработки в конфигураторе
Переходим к тем потребностям, которые возникают у нас непосредственно при разработке в конфигураторе.
Очень важно быстро писать код. Я специально несколько раз буду употреблять слово «быстро», потому что мы при разработке должны выпускать систему быстро. Разработчики всегда дорогие. Если они не будут быстро писать код, то будут тратить много времени и дорого обходиться заказчику.
Также важно быстро читать код. Есть такая теория – код больше читается, чем пишется. И далее – навигация по коду тоже очень важна. Как раз для использования чтения.
Более конкретные примеры потребностей:
- Быстрый список методов модуля. Кто пользуется в конфигураторе списком процедур и методов? Удобно пользоваться этим инструментом? Я лично не пользуюсь этим инструментом очень давно – лет 10 уже, потому что он абсолютно неудобен и устарел. Есть другие – я далее покажу.
- Быстрая навигация по метаданным. Не ходить по дереву, не щелкать мышкой по группам, чтобы раскрыть, добраться и т.д. Удобнее набрать буквально три-четыре символа и быстро перескочить. Есть такие инструменты.
- Быстрый глобальный поиск. В конфигураторе функция глобального поиска тоже устаревшая – там нет быстрого поиска. Поиск происходит очень медленно. Однако есть другие инструменты, которые решают эту проблему.
- В конфигураторе есть отличная контекстная подсказка. Она развивается. Но также есть сторонние инструменты, которые помогают нам выполнить эту потребность.
Инструменты для работы с кодом
Переходим непосредственно к инструментам для работы с кодом.
Главный инструмент – это, конечно, конфигуратор. Как я уже говорил, мы работаем с хранилищем 1С, разрабатываем в конфигураторе, отлично прототипируем и т.д. Но, к сожалению, наш конфигуратор устарел уже на 10 лет, как минимум. И многих возможностей в нем не хватает.
Есть инструмент, который дополняет работу с конфигуратором – это EDT. До 13 сентября у меня здесь стояли знаки, обратные тем, что на слайде – сначала стоял вопросительный знак, а потом восклицательный. Но 13 сентября, на День программиста, «1С» сделала нам отличный подарок и выпустила финальный релиз EDT. Поэтому я переставил знаки местами. Хотел оставить только один восклицательный знак, но при запуске финальной версии все равно возникают различные проблемы.
И вообще EDT у меня ассоциируется с картинкой, которую я здесь подобрал специально для Питера. Это знаменитый питерский долгострой. EDT – это тоже некий долгострой. Отлично, что выпущена финальная версия, очень здорово. Но есть проблемы – ждем, когда 1С их исправит.
Вообще, мы верим в EDT, мы даже в нашей команде разрабатываем плагин для EDT с кодовым названием «СнегоЕд».
Нужно расшифровывать, почему «СнегоЕд»? Восьмерка у нас очень похожа на снеговика – вот вам «Снего». А «Ед» – это EDT. Вот и родился «СнегоЕд».
Следующие инструменты – это «расширители» конфигуратора. Они нужны, когда мы работаем в конфигураторе, но используем другие, сторонние инструменты.
Все знают, что это такое Снегопат? Я на текущем слайде поставил к нему со всех сторон вопросы, потому что Снегопат с 8.3.11 не работает, по поддержке есть вопросы. Но он дал нам очень много в плане сценариев использования. Там есть быстрый список методов, который отлично работает, быстрая навигация и т.д. Я верю, что в Снегопате произойдут изменения, и мы снова сможем все это использовать.
Следующий инструмент, про который я хотел бы рассказать – это SmartConfigurator.
Здесь уже точно нет никакого нарушения лицензии. Инструмент работает исключительно на поиске окон через Windows API и на передаче нажатий. В этом инструменте реализованы очень многие возможности – список методов, быстрая навигация, автоформатирование и т.д. Причем он написан на языке OneScript, и к нему можно добавлять собственные расширения. Это некий конкурент, аналог Снегопата, но бесплатный и опенсорсный.
Правда к нему тоже есть некоторые вопросы, поэтому я сам его не очень часто использую, а все-таки пользуюсь другими инструментами.
Кто-нибудь использует шаблоны в конфигураторе? У кого больше одного стандартного шаблона? Когда я приходил в разные компании, для меня было удивительно, что разработчики 1С не пользуются шаблонами вообще, хотя в них есть очень много интересных возможностей для ускорения написания кода. Если не использовать Снегопат, SmartConfigurator, EDT, то шаблоны в достаточной мере могут помочь быстрее написать код.
Еще один инструмент, который я вам хотел показать – это Visual Studio Code.
Это редактор от Microsoft, опенсорсный инструмент, абсолютно бесплатный. Он современный, не так давно появился.
Как видите, он разительно отличается от конфигуратора. Во-первых, темная тема оформления. Кто любит темные темы? В конфигураторе при использовании темной темы все-таки будут светлые тона.
Однако Visual Studio Code – это, конечно, не полная замена конфигуратора. Здесь нет прототипирования, разработки форм, СКД и т.д. Этот редактор нужен только непосредственно для кодирования.
Работает очень быстро. Для больших конфигураций типа ERP и «Управление холдингом» я пользуюсь поиском исключительно в Visual Studio Code. Gitsync разбирает конфигурацию на исходники, после этого я перехожу в Visual Studio Code и выполняю поиск. Ответ получается мгновенный, по щелчку. Есть разные варианты поиска:
-
- С помощью регулярных выражений, которые я очень люблю;
- Поиск по целому слову;
- Поиск с учетом регистра.
Также есть множественное выделение, которого в конфигураторе нет. Это очень удобный инструмент, когда можно выделить несколько слов, и во всех выделенных словах у вас в одном и том же месте будет гореть курсор, и вы сможете тут же что-то набрать. Например, подставить из буфера, убрать любой знак, полностью переписать слово. Выглядит очень красиво.
VS Code позволяет качественно выполнять операции замены. Этот инструмент легко расширяемый. В отличие от конфигуратора, для которого нет ни одного расширения (если не говорить про Снегопат), здесь куча различных плагинов.
В частности, на базе плагинов для VS Code можно работать с кодом 1С.
Есть плагин Language 1C(BSL), который добавляет в VS Code поддержку кода 1С. Благодаря ребятам, которые сделали этот плагин, код 1С (*.bsl) признали в мировом сообществе, и теперь на GitHub мы можем видеть код 1С автоматически раскрашенным.
Также на слайде перечислены другие плагины, которые мы используем в Visual Studio Code. Останавливаться на них подробно я сейчас не буду.
Качество кода и код-ревью
Когда мы написали код, у нас возникает очередная проблема. Потому что код – это вещь не простая. С ним нужно работать – им нужно владеть, им нужно управлять.
Как правило, при работе в команде желательно общее владение кодом, чтобы не было ситуаций, когда только один человек имеет право изменять код. Потому что в этом случае появляется зависимость от этого человека, он не может даже уйти в отпуск. Для компании это плохо – много проблем. Лучше использовать общее владение кодом. Для этого используется Git-сервер на основании наших исходников.
Код – это тоже некий артефакт, который нужно обязательно проверять. Нужно выполнять Code Review – согласно стандартам команды, согласно стандартам 1С. Но часть проверок превращается в рутину, тем более что Code Review – это очень дорогая операция, потому что здесь должны участвовать два человека – тот, кто написал код, и тот, кто проверяет код. Желательно рутину из Code Review также автоматизировать. Для этого в нашей команде был сделан плагин Sonar-BSL.
Sonar-BSL – это плагин для сервера SonarQube. Он работает очень быстро.
Кто знает, что такое АПК? АПК – это «Автоматизированная проверка конфигурации», инструмент, который позволяет выполнять статический анализ кода. К сожалению, когда мы запустили анализ в АПК для такой конфигурации, как ERP, у нас на достаточно хорошей машине на это ушло 40 часов! А наш плагин разбирает ERP за час. Можете самостоятельно рассчитать разницу в производительности.
Результатом работы Sonar-BSL является список нарушений стандартов кодирования. Его пример приведен на скриншоте. Обнаруженные ошибки могут быть совершенно неожиданными:
Например, до использования Sonar-BSL, я всегда применял конструкции НачатьТранзакцию и ЗафиксироватьТранзакцию совершенно по-другому. А оказывается, у 1С есть стандарт, запрещающий использовать установку транзакции вне блока Попытка-Исключение.
Участки кода, где используется НайтиПоНаименованию, будут показаны, как ошибки. Использование этой конструкции – стандартная проблема начинающих разработчиков.
Также Sonar-BSL умеет работать с метаданными и запросами – может проверять запросы на валидность и подсказывать, какие конструкции в запросе будут работать неоптимально.
На текущем слайде показаны очень красивые и полезные метрики:
- Уязвимости;
- Конкретные ошибки;
- Просто некачественный код, который не является серьезной ошибкой, но может повлиять на систему.
Слева показаны общие проблемы для всего проекта, а справа – те новые проблемы, которые возникли при последнем помещении в хранилище.
Проверка кода работает через Git, как и другие инструменты. Мы поместили что-то в Git (через хранилище 1С или как угодно), и видим, какие проблемы у этого кода. На данном скриншоте видно, что у нас 3 новые ошибки, 0 уязвимостей и 2 дня технического долга. Очень полезная информация для менеджеров и технических лидеров.
Есть возможность использовать Sonar-BSL в качестве подсказки в процессе разработки:
- С помощью плагина Sonarqube-inject-VSC вы можете увидеть все свои ошибки непосредственно в процессе кодирования в Visual Studio Code.
- И для EDT – не прошло и суток, как наша команда выпустила плагин SonarLint, чтобы можно было проверять код 1С в EDT.
Потребности тестирования
Переходим к тестированию. В тестировании тоже есть свои проблемы и потребности:
- В тестировании всегда много проверок;
- Проверки разные – ручные, автоматизированные, автоматические;
- Даже если эти проверки автоматические, они могут отнимать много времени. А ручные проверки отнимают очень много времени. Соответственно, проверки очень дороги;
- И часто возникает потребность получать отчеты, чтобы оценивать:
- Как обстоит дело с качеством системы;
- Как обстоят дела с проблемными участками и т.д.
Посмотрим, какие инструменты помогают решать проблемы тестирования.
Здесь, как вы видите, «облако» достаточно небольшое. Я использую три инструмента:
- Vanessa Behavior – инструмент для тестирования поведения. Я думаю, что многие его уже знают;
- xUnitFor1C – инструмент для тестирования модулей. Тоже не буду останавливаться подробно;
- В рамках xUnitFor1C мы активно используем инструмент, который называется «Дымовые тесты». Он позволяет, не написав ни единой строчки кода, проверить поведение вашей системы. Используя одно только дымовое тестирование, вы можете проверить 7-15% функционирования вашей системы. Это очень хороший показатель.
- Еще один инструмент, который мы используем в своей работе – это Vanessa-Runner. Это инструмент по автоматизации действий с конфигуратором и исходниками. С его помощью реализуется:
- Автоматическая загрузка расширений;
- Автоматическая загрузка исходников конфигурации в какую-то базу;
- Выгрузка исходников и т.д.;
- Помимо этого, Vanessa Runner можно использовать для автоматического запуска тестирования с помощью инструментов Vanessa Behavior и xUnitFor1C.
Еще один интересный инструмент тестирования – это Allure. Он позволяет получить отчетность на базе тех инструментов, про которые я сказал – xUnitFor1C и Vanessa Behavior. На слайде показано:
- Общее состояние системы;
- Сколько у нас вообще тестовых сценариев;
- Сколько из них проходит;
- Сколько не выполняется.
И очень красивый тренд справа. Видно, как меняются результаты тестов с течением времени.
Проблемы развертывания
Переходим к развертыванию. Здесь также возникает множество проблем.
- При развертывании, как правило, желательно использовать релизное управление – разворачивать setup.exe конкретной версии. Подавляющее большинство коллег развертывает боевые базы из хранилища, но это может вызвать множество проблем. Поэтому мы в части наших проектов не используем хранилище, которое подключено к боевой базе, а используем именно выпуск релиза, который затем в режиме поддержки устанавливается на боевую систему.
- Также при развертывании часто нужно выполнять много действий. Например:
- Договориться о регламентном времени;
- Отключить пользователей;
- Выполнить обновление системы;
- Выполнить миграцию данных;
- Потом снова запустить пользователей;
- Проверить, правильно ли у нас выполнилась миграция и т.д.
- Иногда необходимо выполнить быстрое исправление – внести исправление незамедлительно и в короткие сроки, если что-то пошло не так.
Вот инструменты, которые мы используем для автоматизации развертывания.
- Packman – это инструмент для подготовки тиражируемой конфигурации 1С.
- Он позволяет выпустить тот самый setup.exe, который можно использовать для релиза.
- Deployka – это инструмент для развертывания файлов поддержки на конкретных боевых или тестовых базах.
- С его помощью можно выгонять пользователей, разрешать работать в системе, выполнять загрузку базы и т.д.
- Инструмент xUnitFor1C, о котором я уже говорил, позволяет выполнить некие проверки.
- Например, с его помощью мы можем убедиться, что у нас прошла миграция. Для этого мы пишем некие тесты, которые выполняются именно в боевой базе.
- Кто знает, что такое ПИР? Или ИР – инструменты разработчика?
- Инструменты разработчика – это очень полезный инструмент, за который Сергей Старых уже получил свою награду на конференции Инфостарта. Хотя этот инструмент не работает в управляемых формах, зато он отлично выполняет огромное количество задач и приносит громадную пользу. Я всем его рекомендую.
Инструменты для 1С:Предприятия
В качестве инструментов для «1С:Предприятия» я рекомендую использовать опять же:
- Портативные инструменты разработчика – те, которые работают в любой конфигурации. Если у вас есть возможность внесения изменений в конфигурацию, вы можете использовать Инструменты разработчика, как подсистему. И еще не так давно Сергей Старых выпустил расширение – оно также может использоваться в любой конфигурации;
- Еще один инструмент – это генератор данных от xUnitFor1C.
С его помощью очень удобно подготавливать данные для тестов из боевой базы. Например, мы в боевой базе получаем какой-то «снимок» данных, на которых у пользователя возникла проблема, и потом в тестах можем использовать именно эти данные, чтобы ошибка, которую описал пользователь, не возникла в дальнейшем.
Устраняем рутину
Как я уже говорил, очень важно устранять рутину.
Например, с помощью Vanessa-runner я организую запуск моих любимых инструментов в режиме «1С:Предприятия». Справа я привел пример настройки vrunner.json. Здесь описаны:
- Простейшие настройки базы – пользователь, пароль, версия платформы, если необходимо;
- Режим запуска Vanessa-behavior;
- Режим запуска дымовых тестов. Как правило, чтобы запустить тесты, нужно выполнить достаточно много действий, и я их запускаю вот этим одним файлом.
С помощью этого файла настройки я могу получить возможность автоматического запуска Vanessa-behavior и xUnitFor1C с нужными мне настройками в нужной мне базе:
- Например, я могу создать файл Vanessa-bdd.cmd, который будет содержать всего лишь одну строку: runner vanessa --settings tools/vrunner.json;
- Также «Инструменты разработчика» удобно запускать с помощью ПИР.cmd. Этот файл запуска позволяет сразу запустить базу в нужном режиме, поскольку для запуска портативных инструментов разработчика требуются обычные формы и отключенная модальность, и при их обычном запуске придется несколько раз перезапускать 1С.
Автоустановка всех инструментов
Как я уже говорил, я люблю все автоматизировать. Поэтому все инструменты у меня устанавливаются автоматически.
Не так давно мне была выдана новая машина, и я буквально за один час установил порядка 30 инструментов, которые я использую в своей работе. Кроме, конечно, Microsoft Office – его пришлось ставить руками.
Все остальные инструменты я установил с помощью специального файла настройки, часть которого приведена на скриншоте. Этот файл настройки использует возможности инструмента Chocolatey , который позволяет установить ваши любимые программы в консольном режиме.
Также у меня есть файл настройки git-config-setup.cmd – он нужен для правильной настройки git на своей целевой машине.
И еще у меня есть инструмент subst_t.cmd – это маленький, простенький инструмент для настройки путей к дискам, чтобы я мог на всех моих машинах использовать одни и те же пути. Например, диск «T» у меня – это всегда рабочие документы, а диск «W» – это базы для 1С.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.
