DevOps: бери и делай!

Публикация № 1361047 15.01.21

Инструментарий разработчика - DevOps

В последнее время тема DevOps становится актуальной благодаря бесплатным инструментам автоматизации для проектов на 1С. О том, как вести разработку по DevOps и какие при этом могут возникнуть проблемы и сложности, рассказал разработчик Инфостарта Павел Олейников.

Я хочу поговорить про DevOps – что это такое, зачем он вообще нужен, и почему он сейчас так популярен.

 

 

Все уже, наверное, видели этот знак бесконечности с делением на секторы Dev и Ops – это эмблема DevOps, которая в последнее время все чаще встречается.

Но зачем вообще нужен DevOps и действительно ли он необходим?

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

В русской Википедии дано следующее определение DevOps:

Методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимная интеграции их рабочих процессов друг в друга для обеспечения качества продукта.

В то же время в англоязычной Википедии определение следующее:

Набор практик, направленный на сокращение жизненного цикла разработки систем и непрерывной доставки ПО на продуктивную среду, обеспечивающий высокое качество продукта.

Мне больше нравится иностранное определение, из него понятно что: DevOps необходим, потому что он помогает выпускать качественный продукт дешевле – мы быстрее поставляем качественный продукт, соответственно, мы завоевываем рынок.

 

 

Сложно ли внедрить DevOps?

На самом деле, DevOps сочетает в себе несколько разных процессов – это:

  • Coding (кодирование, контроль качества)

  • Building (сборка)

  • Testing (тестирование)

  • Packaging (подготовка релиза)

  • Releasing (утверждение релиза, развертывание)

  • Configuring (управление инфраструктурой)

  • Monitoring (мониторинг, работа с пользователями)

Всеми этими процессами мы, 1С-ники, так или иначе, занимаемся. Другое дело, что у нас эти процессы зачастую не автоматизированы (что-то автоматизировано, что-то – нет), но они присутствуют – может быть, не слиты вместе в единую систему. Мы пишем код, изучаем код других участников команды – независимо от того, есть ли у нас обязательная процедура code review. Мы все этим занимаемся.

Почему же сейчас тема DevOps стала так интересна?

Все курсы по DevOps, которые я смотрел, направлены на системных администраторов. Потому что если программисты для своего удобства уже что-то автоматизировали, то у системных администраторов в этом плане тяжело – они вынуждены настраивать кучу разного ПО, особенно, если их работа касается администрирования веб-проектов (Apache, Nginx, Gzip, MySQL). Все это со своими настройками, изменилась версия продукта – нужно все это переставить, поставить что-то другое. У них может использоваться 15 - 20 продуктов, и если ошибиться в версии какого-то из них - все упадет, а может быть и нет. Поскольку для них это очень критично, их этому и обучают. Поэтому все курсы по DevOps, в основном – это автоматизация деятельности сисадминов.

Но все те же самые практики автоматизации рутинных действий можно использовать и для разработки в 1С, несмотря на то, что раньше это было не принято. Мы привыкли, что фирма «1С» загнала нас в рамки своей функциональной платформы, и мы работаем только в этих рамках, не оглядываясь на другие технологии – нам для всего хватает нашего маленького желтого круга. Но сейчас эти границы уже начинают расширяться.

 

Обзор бесплатных инструментов

 

 

Что мы сейчас используем у себя в компании, чтобы автоматизировать процессы разработки, чтобы мы могли сказать, что у нас есть DevOps, и мы этим занимаемся.

 

Coding (кодирование, контроль качества)

Разработка – это:

  • Конфигуратор 1С. Одна из наших систем, самая большая, все еще там, потому что она слишком часто обновляется и требует последней версии платформы.

  • Еще есть EDT, на которой по всем своим проектам работаю я, но она кушает достаточно много ресурсов. На моей рабочей машине она работает хорошо, но для этого, пришлось поставить 32 Гб оперативной памяти и SSD. Еще год назад фирма «1С» сказала, что такое количество оперативной памяти – это стандарт рабочего места для программиста.

  • В качестве системы контроля версий фирма «1С» нам предлагает хранилище конфигураций. Это функционально, работает, помогает организовать команду, но есть сложности:

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

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

    • Либо если мы хотим что-то доработать дома, мы должны выгрузить cf-файл, принести домой – развернуть базу, развернуть cf-файл, начать с ним работать, потом принести обратно, сравнением/объединением загрузить. Если конфигурация большая – это тоже сомнительное счастье. Проще у сисадминов выбить удаленный доступ.

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

  • Кстати, по поводу разработки на EDT – когда вы разрабатываете на EDT, 1С хранит конфигурацию в виде набора файлов, среди которых есть – BSL-файлы (это код модулей) и куча XML-файлов, в которых хранится структура, формы и т.д. Там огромное количество папок. Конфигурация КА, выгруженная в файлы, занимает порядка 10 Гб. Из плюсов – вы можете редактировать модули конфигурации не только с помощью EDT, но и из VS Code, потому что в нем тоже много инструментов для работы с текстом модулей. Можно даже не запускать EDT, а править текст модуля в VS Code и коммитить прямо оттуда. Это быстро и удобно. Потом достаточно будет только запустить тестирование, и если тесты прошли, значит, все хорошо.

  • На следующем этапе мы должны проверить качество кода, который мы написали. Я программирую уже 15 лет и всегда думал, что я молодец и пишу код хорошо. Но я смотрю в SonarQube – я не молодец. Все наши договоренности о том, как писать код (как ставить запятые, пробелы, черточки, чтобы все это легче читалось) – это все работает только на бумаге, и в реальности мы получаем совсем не тот код, который мы ожидали. Но если мы проводим ревью кода – мы тратим время, тратим нервы, и мы никак не делаем команду сильнее. Когда твой сосед тебя контролирует и тебя критикует (даже если по делу) – это не команда, потому что все равно накапливается какое-то психологическое противостояние, которое нас отдаляет друг от друга. Это нехорошо. Поэтому пускай проверяет машина – кто будет обижаться на машину? Машина проверяет, мы видим метрики, у нас появляется какая-то история. У SonarQube есть бесплатный плагин для проверки качества кода 1С – на моей машине он спокойно проверяет код КА за 10 минут. АПК эту же КА проверяет несколько часов. Получается, что, запустив проверку в SonarQube, я очень быстро получу ответ – пройден порог качества или нет, хорошо мы написали код в этот раз или плохо. Плюс у меня есть история в цифрах – как развивался мой проект – становился хуже или лучше. А для руководителя цифры важны тем, что есть объективная метрика – он не просто молодец, а он молодец, потому что было 18, а стало 8 – он стал меньше косячить.

 

