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

Публикация № 1344163 16.12.20

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

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

Продолжаем цикл статей по практике применения DevOps.

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

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

В третьей части Светлана Попова рассмотрела работу двух инструментов тестирования – Vanessa Automation в связке с СППР и Сценарное тестирование.

А мы с вами соберем автоматизированную сборочную линию.

 

Параметры виртуальных машин для master и slave-нод

 

 

Давайте рассмотрим параметры виртуальных машин, которые мы будем использовать. Это два сервера – Ubuntu (он будет мастером) и Windows (он будет ведомым – слейвом):

  • на сервере Ubuntu установим Jenkins и GitLab.
  • на сервере Windows у нас уже установлены 1С, SonarQube, OneScript, EDT и Git, а также Java – в рамках мастер-класса мы их установку рассматривать не будем.

 

 

При конфигурировании виртуальной машины для Ubuntu нужно учитывать требования к оборудованию, предъявляемые программным обеспечением Jenkins и GitLab:

  • Jenkins требует 1 Гб и более памяти и 50Гб и более свободного места на диске.
  • А для GitLab – это 2 ядра и 8Гб.

Информация взята из официальных источников – jenkins.io и gitlab.com.

 

Установка программного обеспечения на сервере Windows

 

 

А на сервере Windows должно быть установлено следующее программное обеспечение:

  • обязательно нужен OneScript;
  • большинство действий по работе с 1С мы будем выполнять с помощью vrunner, поэтому его тоже нужно установить (также для работы vrunner требуется установить пакет vanessa-add):
    opm install add
    opm install vanessa-runner
  • Vanessa Automation;
  • платформа 1С, включая Rac и Ras;
  • EDT 14;
  • JDK 11 версии;
  • Git;
  • SonarQube и Sonar-scanner.

 

 

После установки программного обеспечения рекомендую проверить наличие путей в переменных среды:

  • в JAVA_HOME должен быть прописан путь к JRE;

  • а в PATH должны быть установлены пути для JDK, OneScript, Git.

 

 

Также в PATH должны быть прописаны пути к утилите ring для EDT.

 

Установка программного обеспечения на сервер Ubuntu

 

 

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

 

Ubuntu: Установка Java

Для работы Jenkins на сервере Ubuntu нужно будет поставить Java. Это можно сделать с помощью команды:

sudo apt-get install default-jdk

Результат установки можно проверить с помощью команды

java --version

 

Ubuntu: Установка Git

Чтобы Jenkins мог работать с исходниками репозиториев необходимо установить на Ubuntu Git. Это можно сделать с помощью команды

sudo apt install git

 

Ubuntu: Установка GitLab

 

 

Далее устанавливаем Gitlab.

Для его скачивания у нас должен быть установлен curl командой:

sudo apt-get install curl

Также нужно сделать настройку postfix, чтобы можно было отправлять уведомления по почте. Для этого выполним команду:

sudo apt-get install curl ca-certificates postfix

При установке выберем тип «Без настройки» – в этом случае мы можем настроить почтовый сервер позже.

 

 

Потом скачиваем GitLab по ссылке из репозитория:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

И запускаем непосредственно установку, указав адрес будущего сайта – мы разворачиваем GitLab в локальной сети по IP 192.168.223.128:

sudo EXTERNAL_URL="http://192.168.223.128" apt install gitlab-ee

И чтобы запустить GitLab применяем команду:

sudo gitlab-ctl reconfigure

После этого по адресу 192.168.223.128:8080 (8080 – порт по умолчанию) запустится GitLab:

  • при первом запуске задаем пароль пользователя root;
  • через административную панель добавляем пользователей и проект.

 

Ubuntu: Установка Jenkins

 

 

Для установки Jenkins мы будем использовать команды, которые представлены на официальном сайте Jenkins:

wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -

sudo sh -c 'echo deb https://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'

sudo apt-get update

sudo apt-get install jenkins

