Что можно автоматизировать?
Что такое вообще «автоматизация специалиста по 1С»? Что такое автоматизация автоматизатора? Что он может делать автоматически?
- Самое очевидное – это бэкапы. Автоматические бэкапы приходят в голову в первую очередь.
- Сюда же относятся такие простые, но очень важные и очень экономящие время вещи, как:
- автоскачивание релизов;
- обновления;
- какие-то выгрузки, которые не нужны бизнесу, но нужны вам лично, и т.д.
Эти задачи встречаются абсолютно у каждого, и очень многие 1С-ники делают их руками. Как вы обычно делаете выгрузку базы? Заходите в конфигуратор, нажимаете «Выгрузить» и т.д.? А почему бы не сделать себе кнопку, которая будет запускать выгрузку автоматически? Эти вещи вообще не должны делаться руками.
Мы можем автоматизировать и более интересные задачи – например, собирать для себя такие показатели, как:
- Статистику качества кода по различным метрикам;
- Как часто изменяется тот или иной объект метаданных;
- Какая корреляция между количеством изменений и количеством ошибок в этом объекте метаданных.
- А если мы интегрируем получение этой статистики в процесс автоматических сборок, мы сможем отслеживать даже такие важные показатели, как, например - кто чаще и полезнее всего коммитит в наше хранилище 1С и т.д.
На каком языке удобнее всего писать скрипты автоматизации?
Ни для кого не секрет, что современная автоматизация IT-шников преимущественно выполняется на скриптах. Скрипты – это сценарии, которые написаны в обычных текстовых файлах. Для них не нужен отдельный компилятор, не нужно создавать проект в VisualStudio – это просто текстовики, которые можно запускать на исполнение. Это просто несложные программы, написанные в текстовом виде.
На чем можно писать скрипты автоматизации применительно к 1С? Существует масса инструментов для скриптинга:
- Есть замечательный PowerShell, которым можно сделать очень много всего интересного и полезного. Правда, он есть только на Windows и у него довольно специфичный синтаксис.
Не знаю, кому как, но мне, когда я что-то делал на Powershell (сейчас уже не делаю, потому что у меня есть OneScript), его синтаксис показался очень неудобным. Если оставить его использование на пару месяцев, то потом при возвращении приходится изучать его заново – настолько он быстро забывается из-за своей необычной специфики. - Есть VBScript, который также доступен только на Windows. Это довольно «бедный язык» и без обвязок в виде COM-объектов на нем писать не очень интересно. Он не то чтобы не мощный – он, скорее, просто скучный.
- Есть прекрасные Python и Ruby, которые работают уже не только на Windows. Они кроссплатформенные, у них богатейшая библиотека объектов, огромные возможности – это прекрасные языки. Но они, опять же, требуют от 1С-ника специальной квалификации, поскольку это – отдельная область знаний, которую нужно изучить дополнительно к тем задачам по автоматизации бизнеса, которые у нас уже есть. И когда помимо бизнеса, который требует от нас автоматизации, нам нужно автоматизировать еще и самих себя, нам приходится изучать для этого целый отдельный спектр языков и их библиотек. Это неудобно.
- Поэтому и появился OneScript. Это скриптовый язык, который выполняет текстовые файлы (маленькие, большие, какие угодно), но при этом не требует изучения нового языка и новых библиотек. Это – язык 1С, который выполняется независимо от платформы: может выполняться в Windows, в Linux, даже под управлением HTTP-сервера – где угодно. При этом он может расширяться, может добавлять новые библиотеки и т.д. Это – средство написания скриптов для 1С-ников на любимом нами языке 1С.
Что такое 1Script?
Итак, OneScript – это независимый от платформы 1С (никаким образом не использующий библиотеки платформы), кроссплатформенный интерпретатор языка 1С с полнофункциональной прикладной библиотекой.
Там есть работа с сетью, работа с файлами, с операционной системой.
Есть несколько режимов, несколько окружений работы.Это может быть:
- Независимый скриптинг.
- Разработка самостоятельных модульных консольных утилит.
- А также несложные веб-службы, которые позволяет запускать специальный режим работы в качестве CGI-приложения под управлением HTTP-сервера. В этом режиме мы можем даже писать на 1С сайты. Но это, конечно, не самое правильное применение OneScript, потому что для написания сайтов есть соответствующие инструменты.
Как мы используем 1Script?
Мы уже больше года успешно применяем OneScript в режиме боевой эксплуатации в рамках одной крупной компании. С его помощью мы решаем три класса пересекающихся задач и наблюдаем при этом эффект синергии, поскольку, решая одну задачу, мы автоматически получаем средство для решения другой.
- Итак, самое основное и самое полезное, что мы делаем – это синхронизация хранилища 1С с GIT. Решение этой задачи дало нам очень много дополнительных возможностей.
- Кроме этого, с помощью скриптов на OneScript мы строим нашу непрерывную интеграцию:
- В частности, мы автоматизировали сборку для наших решений на базе 1С.
- И настроили автоматическое развертывание из собранного дистрибутива в рабочий контур.
- И наконец, мы автоматически собираем метрики кода. Это позволяет нам анализировать общую статистику по качеству того кода, который выдают наши разработчики 1С.
Синхронизация с GIT
Итак, синхронизация хранилища 1С с GIT. Зачем нам это вдруг понадобилось?
Ответ, на самом деле, простой: такая синхронизация позволяет увеличить скорость доступа к истории кода.
Как мы привыкли работать с хранилищем 1С? Например, придя рано утром на работу, мы поняли, что у нас в коде есть некая строчка, которая все ломает. Кто внес эту строчку и когда? Мы открываем историю кода, отматываем пару версий назад, запускаем сравнение, идем пить чай, возвращаемся, смотрим: не та версия, строчка все еще есть. Выбираем новую историю, запускаем сравнение, выпиваем чай, смотрим: не та версия. Ругаемся матом, выбираем другую версию и т.д. Получается, что из-за несовершенства инструмента мы тратим наше драгоценное время, неэффективно расходуем его, выполняя разбор полетов – кто и когда внес эту строчку.
А имея код исходников 1С в GIT, мне достаточно написать: git blame, и через секунду я уже вижу, кто внес эту строчку и когда. Таким образом, синхронизация хранилища 1С с GIT не заставляет меня пить чай литрами.
Для синхронизации хранилища с GIT мы используем специальное приложение на OneScript, о нем – чуть позже.
Пример выгруженных в GIT исходников 1С показан на скриншоте. В качестве сервера репозиториев мы используем Stash (это корпоративный аналог BitBucket).
У нас в компании внедрен стек Atlassian – это Stash, Jira, Codereview в виде Crucible и т.д., причем все эти инструменты замечательно интегрированы. Это дает очень полезный совокупный эффект.
Синхронизируясь с хранилищем, я уже прямо в веб-интерфейсе Stash вижу всю историю. Когда я хочу сравнить одну версию с другой, мне не нужно ждать – я просто кликаю по ссылкам и получаю сравнение за секунды.
Особенности синхронизации:
- Для каждого коммита в таблице указан его автор – ссылка на соответствующего пользователя домена Stash.
Естественно, что в хранилище 1С свои пользователи, они сохраняют туда результаты своей работы и пишут комментарии к закладкам. Причем пользователи хранилища 1С могут называться совсем по-другому, чем соответствующие им пользователи Stash. А при запуске приложения gitsync пользователи хранилища 1С автоматически отображаются на пользователей домена Stash. И результаты мы видим уже в разрезе доменных пользователей – кто сделал закладку и когда. - Также для каждого коммита отображается соответствующий ему текст закладки из хранилища 1С
- А если в комментарии к закладке был указан код задачи, то мы в отдельной колонке видим ссылку для ее открытия в Jira.И наоборот, рассматривая задачу в Jira, мы можем увидеть, какие строки кода были изменены в ходе работы над ней.
Самое главное здесь то, что мы при этом ничего не ждем. В мире и так сделано очень много полезных инструментов, и мы можем успешно их друг с другом интегрировать. Например, изобретен GIT, а с ним уже по умолчанию работает масса инструментов, включая и те, о которых я говорю. Поэтому, получая исходники в GIT, мы автоматически получаем доступ ко всем наработкам мирового сообщества. Это очень удобно.
Точно так же доступен быстрый контроль изменений в рамках коммита – я сразу вижу, кто, что и где менял, по каким модулям.
Еще один момент, от которого мы получили пользу практически сразу, как только внедрили – это обзоры кода. Это та штука, которая дала моментальный положительный эффект– мы сразу сказали: «Вау, как классно получается!»
Обзор кода мы выполняем с помощью Atlassian Crucible. Это продукт также из стека Atlassian, он тоже успешно интегрируется.
Какие положительные моменты мы получаем? Их несколько.
- В первую очередь, это обмен знаниями, даже на нескольких уровнях. Мы выделили экспертную группу, которой команда доверяет, разрешая смотреть и критиковать код:
- во-первых, идет обмен знаниями от экспертов к менее опытным коллегам, когда они передают какой-то опыт и говорят – так делать можно, а так нельзя и т.д.
- а во-вторых, когда эксперты комментируют одну и ту же задачу, они еще и обучают друг друга: один заметил одно, другой – другое, научили друг друга. Это активизирует обмен знаниями и накопление опыта в команде.
- При проведении обзоров кода удалось решить еще одну важную проблему. Дело в том, что разработчики, когда пишут, не знают, что делает их коллега. Они в соседний модуль не лезут: «я там ничего не знаю, ничего не понимаю, и знать не хочу». А сейчас, после внедрения обзоров кода, они волей-неволей становятся в курсе проблем своих коллег. И в случае, например, какого-то форс-мажора или чьей-то болезни, они тоже могут подключиться к разработке, потому что теперь они также владеют темой этого модуля (хотя, в принципе, это произошло автоматически – их никто не заставлял). Получается, что, изучая код, разработчики учатся тому, что происходит в соседних модулях – лучше понимают архитектуру системы, меньше пишут костылей, меньше копипаста и т.д.
Этот полезный эффект мы получили практически в первые дни после внедрения обзоров кода. - И третий момент – у нас стали быстро находиться баги. Они стали находиться еще даже до попадания в сборку, не говоря уже про рабочий контур. Это стало возможным именно благодаря таким просмотрам кода. Когда смотришь свой код, в нем тяжело найти ошибку, но стоит отдать его чужому человеку, он находит ошибки очень быстро. Это очень эффективно, попробуйте!
Как мы получили все эти прелести?
Мы взяли инструмент v83unpack, который написал очень уважаемый мною Евгений Сосна. Если кто не знает, v83unpack – внешняя обработка, которая выложена на github. А поскольку она написана на 1С, то мы обычным копированием через буфер обмена можем просто перенести ее код в скрипт и выполнять там (с небольшими изменениями). На базе этой обработки и было написано приложение gitsync.
Приложение gitsync – это именно консольная утилита. Поэтому запуская ее, вы даже не думаете, на каком языке она написана, вы прямо в командной строке пишете:
gitsync <путь к хранилищу> <url удаленного репозитория>
Нажимаете Enter – и все, пошла синхронизация.
Сборка релиза
У нас внедрено релизное управление – это означает, что на рабочий контур накатывается не какая-то закладка в хранилище 1С, а выпускается специальный новый релиз, для которого мы собираем полноценный setup.exe (такой же полноценный дистрибутив, с каким поставляются типовые конфигурации и который устанавливается в каталог шаблонов).
Этот дистрибутив включает в себя не только код, но и документацию, приемочные тесты, какие-то внешние обработки и т.д. Все это мы также храним в GIT. Получается, что у нас не только код, но и вся сопроводительная документация, все материалы к релизу также версионируются в едином хранилище.
И, когда мы запускаем цикл сборки, все это компонуется в файл релиза (файл setup.exe), который мы выкладываем на сетевое хранилище, чтобы команда поддержки могла его оттуда забрать и развернуть в рабочей базе.
Развертывание релиза
Сценарий развертывания у нас довольно простой и, в принципе, стандартный: билд-сервер загружает релиз, который ему выложили разработчики, отключает пользователей и выполняет развертывание. Это все, в принципе, понятно.
На скриншоте показан скрипт, который выполняет развертывание. Как вы видите, проверяется число попыток отключений, и если пользователь все еще есть, мы выводим сообщение, ждем немного, пытаемся опять его отключить и т.д.
Здесь показана выдержка из лога билд-сервера. Обратите внимание, что в результатах сборки отображается сообщение о работающих сеансах, которое было прописано в скрипте – соответственно, мы можем отследить, как происходил процесс развертывания.
Билд-сервер для непрерывной интеграции
В качестве билд-сервера мы у себя используем TeamCity – он показан на скриншоте. Здесь можно увидеть наши проекты и состояние по ним. Например:
- по первому проекту показано, что его код уже синхронизирован с GIT,
- а по второму – релиз уже развернут в нужный контур и в нем успешно проведены тесты.
Просто открываем браузер и смотрим статистику, где какая версия в каком состоянии у нас находится, и т.д.
Чтобы раскатать релиз в базу, нам достаточно нажать кнопку Runв консоли билд-сервера, и мы получаем либо развертывание, либо сборку нового релиза.
Метрики кода
Что касается метрик кода, мы в основном используем уже существующие инструменты – либо с Инфостарта, либо те, которые получили в сообществе.
- Например,у нас идет расчет покрытия кода тестами, которое реализовано, опять же, силой таланта Леонида Паутова и Евгения Сосны.
- Есть анализ цикломатической сложности кода, когда мы смотрим, какие модули у нас наиболее запутанные и наиболее плохие – мы каждую сборку собираем статистику по цикломатике и, если она куда-то прыгает, значит, где-то кто-то что-то плохо, непонятно написал.
- Еще мы используем известную обработку «Копипастамер» от ildarovich – это анализ повторяющихся фрагментов кода по всей конфигурации. В результате мы можем видеть статистику, и если какой-то показатель превышает порог, значит, кто-то, не разобравшись в коде соседа или в общих модулях, просто взял и что-то «скопипастил», хотя эту процедуру надо было просто вынести с директивой Экспорт в отдельный модуль для повторного использования. Ну и начинается сразу разбор.
Как разрабатывать скрипты?
Мы для этого используем программу Notepad++. На Инфостарте можно найти подсветку синтаксиса языка 1С для Notepad++, а всплывающая подсказка там есть прямо «из коробки».
Необходимо сделать всего лишь пару настроек, и программа Notepad++ превращается в неплохую среду разработки, которая позволяет:
- Писать код с подсветкой синтаксиса и со всплывающей подсказкой;
- В отдельной панели видеть файлы проекта;
- И, что самое главное: прямо отсюда мы можем запустить этот код на выполнение и увидеть внизу его непосредственные результаты. Например, я написал код, нажал F6 и внизу пронаблюдал результат его выполнения.
Я никуда не переключаюсь – это одно окно, где есть все, что нужно для разработки скриптов. Буквально в три нажатия кнопки Notepad++ превращается в такой редактор кода. Очень удобно.
Устройство языка 1Script. Доступная документация по проекту
Как устроен OneScript внутри?
- Это – приложение.NET, которое довольно стабильно работает и под LinuxMono 3.12 и под .NET 4.0.
- Он написан на C#.
- Его исходные коды открыты.
- Есть встроенная стандартная библиотека для взаимодействия с операционной системой.
- И еще есть набор полезных наработок – инструментов, уже написанных на OneScript.
Есть сайт – oscript.io, на котором находится вся документация по проекту.
Там описан процесс установки, запуска: как разрабатывать, расширять и т.д.
Также, что мне кажется наиболее важным, там есть онлайн синтаксис-помощник. Поэтому, когда вы захотите поподробнее узнать возможности глобального контекста, а также какие свойства и методы есть у того или иного класса, и т.д., достаточно зайти на oscript.io и посмотреть подсказку по синтаксису.
Новое в проекте. Библиотеки. Пакеты приложений
В прошлом году я уже делал доклад по OneScript, но тогда это был просто анонс инструмента, наработок непосредственно на скриптах на тот момент было еще очень мало, но мы уже довольно успешно использовали его у себя внутри, и нам это очень нравилось.
Постепенно накопилась кодовая база, которую захотелось использовать повторно.
Поэтому я добавил в движок возможность использовать библиотеки – была внедрена нестандартная директива препроцессора, которая так и называется: #Использовать (на скриншоте ее видно).
И теперь, если мы вначале скрипта пишем:
#Использовать <некую библиотеку>
у нас в области видимости скрипта появляются объекты этой библиотеки (классы или модули).
Например, если мы пишем:
#Использовать tempfiles
У нас подключается модуль «временные файлы», который содержит полезные функции для работы с временными файлами (автоудаление и пр.).
А для того, чтобы подключить мощную библиотеку строковых функций, нужно написать:
#Использоватьstrings
Более того, с тех пор появились пакеты программ:
- Это уже не просто какие-то отдельные скрипты, которые где-то лежат. Это модульные приложения с точкой входа, они могут содержать наборы модулей самых разных видов.
- Эти пакеты могут быть упакованы и распространяться в виде дистрибутивов. Причем предусмотрена автоматическая установка этих дистрибутивов с помощью пакетного менеджера.
- Внутренняя структура приложения ничем не ограничена, автор пакета может строить свое приложение, как ему заблагорассудится.
- Сам движок OneScript никак не диктует то, как библиотека должна быть устроена внутри - есть определенная инфраструктура загрузки библиотек, только и всего.
Схема загрузки библиотек
Как организована инфраструктура для загрузки библиотек?
- В системе есть каталог, в котором лежат установленные пакеты. Их может быть несколько – это прописывается в конфигурации.
- И есть модуль загрузчика (это тоже скрипт), который эти пакеты загружает в область видимости движка, в область видимости скриптов.
При этом, как я уже сказал, внутреннее устройство отдельной библиотеки никак не регламентируется, никак не диктуется.
Единственное, чтобы упростить задачу разработчика, есть стандартное соглашение о том, как строить пакет так, чтобы с ним было удобно работать.
В соответствии с этим соглашениеммы можем складывать зависимые скрипты пакета в предопределенные каталоги «Классы» и «Модули»: если скрипт лежит в каталоге «Классы», значит, что это объект, который можно создавать с помощью оператора«Новый».
Допустим, если у нас там лежит файл Пользователь.os, то в основном скрипте библиотеки мы сможем создавать класс с помощью конструкции:
Новый Пользователь().
А если мы положим скрипт в папку «Модули», то мы сможем использовать его как общий модуль (сразу через точку, как свойство глобального контекста):
УправлениеПользователями.Удалить();
РаботаСФайлами.Существует(“log.txt”);
Если автор пакета захочет структурировать свои модули согласно этой схеме, ему надо всего лишь разложить соответствующие файлы в нужные папочки и добавить в свой пакет отдельный модуль загрузчика package-loader.os (помимо основного файла загрузчика, который лежит в корневой папке библиотек). Стандартный код такого «дополнительного» загрузчика показан на следующем слайде. При желании, его можно кастомизировать – внести туда свои правки или вообще написать свой вариант.
Что такое загрузчик? Это тоже скрипт. Поскольку вся логика загрузки библиотеки не прошита в движке, а точно так же заскриптована, мы можем просто поправить в этом скрипте событие ПриЗагрузкеБиблиотеки (здесь видно, что оно заключается в банальном переборе файлов каталога).
Как происходит загрузка библиотеки?
Когда компилятор встречает в скрипте директиву #Использовать, он ищет каталог, в котором лежит эта библиотека,инициализирует еемодуль загрузчика и выполняет его обработчик события ПриЗагрузкеБиблиотеки (там прописан алгоритм интерпретации загрузкиэтой библиотеки).
Пакетный менеджер
У нас есть облачное онлайн-хранилище пакетов, куда мы выкладываем сформированные нами наработки – вы можете их устанавливать и повторно использовать.
Для удобной работы с этими наработками есть пакетный менеджер, я назвал его opm (OneScriptPackageManager). Он также написан на OneScript и представляет собой консольную утилиту.
Вы открываете консоль и сразу пишете:
opm install gitsync
И дальше приложение запускается, идет в облако, скачивает приложение gitsync и устанавливает его. Поэтому следующим вашим шагом будет:
gitsync <хранилище такое-то> <urlрепозитория такой-то>
Это уже не просто скрипты, это приложения, которые запускаются сразу в командной строке под собственным именем.
Для того, чтобы opm мог как-то идентифицировать пакет при скачивании, автору пакета достаточно подготовить специальный файл манифеста, который пишется в стиле «конфигурирование через код». По сути, это код, но он выглядит, как конфигурационный файл.
Мы пишем в нем:
- имя пакета такое-то,
- версия такая-то,
- зависит от пакетов 1, 2, 3…
- И, если это – приложение с исполняемой точкой входа, то мы прописываем еще и эту точку входа (исполняемый файл).
В случае, если у приложения прописана исполняемая точка входа, при установке через пакетный менеджер автоматически сгенерируется shell-скрипт, который будет эту точку входа запускать. И в результате мы получаем утилиту командной строки, пользователю которой неважно, на каком языке она написана – он просто ее запускает.
Примеры библиотек
Немного о тех библиотеках, которые у нас уже есть.
Самой полезной по отдаче для нас стала библиотека v8runner – объектная обертка для конфигуратора.
Все знают, что у конфигуратора есть параметры запуска, позволяющие выгрузить конфигурацию, загрузить конфигурацию, разложить на файлы – очень много команд. И мы написали объектную обертку, которая позволяет нам удобно вызывать эти команды конфигуратора. Для этого мы подключаем библиотеку v8Runner и пишем:
Конф = Новый УправлениеКонфигуратором();
Конф.ЗагрузитьКонфигурациюИзФайла(ПутьКФайлу)
И она загружает этот файл конфигурации в нужную базу.
Мы можем создать информационную базу и указать версию платформы, которая должна быть при этом использована: v8runner сам определит, где установлена платформа, каких версий, найдет максимальную или определит наиболее близкую по маске. Эти низкоуровневые и неинтересные вещи закрыты там внутри, они не отвлекают ваш мозг от решения основной задачи.
Эта библиотека оказалась очень полезной – мы ее активно применяем.
Даже если вы не будете использовать OneScript (что делать нельзя), вы можете просто использовать этот код в своих разработках 1С – поскольку синтаксис одинаковый, код можно портировать просто переносом через буфер обмена.
Вторая библиотека, которая имела такой же полезный эффект – это библиотека логирования logos, которая была написана под впечатлением от log4j (библиотека логирования для Java). Получилось логирование в стиле log4j на языке 1С.
Выглядит это так: мы у себя в коде приложения прописываем сообщения разного уровня, говорим, что это сообщение – об ошибке, это – вообще отладочное сообщение (оно нам не нужно) и т.д. А потом уже при эксплуатации приложения мы просто регулируем его «болтливость», устанавливая уровень лога (сейчас хочу отладочные сообщения, а сейчас – не хочу). Мы получаем нужный нам в данный момент уровень детализации лога, не переписывая код. Это очень удобно.
Если я не ошибаюсь, сейчас уже накоплено порядка десяти библиотек, которые родились в процессе применения OneScript в нашей компании. А поскольку мы ничего не прячем, то в проекте появляются библиотеки повторно используемого кода.
Заключение
В заключение, хотелось бы резюмировать:
- Все, что мы делаем руками, нужно постараться автоматизировать. Если вы несколько раз подряд что-то проделали вручную, нажимая мышкой, надо задуматься: если вы сделали какую-то последовательность действий один раз – бог с ней, а если вы ее сделали два и даже три раза –надо писать скрипт автоматизации.
- Для этого есть инструмент – OneScript, который достаточно стабильно работает (уже больше года в крупной компании в режиме боевой эксплуатации).
- Этот инструмент – уже не просто скриптовый движок, это уже некая экосистема наработок для автоматизации 1С-ников.
- В этой экосистеме естьоблачный пакетный менеджер, с помощью которого мы можем инсталлировать или удалять пакеты по мере необходимости, выполняя пару команд в консоли.
Язык 1С – это такая linguafranca для 1С-ников. Когда наши коллеги в соседнем отделе внедряли у себя непрерывную интеграцию, я отдал им наши скрипты и какую-то документацию. Потом через пару дней встречаю в коридоре: «ну как, получилось?» Он говорит: «да, было что-то непонятно, но я посмотрел в код и разобрался». Смысл в том, что мы говорим с ним на одном языке и, когда ему непонятно, он может просто посмотреть в код. А если бы я написал это, не дай бог, на ruby, то он бы посмотрел в код и сказал: «Что это? Не буду я разбираться, внедрять не буду». А здесь он смог посмотреть в код, разобраться и внедрить у себя полезный инструмент непрерывной интеграции (о ее пользе мы говорить не будем, она очевидна).
Ресурсы проекта:
- В первую очередь, это oscript.io – сайт проекта, на котором есть синтаксис-помощник и документация,
- Также это hub.oscript.io – hub пакетов. Пока не богатый, но я думаю, что он будет развиваться.
- Это https://github.com/oscript-library –репозиторий скриптов
- И https://github.com/EvilBeaver/OneScript – репозиторий самого движка.
****************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.
Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.
От автора:
За год, прошедший с момента данного выступления, часть информации несколько потеряла актуальность, мы не стояли на месте и многое улучшили. В частности, активные участники сообщества @nixel2007, @bambr1975, @pumbaEO (кого забыл, напомните), создали новый редактор кода на 1С, взамен упомянутого здесь Notepad++. Рекомендую пользоваться именно этим редактором на базе Visual Studio Code.
https://github.com/xDrivenDevelopment/vsc-language-1c-bsl/blob/master/README.md