Building (сборка)

Обратите внимание, здесь на схеме есть еще значок OneScript – это реализация виртуальной машины 1С, которая позволяет вызывать все команды по работе с конфигурацией (выгрузки базы, сборки релиза и т.д.) с помощью скриптов, написанных на языке 1С. Они работают как обычные батники или скрипты vbscript, но при этом написаны на понятном каждому 1С-нику языке.

Проект OneScript разрабатывается сообществом – любой, кто знает C#, может придумать какую-то новую фишку и реализовать ее в этом решении.

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

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

 

Testing (тестирование)

Для тестирования мы используем Vanessa Automation в связке с СППР. В ней мы храним структуру конфигурации и туда же добавляем скрипты тестирования. Там их удобно настраивать и можно комбинировать – написать скрипт, добавить несколько разных сценариев, и СППР будет их запускать.

 

Packaging (подготовка релиза) и Releasing (утверждение релиза, развертывание)

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

 

Monitoring (мониторинг, работа с пользователями)

Мониторинг (контроль того, что, где, как сломалось) – это те же замеры производительности, контроль серверов и т.д.

Дальше идет оперативная деятельность – это работа с пользователями. Здесь мы работаем в нашей внутренней системе по учету заявок, которая называется BPM.

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

 

Особенности инфраструктуры

Обратите внимание, что процессы deploy (он же Releasing) и build должны быть, по сути, одинаковыми:

  • На этапе deploy мы готовим cf-ник, который загружаем на рабочую базу, стартуем базу, и запускается процедура обновления.

  • На этапе build происходит то же самое, только производится загрузка базы на эталонную, после чего на эталонной базе прогоняются тесты. Получается, что тесты – это не только скрипт, но и проверка, создалась ли база, обновилась ли она, нет ли здесь ошибок. Соответственно, тестировать надо на такой же инфраструктуре, что у рабочей базы – хотя бы приблизительно. Нельзя тестировать на файловой базе с платформой 8.3.16, если на продуктиве у вас клиент-сервер с платформой 8.3.13– возможно, вы что-то не протестируете.

Кстати, по поводу выгрузки в XML-файлы. Возможность выгружать модули из базы появилась у конфигуратора в версии 8.0.10 – релиз с этой возможностью состоялся 31 марта 2005 года. Да, эта выгрузка была не полноценной и выгружались только модули и справочная информация, а не вся конфигурация, как сейчас. Но платформа уже тогда была готова к тому, чтобы не отрываться от остальных языков разработки – все понимали, что это нужно, что сообщество будет это использовать. И в статьях 2007-2008 года я видел, что люди уже использовали системы контроля версий для ведения разработки (правда, тогда еще использовался не Git, а другая VCS). Там описывался процесс разработки без хранилища – именно путем выгрузки модулей в файлы.

 

Начало работы: какие могут возникнуть проблемы и сложности

 

 