После установки нужно изменить порт, на котором будет работать Jenkins, потому что GitLab у нас установлен на этом же сервере, и использует тот же порт 8080, поэтому Jenkins мы поставим на порт 8081. Для этого нужно вызвать на редактирование файл, где указаны значения по умолчанию, выполнив команду:

sudo nano /etc/default/jenkins

в файле прописать

HTTP_PORT=8081

и после этого нужно перезапустить Jenkins командой:

sudo service jenkins restart

 

 

Проверить статус Jenkins можно командой:

systemctl status jenkins

Если все хорошо, мы увидим сообщение о том, что Jenkins активен (такое же, как на скриншоте).

 

 

После установки Jenkins мы можем уже перейти на URL 192.168.223.128 по порту 8081, который мы указали. При входе Jenkins попросит ввести пароль администратора.

Пароль администратора, сгенерированный при установке, хранится в каталоге /var/lib/Jenkins/secrets. Посмотреть пароль, который предлагает Jenkins, можно командой:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

 

 

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

 

 

Происходит установка плагинов Jenkins.

 

 

При первом входе нужно будет создать пользователя-администратора, задать его логин и пароль.

 

 

И прописать URL для Jenkins.

 

 

После этого, в принципе, половина этапа пройдена – считаем, что GitLab и Jenkins у нас установлены.

 

Интерфейс Jenkins

 

 

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

Самый верхний пункт «Создать Item» – это создание сборок или задач.

 

 

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

 

Настройка Jenkins

Далее – раздел «Настроить Jenkins».

 

 

Здесь первое, что нам нужно сделать – это настроить глобальные настройки безопасности. В группе Agents мы можем указать порт, по которому наши агенты будут подключаться к узлу master (по умолчанию заблокирован). Мы можем выбрать статичный или случайный. Укажем статичный порт 41000. Статичный порт удобно использовать, когда настроен файрвол – в самом файрволе вам нужно будет указать добавить в исключения порт и настроить права, чтобы агенты могли подключаться.

 

Установка и настройка плагинов

В разделе «Управление плагинами» нужно дополнительно установить плагины:

После того, как мы их установим, их нужно настроить.

 

 

Плагин Allure настраивается в разделе «Конфигурация глобальных инструментов» – здесь нам важно задать командную строку вызова allure.

 

 

И в разделе «Конфигурация глобальных инструментов» задать настройки вызова SonarQube Scanner.

 

 

А в разделе «Конфигурация системы» нужно указать URL сервера SonarQube.

 

Добавление узла

Теперь нам нужно добавить в Jenkins наш slave-узел. Этот шаг нужно делать, соединяясь с Jenkins по сетевому URL на машине, где находится наша ведомая Windows-система – там, где будет производиться непосредственное тестирование.

Для подключения агентов и создания новых узлов в настройках Jenkins есть раздел «Управление средами сборки».

 

 

Здесь мы создадим новый узел, поставим переключатель «Permanent Agent» и в окне со вводом параметров зададим:

  • Количество процессов-исполнителей – установим равным 2. Это количество процессов/задач, которое может одновременно выполняться на данном узле.

  • Корень удаленной файловой системы – у нас это будет C:\H. Это тот каталог на узле, в котором Jenkins будет создавать свои временные файлы (если этого каталога у нас на Windows-системе нет, его нужно создать).

  • Способ запуска – Launch agent by connecting it to the master

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

 

 

Откроем его настройки из браузера на машине, где находится наша ведомая Windows-система.

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

  • Первый способ запуска – это запуск Java-апплета, открываемого из браузера.

  • Второй способ запуска – это запуск из командной строки.

Воспользуемся вторым способом. Для этого нам необходимо скачать файл agent.jar по выделенной гиперссылке и сохранить его в папку C:\H.

Далее – скопируем текст предложенной команды.

 


Для этого в папке C:\H создадим файл run.bat и вставим в него скопированную команду.

Чтобы команда работала в кодировке UTF8, в начало нужно добавить:

chcp 65001

Также нам нужно будет указать, что сама Java должна работать в кодировке UTF-8 (чтобы при выполнении задачи в самом Jenkins не было нераспознанных символов), поэтому в строку нужно добавить параметр:

-Dfile.encoding=UTF8

Запустим этот батник.

 

 

Если подключение прошло успешно, будет выведено состояние Connected.

 

 

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

 

Настройка Pipeline

 

 

Давайте теперь создадим пайплайн.

 

 

Назовем его conf, нажмем ОК.

 

 

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

Например, нужно настроить параметр «Удалять устаревшие сборки» – мы в Jenkins будем хранить только результаты пяти последних сборок.

 

 

Также нам нужен будет флаг «Prepare an environment for the run» (подготовить переменные к сборке). Здесь в поле «Properties Content» мы можем задать значения переменных, к которым в дальнейшем будем обращаться из пайплайна, в виде соответствия имени переменной и названия. Я вставлю сюда следующий текст:

Server=infostart_fs
BaseName=infostart_conference_develop
RasPort=1545
Uccode=123

Это – четыре переменные, которые мы будем использовать в пайплайне:

  • Server – сервер MS SQL, на котором у нас развернута база;
  • BaseName – имя базы, к которой мы будем подключаться;
  • RasPort – порт сервера Ras;
  • Uccode – код блокировки.

 

 

Далее в разделе Pipeline указываем настройки:

  • Pipeline script from SCM – это значит, что мы будем брать пайплайн скрипт из SCM-репозитория.
  • SCM – указываем Git.
  • Repository URL – указываем адрес репозитория на GitLab.
  • Credentials – укажем сохраненные настройки с доступом к репозиторию.
  • Выберем конкретную ветку – vpronin.
  • Script Path – укажем demo/jenkinsfile (путь в репозитории к Jenkinsfile), в этой сборочной линии мы будем использовать не основной дженкинсфайл, а демонстрационный, который сейчас сами напишем.
  • в поле Additional Behaviors добавим шаг поведения Clean before checkout (очистить перед сборкой, чтобы не было лишних файлов), этого будет достаточно.

Нажимаем Применить.

 

 

Попробуем собрать наш пайплайн командой «Собрать сейчас». Внизу видно, что пошла сборка – мы можем перейти по гиперссылке и посмотреть, в каком она состоянии сейчас.

 

 

Откроем вывод консоли (Console Output). Здесь видно, что к репозиторию он подключился и сборочную линию уже увидел, но из-за ошибки в дженкинсфайле сборка завершилась с ошибкой.

 

Структура репозитория проекта и файла jenkinsfile

 

 

Перейдем в каталог репозитория Conference с помощью Visual Studio Code и рассмотрим его структуру.

На слайде показаны самые важные элементы каталога проекта – это:

  • папка EDT с исходниками конфигурации;
  • папка features с тестами;
  • папка tools, которая содержит скрипты автоматизации, которые мы будем использовать;
  • и файл jenkinsfile, где находится основная сборочная линия.

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

 

 

Рассмотрим структуру файла jenkinsfile:

  • пайплайн начинается с ключевого слова pipeline;
  • далее идет agent – указывается, на каких агентах будет осуществляться сборка;
  • потом раздел environment – это объявление переменных;
  • затем раздел post – действия после завершения сборки:
    • в разделе always указываются действия, которые будут выполняться всегда;
    • в разделе failure – действия, которые будут выполняться при ошибочной сборке;
    • и в разделе success – действия, которые будут выполняться при удачной сборке;
  • шаги располагаются в разделе stages:
    • каждый отдельный шаг располагается в разделе stage;
    • а сами действия в ветке steps.

 

Этапы сборки

 

 

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

 

Шаг №1. Подготовка среды

 

 

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