Как проще всего начать применять DevOps-практики

  • Поставить SonarQube. Это система, у которой есть бесплатная Community-версия. Ставится достаточно просто. Вы можете поставить ее себе на локальный компьютер и просто проверить качество кода на своем проекте – выгрузить конфигурацию в xml руками и батником запустить проверку. Я не призываю вас сразу запускать проверку ERP, потому что, чтобы проверить КА, мне пришлось отдать Java-машине 24 Гб, а ERP будет требовать еще больше оперативной памяти. Но какие-то небольшие проекты можно проверять – просто чтобы узнать, что такое автоматизированная проверка качества. Потому что об этом можно говорить много, но, пока не потрогали руками, не понятно, что же это такое. Поставьте SonarQube на своей машине, посмотрите, что это такое – вас это ни к чему не обязывает.

  • Следующим шагом – поставить GitLab. На Windows он не ставится, поэтому придется развернуть виртуальную машину. Но мы же в 21 веке – есть много инструкций, как развернуть виртуальную машину на базе Ubuntu, это все достаточно просто делается.

  • Дальше – поставить OneScript, С ним будет проще писать, по нему тоже очень много информации – и есть уже готовые скрипты, которые помогут проще выгружать.

  • Установить Git, создать репозиторий и выгрузить в него историю изменений хранилища конфигурации с помощью GitSync (пакета для OneScript). Да, это будет не быстро, потому что выгрузка в Git происходит следующим образом – он берет версию хранилища, выгружает в cf-файл, этот cf-файл загружается в новую созданную базу, оттуда выгружается в XML файлы. Там много шагов, и, если база большая, это, конечно, займет время, но можно будет посмотреть, что такое Git, как выглядит история вашей разработки в Git. Опять-таки, мы пока не меняем базы, не меняем среду разработки, мы просто пробуем.

  • Следующий шаг – скачать Vanessa Automation. Она поставляется в двух вариантах – как единая обработка (в варианте Single) и как комплект обработок. Скачайте VA в варианте Single, запустите и посмотрите, что такое тестирование – как оно работает, что оно умеет. Может быть, это заменит ваших тестировщиков, которые просто прокликивают сценарии использования по вашим доработки, проверяют, открываются ли формы. Может, это просто нужно сделать, чтобы не было проблем, чтобы все гарантировано стартовало. Причем, VA – это тоже фреймворк, который разрабатывается сообществом, вы тоже можете его дорабатывать. Например, когда мы разговаривали с Леонидом, мне было интересно что-то сделать, я предложил: «А давай Vanessa будет несколькими голосами говорить одновременно», он обрадовался: «Давай, сделай!». Я сел и дописал – любой из вас может любую свою идею не просто предложить, а еще и самому реализовать. Почему нет? Протестировали – опять, мы не меняем базу, мы не меняем среду разработки, мы просто посмотрели, что такое тестирование, с чем его едят, а может быть, и отдали нашим тестировщикам, чтобы они наконец-то начали тестировать быстро – не по полгода, не брать на это 8 часов из спринта, а тестировать за час-два.

  • Следующий шаг – организовать автоматический запуск скриптов. GitLab у нас уже есть, и мы просто попробуем сделать так, чтобы GitLab нам что-нибудь автоматически запускал – ту же проверку в Sonar. У GitLab есть GitLab CI, который позволяет запускать скрипты – можно посмотреть, что такое CI, и попробовать поработать с ним, написать батник, который будет вызывать Sonar в нужный момент сам. Простейший код по автоматическому запуску у меня дальше в докладе будет, я покажу, как это.

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

 

Разработка через хранилище 1С

 

 

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

  • Мы просто выгружаем хранилище в Git с помощью GitSync и уже имеем полноценную историю.

  • Кроме этого, так как у нас база уже в виде файлов, мы проверяем качество кода – уже можем сказать, где есть проблемы. Например, SonarQube может помочь отследить:

    • Одинаковые условия – кто-то копипастом добавил в ИначеЕсли одинаковые условия. Глазами такие места можно пропустить, а SonarQube это покажет, потому что во втором условии нет смысла.

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

  • Дальше – тестирование.

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

 

Разработка через Git

 

 

Либо же мы можем разрабатывать сразу с использованием Git, не используя хранилище.

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

В EDT все просто – там мы сразу работаем с файлами, которые хранятся в репозитории. Разве что для загрузки конфигурации в базу мы должны дополнительно вызвать команду утилиты ring, чтобы преобразовать файлы из структуры, которая хранится в EDT, в ту структуру, которую понимает 1С.

А если мы работаем в конфигураторе, то просто после завершения работы выгружаем файлы конфигурации в репозиторий Git и точно так же идем по процессу дальше.

 

 

При работе напрямую с Git мы можем поделить нашу разработку на ветки по методологии Git-Flow. Тогда репозиторий по сравнению с выгрузкой из хранилища будет выглядеть иначе. Потому что когда мы выгружаем из хранилища, у нас есть одна ветка, и мы по ней идем, при этом каждый коммит в ветку - это событие помещения части объектов в хранилище конфигурации.

А когда мы разрабатываем по методологии Gitflow, у нас есть:

  • ветка master, в которой находится только рабочий код;

  • ветка maintenance для экстренного исправления багов – если что-то нашли, нужно срочно поправить;

  • ветка develop, в которую стекаются все изменения от разработчиков – в этой ветке проводится тестирование;

  • и ветки для разработчиков (либо по задачам).

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

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

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

Выглядит страшно, но когда начинаете этим пользоваться, кажется, что по-другому и нельзя.

 

Автоматизируй все: настройка GitLab CI

 

 

Теперь попробуем настроить GitLab runner, чтобы автоматизировать часть наших процессов.

Первым делом автоматизируем проверку с помощью SonarQube. Вручную эту проверку можно запустить в командной строке с помощью bat-файла, запускающего утилиту sonar-scanner. А мы хотим сделать так, чтобы этот bat-файл запускался с помощью GitLab runner.

Для этого нам в панели управления GitLab нужно посмотреть, как прописываются настройки для установки агентов Shared Runner.

Здесь нам подсказывают – скачайте GitLab Runner, зарегистрируйте его на следующий URL, укажите регистрационный токен и запустите.

GitLab Runner устанавливается как служба и работает на вашей машине.

Из важного – при регистрации нужно сразу прописать теги, по которым он будет искаться потом внутри скрипта.

 

 