stage ("Подготовка Среды") {
    steps {
        timestamps {
            cmd("IF NOT EXIST ${WORKSPACE}\\out md ${WORKSPACE}\\out")
            cmd("IF NOT EXIST ${WORKSPACE}\\out\\junit md ${WORKSPACE}\\out\\junit")
            cmd("IF NOT EXIST ${WORKSPACE}\\out\\workspace md ${WORKSPACE}\\out\\workspace")
            cmd("IF NOT EXIST ${WORKSPACE}\\out\\conf md ${WORKSPACE}\\out\\conf")
            cmd("IF NOT EXIST ${WORKSPACE}\\out\\cf md ${WORKSPACE}\\out\\cf")
        }
    }
}

Здесь выполняются команды проверки наличия в рабочем каталоге папок:

  • out – если ее нет, она будет создана;
  • out\cf, где будет сохраняться файл конфигурации;
  • out\conf, куда из формата EDT исходники будут конвертироваться в формат конфигуратора;
  • out\workspace, который соответствует каталогу воркспейса EDT для утилиты ring;
  • и out\junit.

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

def cmd(command) {
    bat "chcp 65001\n ${command}"
}

Не забудем исправить ошибку, из-за которой сборка упала в прошлый раз. Сохраним, закоммитим и отправим в репозиторий.

Откроем Jenkins и попробуем собрать.

 

 

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

 

 

И дальше описывается выполнение этого Jenkinsfile - он создал в папке С:\H все необходимые временные каталоги.

 

Шаг №2. Сборка cf-файла конфигурации

 

 

Давайте перейдем к следующему шагу. На следующем шаге у нас будет подготовка исходников.

stage ("Подготовка исходников") {
    steps {
        timestamps {
            cmd("ring edt@1.14.0:x86_64 workspace export --project ${WORKSPACE}\\EDT --configuration-files ${WORKSPACE}\\out\\conf --workspace-location ${WORKSPACE}\\out\\workspace")
            cmd("vrunner compile --src ${WORKSPACE}/out/conf --out ${WORKSPACE}/out/cf/1Cv8.cf")
        }
    }
}
  • Подготовку исходников мы будем осуществлять с помощью команды ring. Как конвертировать проект из файлового представления 1C:EDT в xml-выгрузку конфигурации, описано на ИТС.
  • И далее мы из xml-выгрузки будем собирать cf-файл (файл конфигурации) с помощью vrunner. Если все пройдет без ошибок, после этой команды в рабочей директории в папке out/cf мы увидим файл конфигурации.

Давайте закоммитим изменения, отправим их в репозиторий и перезапустим нашу сборку.

 

 

У нас запустился процесс выгрузки файлов. После того как EDT закончила выгрузку файлов, дальше vrunner собирает конфигурацию из исходников. Операция завершилась успешно.

 

Шаг №3. Обновление существующей базы

 

 

Следующий шаг – это загрузка конфигурации в информационную базу. Для этого мы тоже будем использовать vrunner.

stage ('Загрузка конфигурации в базу') {
    steps {
        timestamps {
            cmd("vrunner load --src ${WORKSPACE}/out/cf/1Cv8.cf --ibconnection ${baseConnection}")
        }
    }
}

Обратите внимание, что в этой команде используется параметр baseConnection (строка подключение к базе). Этот параметр мы опишем в разделе environment.

baseConnection = "/S${env.Server}\\${env.BaseName}"

Для его установки мы обращаемся к переменным, которые указывали в настройках pipeline (в поле Properties Content).

Сохраним, отправим. Пока что проверять не будем, потому что это долгий процесс – закончим все остальное.

 

Шаг №4. Блокировка пользователей и принятие изменений

 

 

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

stage ('Принятие изменений') {
    steps {
        timestamps {
            cmd("vrunner session lock ${rasConnectionString}")
            cmd("vrunner session kill ${rasConnectionString}")
            cmd("vrunner updatedb --ibconnection ${baseConnection} ${uccodeString}")
            cmd("vrunner session unlock ${rasConnectionString}")
        }
    }
}

Данный раздел состоит из нескольких команд vrunner.

  • Первая команда – это session lock, т.е. мы заблокируем работу пользователей.
  • Потом мы завершим работу пользователей командой session kill
  • Далее – выполним команду updatedb с указанием параметров подключения к базе данных и кода блокировки.
  • И в дальнейшем мы разблокируем базу данных для дальнейшей работы.
uccodeString        = "--uccode ${env.Uccode}"
rasConnectionString = "--ras ${env.Server}:${env.RasPort} --dn ${env.BaseName} ${uccodeString}"

Здесь нам в разделе environment нужно задать значения параметров uccodeString и rasConnectionString.

Значения переменных Uccode, Server и RasPort для этих параметров мы указывали ранее в шаге настройки пайплайна.

Тоже сохраним и отправим этот шаг.

 

Шаг №5. Синтаксический контроль

 

 

Следующий шаг – синтаксическая проверка.

stage ('Синтаксическая проверка') {
    steps {
        timestamps {
            cmd("vrunner syntax-check --junitpath ./out/junit/syntaxCheck.xml --ibconnection ${baseConnection}")
        }
    }
}

Синтаксическую проверку мы тоже будем выполнять с помощью vrunner командой syntax-check:

  • с помощью параметра --junitpath мы указываем, куда положим xml-файлик с результатом проверки;
  • и с помощью параметра --ibconnection нам нужно указать настройки подключения к базе.

 

Шаг №6. Тестирование функциональности

 

 

Далее у нас будет шаг «Тестирование функциональности».

stage ('Тестирование функциональности') {
    steps {
        timestamps {
            cmd("vrunner vanessa --settings ./tools/json/VanessaRunner.json --ibconnection ${baseConnection}")
        }
    }
}

Тестирование функциональности мы будем запускать с помощью vrunner, который будет непосредственно запускать уже Vanessa Automation.

Запускать мы будем с помощью --settings с указанием настроек запуска Vanessa Automation, которые у нас хранятся в файле tools/json/VanessaRunner.json.

 

 

Давайте посмотрим структуру этого файла. Здесь очень много настроек, но нас интересуют параметры:

  • ВыполнитьСценарии – должно быть Истина.
  • КаталогФич – это наш каталог, где у нас будут лежать фичи.
  • КаталогВыгрузкиJUnit
  • КаталогВыгрузкиAllureБазовый
  • ЗакрыватьTestClientПослеЗапускаСценариев
  • И параметры подключения к клиенту тестирования

Более подробное описание настроек вы можете посмотреть в примерах из репозитория Vanessa Automation.

 

Шаг №7. Формирование отчетов Allure, SonarQube

 

 

И последний шаг – это у нас Sonar.

stage ('Sonar') {
    steps {
        script {
            scannerHome = tool "sonar-scanner"
        }
        withSonarQubeEnv("Sonar"){
            cmd("${scannerHome}\\bin\\sonar-scanner")
        }
    }
}

Здесь нам нужно описать переменную scannerHome:

def scannerHome

 

Шаг №8. Настройка шагов и артефакты сборки .cf

 

 

Давайте в раздел post добавим:

post {
    always {
        junit allowEmptyResults: true, testResults: '**/out/junit/*.xml'
        allure includeProperties: false, jdk: '', results: [[path: 'out/addallure.xml']]
        archiveArtifacts artifacts: '**/out/cf/*.cf', onlyIfSuccessful: true
    }
    failure {
        cmd("vrunner session unlock ${RasConnectionString}")
    }
    success {
        cmd("echo success")
    }
}

Это значит, что мы будем:

  • выгружать отчет в Junit;
  • отслеживать состояние сборки в Allure;
  • и архивировать артефакты сборки – cf-файл конфигурации будет прикреплен в Jenkins.

 

Результаты сборки