Дальше – в папке проекта разместим файл настройки sonar-project.properties, в котором укажем:

  • где у нас находится SonarQube;

  • как у нас будет называться проект на SonarQube;

  • где у нас находятся исходные файлы;

  • и какие файлы будем включать – мы берем только bsl-файлы, другие нам не нужны, потому что мы не умеем проверять xml-файлы конфигурации (SonarQube не знает, как их проверять).

Также в папке проекта должен лежать файл check.bat, который будет запускать проверку, вызывая утилиту sonar-scanner (она скачивается с сайта SonarQube отдельно).

 

 

Чтобы авторизоваться на сервере SonarQube, нам нужно в списке пользователей для конкретного пользователя создать токен доступа. Он будет показан только один раз в момент создания. Больше его никак посмотреть нельзя, можно только отозвать.

 

 

И последний шаг – в корень проекта мы добавим файлик .gitlab-ci.yml, где укажем настройки для запуска проверки:

  • создаем новый этап «Проверка сонаром»:
    stages: -Sonar check

  • говорим, что будем запускать этот этап только на runner-е с тегом win:
    tags -win

  • только в ветке с названием po:
    only: refs: -po

  • в самом скрипте пишем команду chcp 65001, которая переводит кодировку на UTF-8, чтобы мы могли прочитать логи, если там появятся ошибки;

  • и через обертку CALL вызываем батник check.bat с параметрами – адресом сонара и токеном, который мы получили у SonarQube.

Теперь, как только мы что-то помещаем в хранилище, отправляем на сервер GitLab командой push, стартует проверка, и через минуту у нас в SonarQube уже есть отчет о проверке того, что мы поместили в GitLab.

 

 

Добавим тестирование, напишем несколько сценариев.

На слайде показан пример сценария – это сценарий из тестирования базы для конференции, который создает новый город в справочнике «Города».

Сценарий тестирования написан на языке Gherkin – это универсальный человекочитаемый язык для написания сценариев.

 

 

Дальше – настроим файл VAParams.json для запуска тестирования с помощью Vanessa Automation из командной строки.

В описании репозитория Vanessa Automation https://pr-mex.github.io/vanessa-automation/dev/ есть информация о том, как такие файлы настроек должны выглядеть.

Мы здесь указываем параметры:

  • ИмяСборки

  • ВерсияПлатформы

  • ВыводитьСообщенияВФайл (в каком файле будут выводиться сообщения

  • КаталогПоискаВерсииПлатформы (где находится платформа)

  • СтрокаПодключенияКБазе (где находится база)

  • ПутьКVanessaAutomation (где находится сама обработка Vanessa)

  • КаталогФич (где находятся наши скрипты – сценарии тестирования)

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

 

 

В gitlab-ci.yml добавляем еще один стейдж – Test (секцию Sonar check я со слайда убрал, чтобы не мешалась).

  • Тег у нее тоже win. Если вы не укажите конкретный тег, но при этом будете использовать несколько раннеров, то неизвестно, где этот стейдж запустится – неожиданно для вас он может запуститься на другой машине и сделать то, что не ожидает владелец той машины.

  • Также указываем, что мы тестируем только свою ветку (only refs po).

  • И в секции script указываем команду для запуска Vanessa Automation. Обратите внимание, что здесь у меня используются переменные, которые можно задавать в параметрах GitLab:

    • %Path1C% – чтобы не писать каждый раз путь к 1C;

    • %po_BaseDir% – место, где у меня находится основная папка, в которой лежит весь проект.

Соответственно, мы из основной папки запускаем Vanessa Automation и указываем ей путь к файлу настройки VAParams.json, который вы видели на предыдущем слайде.

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

Чем еще интересен файл gitlab-ci.yml?

  • Здесь может быть хоть 200 стейджей, но они будут разделены по тегам, по компьютерам, по веткам, и мы, грубо говоря, в одном файле можем иметь скрипты для всех наших веток, которые используем.

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

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

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

 

Вопросы:

  • Я так понимаю, что при автоматическом развертывании 1С на продуктив нельзя реализовать стратегию нулевого времени простоя (zero-downtime strategies). Но можно минимизировать простой, если использовать стратегию сине-зеленого развертывания (Blue/Green deployment), когда мы в определенный момент переключаем трафик пользователей на новую версию. Как вы поступаете с базой при автоматическом развертывании? Как вы ее готовите? Как в таких случаях поступать с достаточно большими, терабайтными базами?

  • Могу сразу сказать – у нас есть время, когда мы можем обновить базу. У нас нет терабайтной базы, на терабайтной базе мы этого не тестировали. Когда у меня была огромная база, у нас было окно – в неделю у нас было 5-6 часов, когда мы ее обновляли. Вариантов больше не было.

  • То есть сейчас до конечных пользователей вы доставляете изменения вручную? Скорее всего, вы прикидывали, как именно можно автоматизировать доставку конечного продукта?

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

  • А если приходит бухгалтер и говорит: «Мне очень срочно нужно внести правки в конфигурацию», как у вас получается не отступать от CI/CD процесса?

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

  • В таком случае у вас появляется человеческий фактор, вы вносите правки не через CI-систему, а потом обязаны их докинуть в ваш основной репозиторий.

  • Жизнь сложнее, чем CI-система.

  • У меня вопрос по схеме разработки через Git. Как вы обновляете конфигурацию поставщика из cfu? Вы готовите свое обновление или же обновляете конфигурацию сравнением-объединением с поставкой 1С? Вы говорили, что разложили свою «Комплексную автоматизацию» на файлики, потом собираете из них cf, заливаете его в базу данных. Когда вышло обновление от 1С – что вы делаете дальше?

  • Обновления от 1С проще накатывать с помощью конфигуратора, потому что разбирать конфликты в сборке Git при обновлении конфигурации при глобальном изменении – это еще то веселье. Потому что он меняет слишком много модулей и разбирать это через текст сложнее, чем в интерактивном режиме через конфигуратор. Дело в том, что, когда изменения мержатся в конфигураторе, он показывает – было так, стало так. И это он добавляет в каждый файлик. Соответственно, ты должен зайти в каждый файлик и поправить – возьми вот это и вот то. Для больших объемов – это очень тяжело. Например, когда мы проверили КА с помощью SonarQube, эти 8 миллионов строк, у нас получилось порядка 70-80 тыс. замечаний. Причем, большая часть из них – это ложные срабатывания, потому что так написана платформа – это нельзя менять. Но это большой процесс.

  • Из личного опыта, когда я попытался через EDT внести правки в типовую конфигурацию, потом все это запихнуть в рабочую базу и накатить изменения с помощью cf-файла, мне вывалило кучу измененных объектов, которые я точно не менял. Будьте готовы, что у вас полезет структура сравнения/объединения.

  • Я EDT начал пользоваться с 13-й версии. До 15-й версии я страдал. Вышла 16-я версия – вроде стало легче. Может быть, они реально поменяли версию Java и что-то переписали, но глюков стало меньше. У меня перестал падать проект – он мог просто упасть и не встать. Приходилось заново выгружать КА, создавать новый проект, потому что он просто не оживает и часть кода теряется. После 16-й версии, по крайней мере у меня, такого больше не случалось, она работает.

  • Скажите, пожалуйста, как у вас реализован процесс тестирования – у вас разработчики проводят какие-то свои юнит-тесты, когда они интегрируют?

  • Так как у нас нет выделенных тестировщиков, у нас разработчики пишут тесты на то, что они написали, сами. Покрытие тестами мы не считаем.

  • А в момент подготовки релиза вы проводите полное регрессионное тестирование? Прогоняете все тесты, которые у вас есть?

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

  • А вы для каждого теста подготавливаете среду отдельно, как рекомендуют сами разработчики? Или все тесты всегда выполняются на одной и той же базе?

  • Тесты в одной и той же базе – это неправильно. Если я сценарий «Создать город» запущу 10 раз в одной базе, у меня будет 10 одинаковых городов. Это будет не совсем красиво – я испорчу данные. У нас есть эталонная база, которая соответствует рабочей. Она отдельно подготавливается – обновляется из свежего cf-ника, на ней должен пройти весь процесс обновления от и до. А после обновления она сохраняется в dt-ник, который разворачивается в тестовую базу, где и запускается тест.

  • Вопрос про GitLab CI. У вас на слайдах еще был указан Jenkins. Получается, что у вас GitLab CI установлен на пользовательских машинах, а Jenkins запускает тесты уже где-то на сервере?

  • Просто мне понравился GitLab CI, потому что он легко запускается. Я себе его поставил и свою ветку проверяю с его помощью, а основная ветка проверяется с помощью Jenkins на сервере.

  • А где вы просматриваете результаты тестирования? Куда вы их выгружаете?

  • На сервере с Jenkins мы просматриваем результаты тестирования в Allure, а результаты тестирования в своей ветке я смотрю просто в логах, я не стал себе усложнять жизнь.

  • Весь мир заболел DevOps, когда вышла книжка «Проект Феникс». Там одна из фраз мастера, который направлял компанию на путь к DevOps, была такая: «Вы должны делать выкладки в рабочую базу несколько раз в день». Насколько вы приблизились к DevOps по этому показателю?

  • Я не согласен с этим. Выкладки несколько раз в день в рабочую базу для 1С ведут либо к динамическому обновлению, либо к постоянному выкидыванию из базы пользователей. Я не сторонник ни того, ни другого.

  • И второй вопрос – насколько вам удалось размыть эту грань между разработчиками и системными администраторами, чтобы упростить процесс коммуникации между ними?

  • Кстати, когда я объяснял методологию DevOps, я ничего не рассказал про «Инфраструктуру как код», потому что, когда мы включаем сисадминов в цикл разработки, они тоже становятся программистами – они пишут код, чтобы собрать контейнер, в котором запустится все остальное, и этот код тоже хранится в том же в репозитории. Получается, что помимо разработчиков 1С у нас появляются еще и разработчики-сисадмины, которые пишут свой код, и они тоже бегают по этой же восьмерке. Сейчас у нас нет своих серверов, мы их арендуем, и в данный момент ведем переговоры, чтобы арендовать мощности и разворачивать уже полноценные контейнеры – то есть разворачивать тестирование не в терминальном режиме, а с помощью контейнеров. Хотим сделать, чтобы все было хорошо и красиво. Обязательно, как только мы это запустим, мы и расскажем, и покажем, и предложим вам этим воспользоваться.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Krasnodar. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в тематических митапах Инфостарта: infostart.ru/events/

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user692332_tomskih_nl 19.07.21 06:34 Сейчас в теме
Добрый день ! В статье упоминается - стандарт рабочего места программиста 1С, скажите где можно ознакомиться с этой информацией от фирмы 1С ?
Оставьте свое сообщение

См. также

Как Gitlab-CI и OneScript могут отсортировать массив (Часть 1)

CI/CD OneScript Бесплатно (free)

С приходом в 1С EDT мы получили git. С git-ом пришел и gitlab, а он уже дает инструменты по CI. Что такое CI? Ну все же знают, как обычно просят обновить прод? Желательно ночью? Желательно проверив на копии, что ничего не сломаем? Ну так вот: CI – это личный помощник, который все сделает сам. Надо только правильно его попросить...

18.11.2021    1768    SaschaG    9    

Окей, Google

Интеграция с сервисами Искусственный интеллект (AI) docker v8 Россия Бесплатно (free)

Пример интеграции Google Ассистента с 1С. В основе которого лежит платформа Dialogflow CX для понимания естественного языка.

28.10.2021    1181    Soloist    6    

Девопсы в 1С: микросервис распознавания штрихкодов

WEB Git (GitHub, GitLab, BitBucket) DevOps Практика программирования Бесплатно (free)

Распознавание штрихкода из сканированного документа в PDF.

09.08.2021    1592    alexey_kurdyukov    8    

Как начать разработку проекта 1С, чтобы легко перейти к DevOps-практикам

DevOps CI/CD v8 1cv8.cf Бесплатно (free)

Многие рутинные операции при работе над проектом 1С можно автоматизировать – довериться готовым инструментам и уменьшить количество нажимаемых кнопок. О том, как с помощью готового шаблона проекта настроить окружение для разработки на митапе «DevOps в 1С» рассказал технический директор Инфостарта Артур Аюханов.

22.06.2021    5146    artbear    2    

Микросервисы на Golang. Часть 6. Докеризация, Начальная оркестрация, CD\CI

Интеграция с оборудованием и сервисами CI/CD docker 1cv8.cf Бесплатно (free)

Создадим микросервис, поместим его в докер, проведем его масштабирование на нескольких виртуальных машинах с помощью оркестрации Docker Swarm, выполним также CD\CD микросервиса с помощью GitHub Action (Микросервис взят с прода, обрезан лишний функционал) будет показан пример его взаимодействия с 1С клиентом.

21.06.2021    1411    dmitry-irk38    1    

Практические кейсы и примеры создания сценарных тестов с использованием фреймворка Тестирование 3.0

Сценарное тестирование Бесплатно (free)

Начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков на Infostart Meetup DevOps продемонстрировал коллегам работу фреймворка «Тестирование 3.0», рассказал о процессе совместной разработки тестов и порассуждал о мировых тенденциях в тестировании.

11.06.2021    4011    ivanov660    26    

Docker для 1Сника

docker v8 Бесплатно (free)

На онлайн митапе «DevOps в 1С» Руслан Жданов рассказал, для чего 1С-нику нужен Docker, как его применять, какие сервисы можно вынести в контейнеры и как организовать взаимодействие контейнеров друг с другом.

07.06.2021    5033    ZhdanovR    32    

Мастер-класс: Реализация цикла CI/CD на практическом примере с использованием системы Тестер

CI/CD Git (GitHub, GitLab, BitBucket) Сценарное тестирование v8 Бесплатно (free)

На онлайн-митапе Инфостарта «DevOps в 1С» выступил Дмитрий Решитко – руководитель отдела разработки в компании C.T. Consultants Inc. Дмитрий провел мастер-класс, в котором продемонстрировал, как создавать новую функциональность в конфигурации с одновременным использованием инструмента тестирования и реализовать автоматизированное тестирование конфигурации при помещении кода в репозиторий на GitLab.

31.05.2021    1505    grumagargler    0    

Vanessa Automation. Как начать создавать видеоинструкции

BDD/TDD-тестирование, Vanessa Бесплатно (free)

Автоматические видеоинструкции на основе сценариев тестирования поражают воображение. Но многие сталкиваются с проблемами при попытке создать собственные фичи для видео. В ходе мастер класса на онлайн-митапе «DevOps в 1С» Светлана Попова рассмотрела особенности создания видеоинструкций с помощью Vanessa Automation для SikuliX и веб-клиента. И рассказала, какие подводные камни нужно учесть при их написании.

26.05.2021    3837    SvVik    10    

Осторожный DevOps

DevOps v8 Бесплатно (free)

Начальник отдела разработки в компании «Билайн» Игорь Сухоруков на Meetup Infostart DevOps поделился особенностями работы своего ИТ-подразделения и рассказал о том, как устроено производство и внедрение ПО в режиме нон-стоп в компании, подразделения которой работают по всей России: от Москвы до Владивостока.

24.05.2021    2489    ig1082    3    

Автоматизация расчета покрытия кода тестами

SonarQube Скрипты автоматизации Сценарное тестирование Бесплатно (free)

На Infostart Meetup, посвященном DevOps-технологиям, с докладом о том, как автоматизировать расчет покрытия кода, выступил программист компании 42Clouds Станислав Косолапов. Станислав рассказал об инструменте собственной разработки для таких задач и показал работу решения на практике.

21.05.2021    4387    amoarok    10    

Ненавязчивая локальная разработка с traefik2, docker и letsencrypt

Групповая разработка docker Бесплатно (free)

Перевод статьи по проксированию HTTP траффика до сервисов развернутых в docker контейнерах. Оригинал от 24.09.2020.

16.05.2021    1830    malikov_pro    0    

Шпаргалка установки сервера взаимодействия без MSI(9.0.33) использованием Postgresql в docker-compose

docker v8 Бесплатно (free)

Какой бы не был бизнес - он нуждается в коммуникации. У кого-то Telegram, у других - Whatsapp, у кого то - электронные письма. Возникла задача наладить общение между пользователями базы 1С без мессенджеров. Скачав самую свежую версию на момент написания статьи 9.0.33, обнаружились некоторые подводные камни при установке.

07.04.2021    1473    yaroslavkravets    0    

Как быстро развернуть автоматическую линию проверки своего решения на 1С, затратив 8 часов и получив выигрыш в 1 человеко/месяц

DevOps SonarQube BDD/TDD-тестирование, Vanessa Бесплатно (free)

У разработчиков 1С уже есть все инструменты, позволяющие использовать современные инженерные практики в 1С. О том, как за 8 часов внедрить автоматические проверки для решений на 1С, снизить в них количество глупых ошибок, а также высвободить ресурсы на более интеллектуальную работу на INFOSTART MEETUP Ekaterinburg.Online рассказал Артур Аюханов.

05.04.2021    6408    artbear    16    

Тестируем в Docker

docker Бесплатно (free)

Чтобы продукт гарантированно отвечал функциональным требованиям, нужно писать для него тесты и часто их запускать. О том, через какие этапы проходит компания, которая хочет автоматизировать тестирование – от одного клиента на локальной машине до запуска тестов по запросу в Kubernetes, на INFOSTART MEETUP Ekaterinburg.Online рассказал Андрей Крапивин.

29.03.2021    4080    Scorpion4eg    8    

Ищем паттерны в сценарных тестах. Практика - Фреймворк Тестирование 3.0

Тестирование и исправление Сценарное тестирование Бесплатно (free)

Выполняем полуавтоматический поиск паттернов в записанных новых или существующих сценариях и заменяем на готовые скрипты действий из библиотеки сценариев.

29.03.2021    1439    ivanov660    0    

Hello world в Vanessa-ADD bddRunner

Сценарное тестирование v8 Бесплатно (free)

Минимальный пример на Vanessa-ADD bddRunner без теории. При написании использовались: 1С 8.3.10.2753, Vanessa add 6.6.5.

24.02.2021    895    kirinalex    0    

1С on demand – скажи "нет" постоянным билд-агентам

Jenkins docker Бесплатно (free)

Каждый, кто пытался запускать на своем компьютере тесты для 1С, сталкивался с тем, что процесс тестирования не позволяет что-то делать параллельно. О том, как изолировать тестовые окружения и организовать «Агент по запросу» с помощью Docker на примере Jenkins CI, рассказал ведущий разработчик компании «Первый БИТ» Никита Грызлов.

25.01.2021    4092    nixel    12    

Практика применения DevOps. Автоматизированная сборочная линия

DevOps Бесплатно (free)

В четвертой части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступил Валерий Пронин. Он рассказал, как развернуть автоматизированную сборочную линию, которая будет контролировать качество кода в проекте и в зависимости от прохождения порога отдавать релиз в виде cf-файла либо отправлять письмо об ошибках.

16.12.2020    4890    proninvvp    5    

Практика применения DevOps. Тестирование

DevOps Сценарное тестирование BDD/TDD-тестирование, Vanessa СППР v8 1cv8.cf Бесплатно (free)

В третьей части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступила Светлана Попова. Она рассмотрела возможности использования двух инструментов тестирования от фирмы «1С» – «Сценарного тестирования» и связки СППР и Vanessa Automation, и рассказала про плюсы и минусы каждого из этих вариантов.

11.12.2020    5579    SvVik    0    

Практика применения DevOps. Работа с SonarQube

DevOps SonarQube v8 1cv8.cf Бесплатно (free)

Во второй части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступил Виталий Подымников – он рассказал про процесс проверки качества кода и использование SonarQube для работы с ним.

07.12.2020    8047    arcius_7012    11    

Практика применения DevOps. Автоматизация процессов разработки, инструментарий и работа с Git

DevOps Бесплатно (free)

Автоматизация процессов разработки с применением DevOps-практик помогает получать более качественный и осмысленный результат. На конференции Infostart Event 2019 Inception в ходе мастер-класса «Практика применения DevOps» команда Инфостарта разложила «по полочкам» инструментарий, который используется для каждого из процессов DevOps, и показала, как работать с ними на практике. В первой части выступил Павел Олейников – он сделал обзор инструментов, которые можно использовать при автоматизации процессов разработки, и рассказал про работу с Git (в том числе в EDT).

03.12.2020    4498    OPM    3    

Тестирование серверного поведения с Vanessa Automation

BDD/TDD-тестирование, Vanessa v8 Бесплатно (free)

Обзор модуля "ИнициаторДанных" (версия VA 1.2.034), пример скрипта

14.09.2020    2722    unichkin    14    

DevOps в команде специалистов 1С или сказ о том, как желтые котики хотели лучше работать…

DevOps Бесплатно (free)

Основные компоненты, на которых строится идея DevOps – это сотрудничество, доверие, инструменты и масштабируемость. И команда специалистов 1С, не подготовленная к соблюдению этих принципов, может столкнуться с проблемами при внедрении DevOps-практик. Как преодолеть эти сложности, и какие выгоды в результате применения DevOps-инструментов может получить компания, на конференции Infostart Event 2019 Inception рассказал руководитель отдела автоматизации предприятий ОП «Синимекс-Воронеж», Эмиль Карапетян.

04.09.2020    7087    amon_ra    2    

Управление конфигуратором в режиме агента с помощью python

Инструменты администратора БД Архивирование (backup) Скрипты автоматизации v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Управление конфигуратором 1С:Предприятие в режиме агента. Опыт применения с реализацией на языке python. Результат получен с использованием интерактивной сессии оболочки через invoke_shell().

06.08.2020    2035    Alex10166    2    

Мастер-класс "Ведение проектов в типовых конфигурациях 1С"

Методология CI/CD БСП (Библиотека стандартных подсистем) v8 Бесплатно (free)

При адаптации типовой конфигурации под особенности учета в компании важно обеспечить возможность легкого обновления поставки. Как организовать архитектуру решения и продумать процесс быстрой и эффективной разработки без ущерба типовой функциональности, на конференции Infostart Event 2019 Inception рассказал ведущий программист компании BIA-Teсhnologies Алексей Князьков.

05.06.2020    5101    AKnyazkov    4    

Vanessa, видеоинструкции для web-клиента

BDD/TDD-тестирование, Vanessa v8 1cv8.cf Бесплатно (free)

Vanessa-Automation. Использование видеоинструкций в web-клиенте.

01.06.2020    3732    SvVik    3    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Сценарное тестирование v8 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    5296    grumagargler    14    

"Война и мир" или DevOps в большом Enterprise

DevOps Бесплатно (free)

DevOps – это концепция разработки и поставки программного обеспечения, которая расширяет практики гибкой разработки Agile на весь жизненный цикл продукта. Но как применить эту концепцию в крупной компании, где любое изменение традиционно должно проходить большое количество согласований и проверок? Про свой опыт внедрения DevOps в большом Enterprise на конференции Infostart Event 2019 Inception рассказал руководитель направления DevOps в «Дирекции региональных продаж Газпром нефть» Марат Биккин.

08.05.2020    4416    squad    1    

Использование vanessa-runner/deployka в сборочных линиях Jenkins

Jenkins Бесплатно (free)

Библиотеки (shared-libraries) для Jenkins, пример сборочной линии.

26.03.2020    3946    ImHunter    3    

Визуализация фич Vanessa Automation в StoryMapper

Agile (XP, SCRUM, Канбан) Сценарное тестирование BDD/TDD-тестирование, Vanessa ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

21.03.2020    4168    oleynik.dv    7    

Пайплайны Jenkins - программирование и настройка. Загружаемые модули. Цикл "Многопоточный CI для 1С", часть 5

CI/CD Jenkins Бесплатно (free)

Рассмотрим создание пайплайнов Jenkins и библиотек собственных методов, язык Groovy, подходы к хранению настроек и обработке ошибок.

17.03.2020    21238    Vladimir Litvinenko    16    

Jenkins: конфигурируем сервер и подключаем к нему виртуальные машины. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 4

DevOps CI/CD Jenkins v8 Бесплатно (free)

Выполним основные настройки Jenkins как CI-сервера. Подключим к нему развёрнутые через Vagrant виртуальные машины в качестве сборочных узлов.

13.03.2020    17024    Vladimir Litvinenko    8    

Разворачиваем узлы CI через Vagrant, строим сеть из виртуальных машин. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 3

DevOps CI/CD Linux Бесплатно (free)

Разворачиваем инфраструктуру для CI из образов виртуальных машин.

04.03.2020    6941    Vladimir Litvinenko    14    

Собираем образ виртуальной машины с PostgreSQL и платформой 1С. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 2

DevOps CI/CD Linux Бесплатно (free)

Автоматизируем установку и конфигурирование Linux, PostgreSQL, 1C, Apache, Java с возможностью выбора версий дистрибутивов. Упаковываем результат в образ виртуальной машины.

28.02.2020    11159    Vladimir Litvinenko    11    

Технология разветвлённой разработки, использующая git, ci/cd

CI/CD Git (GitHub, GitLab, BitBucket) Методология управления разработкой EDT 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Адаптация и расширение требований к разветвлённой разработке с использованием git и ci/cd, основанное на стандартах 1С

24.02.2020    7810    check2    10    

CI/CD для 1С проектов, унифицировано, с кастомизацией

CI/CD Инструментарий разработчика Бесплатно (free)

Тема CI/CD в связке с 1С не нова, но многих пугает сложность использования и поддержки, необходимость обучения команды. Про то, как унифицировать и упростить поддержку сборочных конвейеров для большого количества решений, в своем докладе на конференции Infostart Event 2019 Inception рассказал начальник отдела компании BIA-Technologies Валерий Максимов.

20.02.2020    8334    theshadowco    13    

Тестирование: Отлаживаем и тестируем REST интерфейс 1С с помощью SoapUI

Сценарное тестирование v8 Бесплатно (free)

Рассмотрим быстрый и удобный способ облегчения разработки и отладки REST, SOAP веб сервисов, а также создания автоматизированных тестов.

03.02.2020    7005    ivanov660    4