Давайте теперь попробуем собрать:

  • первый шаг – получение исходников;
  • далее – подготовка среды;
  • далее – подготовка исходников (здесь он генерирует файл конфигурации);
  • далее – шаг загрузки конфигурации в базу;
  • далее – принятие изменений;
  • далее – синтаксическая проверка;
  • далее – тестирование функциональности, где у нас запускается 1С и прогоняются сценарии.
  • далее – запускается сонар;
  • и выполняются действия по завершению.

 

 

Мы видим строчку сборки, у которой появился:

  • значок Allure – можно пройти и получить результат нашего тестирования с помощью Vanessa Automation.
  • и значок SonarQube – в него тоже можно провалиться и посмотреть, какие ошибки нашел Sonar.

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

 

Вопросы.

  • Вы показали и Vanessa Automation и Сценарное тестирование, но в линии участвовала Vanessa Automation. Что вы применяете на практике и какие заметили плюсы и минусы?

  • Первым мы развернули «Сценарное тестирование», хотели его использовать. А в дальнейшем посмотрели на Vanessa Automation, как она хорошо вкладывается в автоматизацию, вызывается и плюс она нам просто больше понравилась. Поэтому у нас в сборочной линии именно Vanessa Automation. Она много позволяет, хорошо встраивается. Почему нет? А в связке с СППР это оказался еще и более интересный продукт за счет того, что СППР может отслеживать еще и саму структуру конфигурации. Можно в ней рисовать, потом программировать и тут же тестировать. Получилась цельная инфраструктура, цельная экосистема.

  • Я правильно понимаю, что вы считаете, что Vanessa Automation – это наиболее функциональный вариант?

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

  • Здесь не упоминалась «Автоматизированная проверка конфигурации» – вы не пробовали использовать ее совместно с SonarQube?

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

  • А не пробовали расширять правила для SonarQube?

  • Мы используем тот набор правил, который есть в OpenSource. Его, конечно, не для всех целей хватает. Но опять-таки, можно выгрузить проверки из АПК. И Community Plugin развивается, но просто руки еще не дошли. Всегда можно самому поучаствовать – у них есть репозиторий, где в принципе описано, как можно эти правила туда дописать, если хочется.

  • И еще вопрос по поводу линии сборки – вы сравнивали Jenkins и Teamcity?

  • С Teamcity не работали. Выбрали Jenkins, потому что есть готовая документация, есть готовые примеры. Мы не рассматривали всех конкурентов, мы выбрали то, что нам больше подошло.

  • Тут вопрос больше к практике применения – что для 1С удобнее ложится? Jenkins, Teamcity или без разницы?

  • Нам больше подошел Jenkins.

  • SonarQube – это же больше статическая проверка кода. Кто на практике следит за разработчиками в части правильной разработки? И куда это вписывается в этот пайплайн?

  • Да, SonarQube не проверяет архитектуру, он проверяет просто синтаксический контроль. Да, должен быть архитектор. В том же СППР если мы рисуем проект – там это можно посмотреть. Архитектор здесь не отменяется. Это все не отменяет архитектора как такого? Это упрощает жизнь архитектора. Архитектор может тратить время на то, чтобы проверять именно функциональность. А эти все вещи автоматизированы и на это мы время не тратим, мы просто смотрим результат.

  • То есть, он существует где-то в фоне, или он уже после SonarQube проверяет, если все ок?

  • Он, в том числе, проверяет до входа в это все. С архитектором должны быть согласованы все эти изменения. Когда кто-то добавляет новый объект, он это делает не потому, что сам захотел, а он должен это согласовать, обосновать, что он нужен.

  • А ошибки, которые генерируются SonarQube – они попадают в систему учета задач? Как обеспечивается постановка и контроль задач при этом?

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

  • Все это мы исследуем и эту методологию разрабатываем, чтобы, в конце концов, это масштабировать на уровень портала, чтобы мы открыли свой BPM уже с интегрированными этими DevOps-технологиями. Уже из самой задачи будет создаваться некая виртуальная среда, в которой это все будет. Поэтому у нас в планах это все отдать сообществу. И, соответственно, привлечь его для написания этих сценариев тестирования и т.д. Мы будем это продвигать и всячески пропагандировать

  • Кто у вас в команде пишет функциональные тесты на языке Gherkin? У нас на работе я сейчас тоже продвигаю DevOps и тяжело передать это кому-то. Нужно обучать отдельного человека, наверное. Расскажите, как у вас.

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

  • А что вы можете сказать про оповещения SonarQube? У нас тоже SonarQube подключен, но оповещения на почту вообще не информативные. Может быть, это как-то настраивается?

  • Как вариант, можно из Jenkins посылать, если что-то упало. Не прошел порог качества – можно из Jenkins посылать. Он интегрируется с очень многими мессенджерами. Есть отдельный плагин для Slack, например. Почта – это то, что есть из коробки. А остальное нужно понастраивать. Лично мне хватает гиперссылки – он ссылается сюда, иди туда, смотри здесь. Проваливаешься и уже понятно, на что он ругается.

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

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

  • Получается, что для каждого автотеста нужно написать свой вариант?

  • Нет, тест один и тот же. Мы же проверяем одни и те же действия, мы просто разные профили запуска указываем – в каком контексте запускается данный тест.

  • Проводили ли вы нагрузочное тестирование сборочной линии на примере какой-нибудь типовой конфигурации – Бухгалтерия, Зарплата? Мне интересно за время, которое выполняется?

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

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2019 Inception. Больше статей можно прочитать здесь.

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Dach 322 18.12.20 12:34 Сейчас в теме
На github случайно не выложены все эти файлики для пайплайна в отдельном репо?
2. Kyrales 141 14.04.21 15:50 Сейчас в теме
3. Darknessalex 11.06.21 00:52 Сейчас в теме
Доброго времени суток!
Воспользовался данной статьёй, чтобы попробовать реализовать сборочную линию, но столкнулся с проблемой на этапе подготовки исходников. Сначала EDT выдаёт сообщение с нарушенной кодировкой, а затем на этапе C:\H\workspace\conf>vrunner compile --src C:\H\workspace\conf/out/conf --out C:\H\workspace\conf/out/cf/1Cv8.cf выдаёт ошибку о том, что файлов в папке out нет. Их на самом деле там нет.


Не очень понимаю, почему туда не помещаются файлы и почему кодировка в сообщении EDT кривая. Может быть суть проблемы кроется там?
Надеюсь на Вашу помощь!
5. user1411559 16.11.21 14:48 Сейчас в теме
с начала надо декомпилировать конфигурацию
vrunner decomplie, появится нужный файл которого не хватает, после чего уже можно из исходников собрать .cf
4. user1411559 16.11.21 14:45 Сейчас в теме
Полезная статья, автор подскажи пожалуйста, как внести изменения в конфигурацию из исходников, минуя все хранилища конфигурация
Оставьте свое сообщение

См. также

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

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

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

18.11.2021    1769    SaschaG    9    

Окей, Google

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

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

28.10.2021    1182    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    5147    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    4012    ivanov660    26    

Docker для 1Сника

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

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

07.06.2021    5035    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    3838    SvVik    10    

Осторожный DevOps

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

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

24.05.2021    2490    ig1082    3    

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

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

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

21.05.2021    4389    amoarok    10    

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

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

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

16.05.2021    1832    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    4081    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 становится актуальной благодаря бесплатным инструментам автоматизации для проектов на 1С. О том, как вести разработку по DevOps и какие при этом могут возникнуть проблемы и сложности, рассказал разработчик Инфостарта Павел Олейников.

15.01.2021    4177    OPM    2    

Практика применения 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    4499    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    7090    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    21240    Vladimir Litvinenko    16    

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

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

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

13.03.2020    17027    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    7811    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