Быстрая настройка конвейера автотестирования для 1С с хранилищем и Git // «Архитектор 1С»

Так, сейчас. Так, сейчас, наверное, должен быть. Всё, всё.

Тема сегодняшнего занятия: быстрая настройка конвейера тестирования для 1С хранилища. Обсудим, какие компоненты нам будут нужны, соответственно, переговорим, а что можно применить, как развернуть и научиться пользоваться всем тем инструментарием, что у нас есть, как обойтись малой кровью, то есть, если какие-то варианты, соответственно, будем выбирать, обсуждать, ну, и строить компоненты нашей виртуальной машиночки. Посмотрим, что у нас получится, какие будут результаты.

Так, сейчас, надеюсь, да, слышно, видно. Мы уже тут всё проверили. Спасибо.

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

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

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

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

Мария, разработчик 1С, получить новые знания. Артём, фронтенд 1С. Интересное сочетание, но бывает. Если не написано 1С, значит, скорее всего 1С по дефолту, да, как понимаю. Ведущий разработчик Константин. Илья, программист, бизнес-аналитик. Имеем сти на заводе, ищет курс для сотрудников. Понятно. Тестировщик. Тестировщик десктопного банковского ПО, новое знания. Разработчик 1С Елена. Так, эксперт 1С на КПХ. Александр, Антон, Кnetно GS. Посмотреть, что в ДНС не только бухгалтерия, инженерной практики. Анастасия, тестировщица, автотесты. Так, Татьяна, Антон, три плюса, видимо, присоединяется, да? Техарх 1С, да, находится в контексте. Александр, ведущий специалист прикладного про. Понятно. Так, архитектор 1С, смотреть, что нового. Ну, собственно, так, вижу, да, что у нас тут есть и профильные специалисты, кто уже занимается архитектурой. Ну, возможно, да, чтобы расширить как горизонты, что мы можем самостоятельно, да, ещё сделать.

Так, хорошо. Так, ладно, давайте продолжим.

Немножечко о нашей школе, о курсах, да, соответственно, чтобы тоже в контексте, чем занимаемся. Специфика - это авторские онлайн-курсы для специалистов уровня от джуна до лидов. В основном-то это у нас крепкие медлы. Разработка программ на основе запросов эти компании кандидатам. Ну и, соответственно, получение обратной связи, собеседований, ну и в том числе и оценка тех уровней кандидатов, которые непосредственно к нам на собеседование приходят. Выдаётся удостоверение повышения квалификации, здесь переподготовки, если необходимо. Направление различное, то есть тут в контексте тех трендов, которые сейчас требуются в современном мире, и программирование, архитектура, инфраструктура, в том числе и управление, и анализ, аналитика, тестирование. Так или иначе какие-то перетоки между различными курсами есть. Понятно, что у нас искусственный интеллект, он сейчас наполняет, да, какую-то часть этих направлений, так или иначе, да, участвуем, но опять же, встраивая всё это в контекст тех требований, которые нам выставляют компании.

Ну и давайте перейдём непосредственно к нашей теме, а именно посмотрим, что на сегодняшний день у нас есть из инструментов. Что из себя может представлять конвейер автотестирования для 1С с хранилищем, да, и Git. Нужно ли, можно ли отказаться от хранилища, собственно, когда это оправдано? Вот есть определённые нюансы, всё ещё так или иначе. Поэтому, да, давайте будем в режиме диалога обсуждать и отвечать на эти вопросы.

Маршрут вебинара у нас состоит из таких двух больших частей. Мы поговорим об архитектуре конвейера CI/CD. Далее чуть подробнее по курсу, по структуре, в том числе и занятия в нём. Экономические плюсы конвейера, то есть, собственно, что он нам даёт, оправдан, не оправдан, то, собственно, попробуем какой-то подвести итог, исходя из того, что приходится изучать. Ну и соберём, да, обратную связь о том, что хотелось бы у себя это применить, а кому и как, и в каком виде, собственно, потому что, как мы будем смотреть, компонентов у конвейера, да, всё-таки не уменьшилось, но попробуем, да, оценить, может быть, что-то вы там скажете, поделитесь тем, что в это работает.

Цель: познакомиться с архитектурой, настройкой конвейера, да, для 1С, выбрать компоненты, линии сборки, ну, и смысл, собственно, автоматизировать работу команды, понять, что мы можем собрать и какие элементы целесообразно автоматизировать, что можно передать наружу. Ну, и в том числе, да, обсудим практики, кто как экспериментировал, да, с компонентами линии сборки. То есть получилось ли у кого-то укрупнить, да, специалистов сделать более универсальным.

И первая часть, собственно, такая теоретическая и обсуждение - это архитектура конвейера CI/CD. Посмотрим, что у нас входит, да, в конвейер, что из этого у нас закрывается наша система 1С. Да, что для чего нам необходимо, а дополнительные инструменты.

Так, сейчас. Ну, здесь немножко вводная, да. Как не секрет для всех нас, что сейчас бюджеты ограничиваются, проекты схлопываются, да, в какой-то мере. Но тем не менее требования к тому, чтобы конвейеры работали, тестирование продолжалось, да, то есть, соответственно, проверки и автоматизация выполнялась. И сейчас автоматизация не просто, да, один из способов снижения риска, а как технологического, так и риска того, что там наш проект рассыпется или заказчик разочаруется в наших инструментах, ну, и в том числе наших рисков как специалистов. То есть нам ставят задачу это оптимизировать тестирование зачастую малой кровью. И это может потребоваться, ну, практически, да, от каждого разработчика 1С. Ну, опять же, из практики это и вопросы и к аналитикам приходят. То есть читать разные роли сейчас является одним из актуальных задач на сегодня. Ну, и мы попробуем, да, разберём, из каких компонентов у нас состоит подключение конвейера, тестирование, а когда он будет у нас актуален. Опять же, думаю, сейчас будут коллеги, кто у нас продвинутые инструменты использовать. Может немножко там вперёд забежать, но тем не менее так.

И что у нас есть? Почему до сих пор у нас живёт традиционное хранилище? Тут давайте этот вопрос будет в том числе и к вам.

Так, картинка. Так, коллеги, картинка есть, да? Есть. Угу. Должна быть. Аа тут сразу же такой вопрос. Причины, почему сейчас традиционное хранилище всё ещё живо, да, несмотря на то, что у нас у него недостатки уже там известны более 20 лет, да, там или сколько у нас получается платформу, да, наверное, это и в одном файле всё хранится, да, в бинарном формате. И код у нас изолирован от внешних систем. Дефекты в какой-то мере, да, выявляются вручную и автоматизация не настолько распространена, да, если это не применять, да, какие-то системы. Ну, и блокировка релизов вследствие и специфики работы с хранилищами, она выполняется, собственно. Несмотря на то, что, да, требования бизнеса требуют на сегодня это снижение уровня дефектов в продуктив до нуля, это высокая скорость поставки и отсутствие потерь информации на пути кода клиенту. Контроль качества бизнесу, да, хочется видеть в течение, да, достаточно оперативного времени после того, как разработчик что-то сделал, да, желательно в течение дня, чтобы мы могли показать и рассказать коллегам, что у нас новенького, да, что у нас получилось.

Почему всё-таки, как вот по вашему мнению, традиционное хранилище всё ещё живо? Ну, то есть тут, может быть, какие-то моменты есть. Ну, есть, да, одна там достаточно существенная причина, почему живёт, да, хотя инструмент имеет, да, определённые плюсы, но так и давайте, да. Ага.

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

Технологический порог у Антона. Предположительный вопрос. То есть что это за технологический порог? Имеется в виду, что подготовленность коллег, разработчиков, то есть достаточно низкая, наверное. Может быть, это имели в виду. Так, а, ну да, вот переобучение, технология.

Так, ну вот у Марата, да, собственно, один из самых проблемных вопросов, который всё ещё остаётся нерешённым и специфически, да, опять же, а тот инструмент, который коллегами разработан, он изначально рассчитан на ресурсы, которых аа не все компании могут предоставить при нормальной разработке в ЕДТ. А что у нас требуется? Чтобы компьютеры разработчиков были 32-64 ГБ, а Core i А9, там какой-нибудь Nvme, а что в виртуальных ресурсах влечёт просто колоссальные затраты, да. Ну вот тут, конечно, это моменты эти есть. А вот именно даже 128 для ERP. А вот ещё, да, серьёзнее даже получается, по сути чуть ли не кэширование в памяти во всей всей системы, да, чуть ли не всей базы, чтобы с этим всем разработчику, э, соответственно, взаимодействовать. Ну, а сейчас, да, зачастую, во-первых, у нас там какие-нибудь облегчённые виртуалки, ноутбуки с затушенными процессорами. А сейчас ресурсы общемировые ушли на Eи, а, соответственно, какие-то локальные места для разработки, да, пока, к сожалению, да, остаются ещё на уровне там 16-32 Гб, поэтому, да, вот моменты есть.

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

Ну, самый существенный, да, минус - это высокая стоимость. Что в условиях вот прямо тут большого минуса, да, бюджет, но здесь мы рассматриваем бюджет именно как паратный ресурсный. Да, изучить, как работает ИДТ можно, да, в какой-то мере работает с облегчённой конфигурацией можно, но когда мы попытаемся в реальных условиях её запустить, а, возникает проблема, да, и вот в команде пять-семь разработчиков, да, или, а, к примеру, вот у нас порядка сколько получается сейчас? 12 разработчиков, да, в четырёх командах. Ээ минус возникает какой? Ну, вот мы сейчас далее пройдём в хранилище. Это затирание кода разработчика одного предыдущим разработчикам, а, соответственно, к как бы может так минусы, да, плюсы. И вот мы не можем, да, полностью перейти на ИДТ со всеми её плюсами и всю команду перекинуть. Ну, и в том числе у нас ещё и могут быть какая-нибудь, а, комбинированная сборка, подрядчики, субподрядчики и так далее.

Разберём, какие минусы, какие плюсы в ээ монолитном хранилище 1С. Ну, самый большой минус, да, который нам нужно будет посмотреть и рассмотреть по преодолению - это невозможность параллельного кодрев. Раз. Во-вторых, невозможность какого-либо там параллельной разработки. Плюс, ээ, до тех пор, пока все разработчики у нас всё они поместят в хранилище. А, а, учитывая, что одни и те же объекты могут требовать разных доработок разработчиков, плюс есть подход, а, я думаю, вот многие она используется, когда, а, чтобы избежать захвата корневых объектов, да, каких-то общих, разработчик в отдельной конфигурации неподключенных хранилищ разрабатывает всё, что угодно, а потом временно там захватывает нужные объекты и перекидывает своё. В этот момент есть риск потери данных. А, а откат в обратную сторону, поиск того кода, что он мог случайно потереть в каких-нибудь там дважды изменённых функциях, он очень высокий. И здесь кроме какческого фактора, да, мы вот предложить, если мы каких-то дополнительных газок ничего не можем. А то, что вот мы ранее рассмотрели и как раз, да, вот Эмин озвучил, да, это полный переход на ИБТ. А-а, к сожалению, это экономически нецелесообразно. То есть здесь либо революция и ЕДТ станет когда-то либо очень быстрым, ну, либо современные компьютеры, да, станут каким-нибудь там 128 ГБ будет стандартом отрасли и считаться, да, плюс-минус, да, у каждого. Ну и скорость работы будет там, ну, скажем, не сильно отставать от скорости разработки в других облегчённых ишках типа, а того же, а Visual Studiaкод всевозможных и тех же инструментов, в которых сейчас коллеги разрабатывают. Там тоже Visual Studio обычный или от коллег что-то из питоновских, да, библиотек. Вот. Ну и вот этот момент, а он у нас продолжает и остаётся быть, что любая печатка, которая прокрадётся, пропустится тестирование, обрушит нашу базу. Так что дефекты нам нужно сокращать, э просто на одном хранилище без автоматизации, мы жить с вами не можем. А, и, собственно, один из вариантов решения, который сейчас строится и а пока что вот каких-то таких вот, может быть, появляются, да, алименты, которые могут это всё упростить, а они появляются, да, в библиотечке. Ну вот сейчас мы как раз мы про них проговорим.

У нас сейчас есть наша привычная среда разработчика, куда это всё размещается, да? И результат, если у нас нет каких-либо автоматизаций, то у нас хранилище 1С, поместился код, и в некоторых случаях, да, у нас может быть запущена, а какая-нибудь автотестирование, да, с генерацией отчёта. То есть, если не использовать конвейер, а, собственно, разработчики, да, наши всё помещают в хранилище. Но что нам хотелось бы видеть, да? Во-первых, на каждое помещение в хранилище, которое делают наши с вами коллеги, а необходимо, а-а, провести конвертацию того кода, который разработчик поместил. А, и сделать такой фоновый контроль и, ну, децентрализованный контроль версий и децентрализованный контроль изменений. В идеале, да, то есть вот здесь вот между вот этими сервисами, то есть сам GSН крутится, смотрит за хранилищем, а в тот момент, когда что-то туда поместили, да, в какой-то код, Гитсинка это всё забирает и делает ээ собственное помещение в хранилище Git в репозиторий от имени того разработчика, под которым у нас была авторизация в хранилище 1С. Собственно, у нас такие получаются, а, ветки виртуальные, да, в зависимости от изменения. Ну, а как они строятся, мы далее посмотрим. А чтобы то есть вот здесь мы добиваемся того, что у нас ведётся само по себе репозиторий Git. А как его построить и как экспериментировать? Далее посмотрим. На чём а самое простое его запустить тоже, собственно, сделаем следующее.

А теперь, да, у нас есть конфигурация. Мы сохраняем код, мы можем видеть изменения, мы можем, во-первых, отчётами смотреть, какие у нас происходили в системе и быстро откатиться по истории, а, по коду, да, пробежаться, потому что, я думаю, а, большинство из вас сталкивались с тем, что поиск история хранилища - это очень-очень-очень небыстро. Поэтому нам хранилище, да, вот это вот репозиторий, позволяет ускорить аналитику, делать отчёты и подключать современные инструменты за код. Здесь, а тут как бы единого стандарта для отрасли нет. Самое простое - это использование Дженкинса. Это, соответственно, инструмент, который запускает по расписанию скрипты, а-а, и отслеживает, э, как бы как оркестратор всего-всего вот этого вот нашего конвейера, от запуска Кисинка, а, до помещения контроль в Git, получение кода и, э, собственно передача в какие-либо дополнительные инструменты. Всё отсюда же стартует. Ну и результатом, да, это формирование отчётов валют, то есть непосредственно генерация метрик и создание тех отчётов, которые у нас тут. А получается.

Ну, если чуть-чуть пойти далее, а какие у нас ключевые компоненты стека, а пока ещё, да, сохраняющиеся и вот имеющие специфику. Основа разложения хранилища в архитектуру Git - это, а, среда Script, на базе которой у нас формируются скрипты на синтаксисе 1С без платформы 1С и может крутиться в том числе в контейнерах. И, а, утилитка GSН, которая инкрементальна, вместо выгрузки в XML забирает из нашего хранилища сведения изменений, сохраняя при этом авторство и комментарии программистов, в том числе формируя, а, ветки из тех комментариев, которые у нас разработчики по договорённости, по согласованию оставляют. То есть, если будут комментировать, а то можем отстроить. Так что у нас в Git по вот этим комментариям, а будут строиться так называемые такие виртуальные веточки и из них далее собираться конфигурация. Понятное дело, здесь сама сборка конфигурации, её, а-а, называемого разрешение конфликта, то есть её вот объединение, да, должна быть автоматизирована, потому что а но а увидеть, как это всё делалось, то есть посмотреть причины, да, там ведения, потом система может сама делать алерты, ну, система имеет вот сам а репозиторий, отвечающий за Git, то есть, соответственно, он это всё у нас собирает.

Сам Git, то есть для тех, кто ещё с ним не настолько знаком, а он состоит у нас из а трёх компонент, а иногда между ними коллеги путаются для тех, кто с ним постоянно не работает. Первая компонента - это у нас рабочая копия, то есть та папочка, с которой аэ разработчик в данный момент у нас работает. Сейчас, секундочку. Что мы сразу откроем? Так, сейчас. Так, давайте сразу же так. Так, ну вот в рамках папочки посмотрим. То есть наши компоненты. А что есть аа сам по себе? А то приложение, которое устанавливаем на локальный компьютер, а он отвечает за работу с двумя компонентами. Аа, то есть это работа с текущей копией, то есть то, что мы видим, а-а, в данный момент внутри папочки. А и, аэ, переключение между ветками. А те файлики, которые у нас в папочке здесь находятся, они, а, не упираются в скрытые папочки внутри, а, системной папочки Git. И оттуда актуальная ветка пересобирается, то есть из объектов, которые находятся внутри. То есть здесь у нас формируются и индексы, и изменения. То есть утилитка Git, она отслеживает, что у нас произошло с этой папочкой, а делает сравнение, выбирает файли, которые у нас были изменены, и, соответственно, эформирует веточку. Что такое ветка? Да, это внутри папочки Git. Если у нас несколько веток там разрабатывается, это несколько вот этих будет наших слепков, э файлов текущей папки и переключение, да, это вытащили, назад убрали, вытащили назад, убрали. А какими инструментами мы работаем именно с такой локальной папочкой? Ну, один из популярных инструментов от Windows, это Git Extension. А, но, к сожалению, он не имеет версии под Linux. Там есть всякие другие типа Git Kaken. А, но зато вот он выглядит привычно. А у нас, собственно, сейчас что-нибудь откроем. То есть у нас есть ветки, да, то есть визуальная оболочка, которая позволяет работать, вызывает команды Git. То есть сам по себе Git, а как приложение не имеет визуального интерфейса, и над ним строится визуализация. А для тех коллег, которые часто переключаются между Линуксом и Windows или работают целиком под Linux, ну, всё-таки освоить Visual Studio Code, ээ, который имеет большое преимущество и в том числе позволяет, соответственно, работать аа и с нумах, имеют там структуру плагинов. Вы можете установить без админских прав, а это очень высоко ценится. То есть, если там нет жёсткого платировки на приложение, а то Visual Studio Code, да, практически, да, в любой корпоративной инфраструктуре может быть установлен как редактор, это такой нетрепающий там записи в реестр, и на него там не ругаются корпоративная система контроля за версиями. Давайте сейчас тоже папочку откроем. Так вот, то есть другая другой вид. А кому-то он может быть менее привычен, да, соответственно, а идёт анализ изменений, да, то есть сколько чего у нас по сравнению с теми изменениями, которые произошли в основной, э, фалике. И вот система считает, как и вот, а, так здесь текущий он не выводит, но вот он считает, сколько изменений было сделано с основной веткой в сравнению с основной веткой. Но это у нас инициальная начальная выгрузка а произошла. То есть мы, например, когда есть в конфигурации, выгружаем кучу кучу файликов, да, система видит и ээ в этот момент проводит контроль и предлагает, да, то есть всё это у нас поместить в, а, так называемый репозиторий.

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

Так, дальше. А по компонентам один из вариантов, который можно использовать для первоначального изучения. Тут уже из пройденного опыта. Вот даже у нас тут вот подсказка идёт, какой репозиторий для старта нашего с вами конвейера применить. Может быть, кто-то с вами сталкивался из вот этих вот трёх вариантов. Это GitФК у нас подскочил, да, GitHub, а, и GTA. Может быть, кто-то про них слышал, кто-то знает, может, кто-то уже экспериментировал с реальными хранилищами репозитория, да, там есть ещё российские типа Gitвеers, э, и, э, source от Яндекса. А, ну вот с ходу сейчас пока вот не буду отвечать. То есть какие, э, есть там плюсы-минусы, да, у каждого.

Так, Александр, а с артефактами? Да, видео. Сейчас, секундочку. А так по видео, коллеги, если кого-то с проблемками до видео, тогда это пишите. Так, ага, спасибо. А в записи, если что, Александр, да, будет с видео норм, то есть, соответственно, качество, да, там будет всё видно.

Так, давайте к вопросу вернёмся. А, то есть, а, про выбор а репозитория, да, соответственно, на чём бы вы развернули? Так, Антон GitHub. Так, на чём бы вы вот стали работать? А, ну давайте с ходу нам нужно научиться, да, и так как времени нет, нам нужно ERP выгрузить. Так, ну GitLab имеет схожее, да? Так, имеем GitLub используем. Угу. Так, окей. Так, вижу, да, по вопросам. Ну, смотрите, то есть какой есть самый существенный момент, а тогда, когда мы только осваиваем этот инструмент и решили работать с конфигурацией, э, даже, например, уровня библиотеки стандартных подсистемы. Аа это ограничение наших вот этих хранилищ. 1С при выгрузке генерирует даже библиотека экосистем больше 10.000 файлов. А в архиве получается сколько? Более 100 Мб эти файлики запакованные уходят. И системы бесплатные, да, если не покупать платные тарифы. Gitliк, GitHub, а GitHub, нет, так вер по-моему тоже. А они скажут, что превышен размер файликов, размер на транзакцию, мы не можем такое принять. А, ну вот Антон пишет, да, когда, а, их все надо коммитить, что-то можно в Git игнор все, да, то есть это вот прямо вот не всё проходит ээ изменения. А мы, если возьмём PУХ, а спух как раз это то, ради чего мы, собственно, приходим к автоматизации. То есть нам нужно отслеживать изменения по ИПУХ, нам нужно провести базовую автоматизацию, то есть нам нужно ту систему, которая поддерживает, э, в идеале локальное развёртывание, ещё в идеале бесплатное локальное развёртывание на тот этап, когда нам, собственно, необходимо внутри всё развернуть. Мы возвращаемся к исходной нашей задачке, а именно, что у нас бюджет ноль. И давайте, а, посмотрим, какие системы можно использовать он примис. Ну, а так, сейчас, секунду. Так, сейчас ссылочку готовлю. Так. И скопируем. Так, одна из самых простых систем, которые есть практически на каждом домашнем насе, это а так и вариант это так, open sourceны вариант. И если ещё идти дальше, и нам необходимо, собственно, репозиторий иметь свой свой локальный, а опять же возвращаемся, что нам нужно быстро, дёшево и с минимальными рисками. Так, секунду. Так. То нам нужен такой продукт. Идём дальше. А, собственно, сразу же, да, при скачивании, а, у нас тут GTA в варианте GoGit выбирается. И посмотрим, что это у нас за зверь. Так, давайте сразу же я её у нас в отдельную папочку положу. Так, а это система, да, вот гита в чём её преимущество? Помимо того, что она есть практически во всех системах, достаточно высоко документирована, хорошо. А, но также поддерживает, э, возможность запуска. А без установки также можно с ней экспериментировать. Не надо там никаких хостингов, чтобы поучиться работать с системой, да, научиться настраивать конвееры, а демонстрировать его коллегам, э, соответственно, сдавать что-то, да, и тестировать перед тем, как давать далее. Запустили. А, и система предлагает накося зайти и произвести её первоначальную настройку. А, собственно, некоторые элементы мы сейчас не будем отдельно показывать, так как по ним много есть информации. То есть как установить Git и как настроить его. А, скачиваем, ставим, да, через далее, далее и настраиваем там гит для 1S, то есть этот шаг. Окей. Дальше one script тоже скачиваем, устанавливаем. Ну, отдельно посмотрим по компоненте, связанные с гипсинка. А теперь идём вот в те варианты, которые уже требуют не просто там скачать и далее, и далее, а уже какой-то такой базовые настройки. Ну, и первое, да, это своё вокальное.

свой локальный вариант репозитория GT, да, с которым хочется поэкспериментировать, посмотреть, какие настройки в нём сделать, чтобы двигаться далее. А вот Эмин, да, там писал как раз, что GitLab стоит. У Гитваба отличная система, а, но по ресурсам требует немножко больше, чем GTA, всё-таки.

Далее тут нозы за то, как там есть небольшой конвейер, вариант, который ставится для того, чтобы поэкспериментировать, поучиться, да, соответственно, научиться настраивать конвеер. Это с локальной базой SQL White. Наша задача сейчас учебная, и мы хотим всё разместить в той же системе. Дальше, ну, запуск и пользователя - это текущее. Всё остальное мы оставляем по умолчанию. А так настройки учётной записи администратора. Ну здесь давайте мы идём админ собакате. Ну и агин пароль тоже пусть будет админ. И установим.

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

Давайте мы пока просто создадим пустую папочку, а, проверим, что у нас код из конфигурации какой-нибудь наше демонстрацие приложения, например, выгружается и загружается назад, а, и появляется в репозитории. Поехали. Название. Ну, здесь будет тест. Аэ, не обязательно ставить его приватным. Это у нас на локальной машинке всё находится. Так, то, что коллеги уже упоминали про использование Gitignor, это для исключения, а, служебных файликов. Ну, вот здесь один эски, по-моему, у нас тут нет шаблона готового, который бы исключал лишние файлики. А, поэтому Gitignor а мы потом будем из библиотечки, а, специально брать для себя шаблон. Пока оставим всё по умолчанию. создать репозиторий. А сразу же системка, как и GitHub, так и как и другие, да, там большие крупные системы предложила вот на строчку.

Теперь мы этот репозиторий пустой, да, пустую папочку должны скопировать и поработать с ним, с инструментами. То есть один из этапов нашего конвеера, собственно, создать. Так, и мы создаём репозиторий, то есть создаём. А в пап Так, нет, не создаём. Мы сейчас клонируем репозитории. То есть мы его забираем с удалённой системы. Вот подставилось. Размещаем в папочке Git. Так, сейчас проверим, что у нас там с названием тест. Опок. Нет, так нету. клонировать, да? Ну, собственно, вот у нас пустая папка получилась. Так.

И теперь, а давайте в эту папочку мы просто создадим там под папочку, а src, а исходники, да, исходные текст source и в неё выгрузим, а файлики из конфигурации 1S. А вот эту операцию у нас далее должен выполнять GS в автоматическом режиме. А пока мы выгружаем напрямую из конфигурации на первоначальную инициацию, но в дальнейшем, да, у нас должна производиться синхронизация нашего хранилища. Так, выгружаем файлы, выбираем нашу созданную папочку элементы тест сцп выгрузить. А, всё, поехало. Так, выгрузились. А цвет у нас поменялся. 111 файликов выгрузилось из демонстрационной конфигурации. А, и теперь мы должны так здесь это, по сути, инициализация. Обязательно вте к каждому комидурий, то есть комит message, так называемый. И мы сразу делаем commit and push. То есть если просто комит, это фиксация изменений для того, чтобы аа их разместить далее. То есть мы фиксируем commit and push - это и фиксирует изменения в папочке и отправляет их. Так, делаем. А, предлагает всё про индексировать и отправить.

Так вот, смотрите, а первоначально у нас немножко не была донастроена система, а тут же, да, она нам предложила донастроить. И давайте мы с вами его донастроим. на путащие изменения. Так, сейчас, секунду. Так, открываем баш. И сейчас мы выполним пару команд, которые нам система уведомила, что она отправить не может, потому что они знают, кто мы такие. Так, чку так. А давайте, так как мы с вами всё делали админ, так и вторую команду это глобальное имя пользователя, от которого мы, э, делаем размещение. А сразу же, э, как для тех, кто следит, да? Получается, что вот эти вот элементы настройки, да, к сожалению, как сказать, всё в одном пакете. Э, так, давай, здесь тоже будет обмен, мы не имеем, поэтому пошагово каждую утилитку накидываем, настраиваем. Да, единым скриптом это можно сделать, но он не не универсавелен и годится лишь для того окружения, для а той ситуации, которую а так мы с вами проходим. Так, всё здесь сделали. Попробуем ещё раз. Так, всё у нас поехало. А GTA спрашивает, доверяем ли приложению, которое у нас делает размещение системы файликов. Доверим дан. Так.

И теперь у нас сейчас идёт вот инициализация. А вот наши файлики прилетели в наш собственный персональный репозиторий, а с которым мы можем работать. и далее подключать его к нашим системам автоматизации. При этом всё хранится локально, никаких пока там нарочных настроек не требовалось, ни веб-сервер там настраивать, ни хостинги какие-то поднимать. То есть всё у нас хранится в папочке. Так, давайте вернёмся к презентации, пройдёмся по остальным компонентам. То есть преимущество, что мы сейчас можем, как и вот маленькую, лёгкую конфигурацию, так и целиком ERP, да, с 10.000ми ми файлов всё это поместить, протестировать, чтобы всё проходит, да, настроить правильно игнор. То есть, по сути, а, используя, да, вот эту вот системку, мы можем в том числе и учить наших будущих там девопсеров или переучивать наших разработчиков работу с системой, потому что тоже Gitlab локально поставить ну, сходу не получится. Тут же вот вы посмотрели, да, по сути мы там за 5 минут локальные репозиторию себя развернули. Так, переключимся. Так. Так. Всё. Это у нас есть. Это у нас есть. То есть это три компонента у нас есть.

А теперь а что нам далее необходимо? Нам нужно, а то, что вот мы сейчас сделали руками, а именно мы транслировали, а наш код а из одински в репозиторий, соответственно должно заменить инструмент нскрипта, как всегда исполнения. А и её утилитка, а именно gits, то есть утилитка синхронизации. А цель которой - это выгрузка история комитов, конвертация, сохранение авторства тех разработчиков, которые нас делают. Ну, и, соответственно, вот следующий момент. А влоб решения - это Кром, то есть это использование запуска по расписанию. Следующий вариант, да, который самый продвинутый - это использование так называемых гитхуков. Э, соответственно, в тот момент, э, когда у нас идёт размещение, да, в хранилище, у нас должен сработать проверка, да, что какие-то изменения произошли, и утилитка, отслеживая изменения, стартует синхронизацию.

Так, а, но а так как сам по себе, да, уже настраивается чуть сложнее, а каким же образом мы будем поступать? Ну, и в принципе, я думаю, для тех из вас, кто уже знакомился, да, с конвейером, а нам нужен какой-то шаблон, да, так библиотека, а для работы э с вот этой утилиткой, да, чтобы ей передавать какие-либо настраие параметры, передавать настроек нашей базы, то есть какой-то упрощённый вариант, а-а, позволяющий в том числе, да, версионирование, соответственно, для этого всего, а, в практике использу Следующее, это используется библиотека для оркестрации сборочного цикла. Ну, и вариации этой библиотеки сейчас можно встретить достаточно много, но исторически а есть библиотека Вонесса, да, то есть с исходными, да, вариациями. А есть от крупного, от первого бита такая очень сложная библиотека. Первый бит марксистская, то есть у них есть своя собственная, да, сборочный цикл. Ну, и я думаю таких крупных франчайзе у них у всех есть уже такие сборочные циклы, то есть состав своих утилиток, а которые они размещают. То есть для чего используется вот эта библиотека и что она нам позволяет делать. А, во-первых, самое основное, да, то есть у нас внутри библиотеки есть Так, сейчас, а, Алексей про GitHook чуть сюда вернусь к нему. А по структуре библиотеки, во-первых, по сути, это у нас хранилище best practice, да, то есть лучших практик, то есть как лучше всё организовать, в какие папочки хранить и, э, например, в рамках удешевления процесса, а, непосредственно работы, э, и с документами, и с запросами. А мы даже можем, ну, вот используя даже ту же GTO, да, у нас же там, если заметили, есть в во всех системах даже кнопочка с задачи. То есть, если у нас совсем бюджет ограничен, мы можем из ГТ сделать и, а-а, по сути, систему обработки задач, введения контроля разработки, а, и уже как бы с ней работать такой как системкой такой внутри автоматизации и даже какие-то элементы документации хранить. А, во-вторых, внутри самого репозитория а располагать файлы от аналитиков, текстовые документы. На сегодня текстовый документы в формате Markда является полезной базой для работы с искусственным интеллектом. То есть мы можем для тех проектов, где это допустимо, а ссылка на наш репозиторий является для системы так называемой, а рак а библиотекой. Вот, то есть, а, по сути, такой внутренний и на основе него, да, там и может какие-то, а, вопросы отвечать, да, какую-то документацию написать. То есть, по сути, является какой-то такой внутреннейтекой для себя. А даже если мы не используем большие системы, а искусственного интеллекта какую-нибудь локальную, то есть опять же мы крутим из репозитория вот в рамках проекта, то есть те, а, документы, которые в нём используются.

А теперь разм далее. А что ещё? Самое существенный, да, момент. А внутри сборочного цикла а мы располагаем а логики для работы с системой оркестрации. А если мы используем Джен, соответственно, это Jenkins Shared Library, то есть общей библиотеки для Дженкинса. Если мы используем скриптики, а то есть по сути это заранее прописанные скрипты на языке одно слон. размещённые в соответствующих папочках, да, и это эти библиотеки у нас подключаются к самому. Дальше, ну, соответственно, код для мы не пишем, мы используем инструменты, наследуя их из проекта проект, адаптировав их под нашу компанию. Дальше. А, так, ну, тут я бы сказал, что Дженкинс гораздо чаще встречается. А просто Gitlab - это два в одном, а Jenkins - это только оркестратор, а Gitlab - это и оркестратор, и хранилище репозиториев. Поэтому для тех, кто может себе позволить по ресурсам GitLab, а для тех, кто, собственно, таких больших там инструментов не имеет или специалистов, которые могут с гитлабом на ты, да, легко там ориентируюсь, а то ставятся Дженкин, ставится гит. и поехали. То есть лёгкие, простые, высоко документированные инструменты. Ну, то есть здесь, а, как сказать, вот Дженкинсн больше, а, но Gitlab он надёжнее, на мой взгляд. Ну, как бы менее гибкий, зато а всё в одном. Мы чаще на проектах ставим Дженкинс опять же, потому что ресурсы ограничены и вот что-то покрутить, да, будет всё возвращаться. Так.

Ну и продельно проговорим про защиту конвейера с фиксацией версии тегов и каширование загрузки. Дальше. Так, ну а чуть-чуть опять же про декоративное управление. Для того, чтобы у нас система знала, где как ей работать. Ну, и опять же сейчас увидите, почему мы не можем это всё, как сказать, в два кликанировать. А у нас внутри а библиотеки а находятся настройки, да, привязывающийся к нашему окружению. То есть, соответственно, нам нужно, а, указать, какая версияски, да, где находится, а, пути к базам, да, где это необходимо, если база файловая. А дальше настройки оповещения. То есть всё это, да, требует до настройки тест. jonв, да, то есть файлов, а для того, чтобы наш конвейер заработал корректно.

Так, и сейчас давайте, чтобы Так. Так, экран нормально видно, коллеги? Э, сейчас, а, раздвоился, да? Сейчас, секундочку. Во, сейчас должен быть нормально. Так, всё, спасибо. Сейчасчку. Так, сейчас мы с вами так, ну, давайте немножечко по конвейерам пройдусь. Так, первое, один из самых старейших вариантов конвейера. Ну, его, конечно, кое-что тут модифицируют, а, но для из него можно интересные какие-то скрипты взять, что-то ещё. То есть это сколько он получается первая версия шесть, то есть какие-то файлики 11 лет даже назад созданы были. Это Vanessa Bootstraп, которую коллеги уже несколько раз переделали, да, соответственно, это основа, которая у нас легла в дальнейшее в библиотеке, которую мы будем сегодня использовать, а именносу Ушер.

Так, давайте немножечко по анесе. То есть здесь у нас, как видите, сразу охватывается и Windows история, да, построение конфигурации хранилища, и Linux история, да, то есть вот 2 года назад в коллеги добавили скрипты, а, соответственно, скрипты для запуска всяких разных э команд. А, и в том числе запуск- это вот даже открыть внутри, то есть вот запускнера. А над всем этим настраивается у нас Дженс, для которого папочка, да, Vipe есть, но аessa Bootstrap, да, она такая универсальная, иногда избыточная, а, но зато даёт пример, как сказать, правильной структуры каталогов. И мы можем, соответственно, их клонировать для себя. А кто-то хранит в документах. А сейчас, Антон, Vanнесса Bootstrap, то есть вот это вот Bootstraп - это как шаблон разработки. А Vanessa Behavior, то есть илиessa Automation - это непосредственно сам продукт. А на гитхабе, да, то есть вот всё, что от авторовнессы, да, соответственно, это их пример, как правильно разрабатывать продукт. Вот, да, то есть вот, собственно, их сам, да, вот add, которая легла в основу Automation, Vanessa Runner, да, это то, что для запуска, соответственно, базовых операций разработчиков всё это у нас дальше поглотилось и развилось в других продуктах. Поэтому вот э разработчик, как сказать, чтобы дань, во-первых, исходному разработчику, да, во-вторых, соответственно, ссылаться, чтобы использовали его. То есть это автора, а сейчас вот вот этой нахрен перейти. То есть это всё было создано легами, да, контрибьюторов достаточно много. То есть и всей этой команде, как сказать, такое отдаётся честь, а что всё это называется. А даже а мы, э- модифицируя вот в рамках уже курса библиотеку, да, сокращая её и адаптируя нас, а-а, тоже Ланесса, дальше - это исходные авторы. Ушер - это следующий разработчик, который тоже сделал свою библиотечку. и мод. Ну, модификация, соответственно, модифицированная уже библиотека, да, сокращённая, адаптированная под конвейер. Ну, и, собственно, вот наша библиотека, которую мы сейчас будем с вами использовать, библиотеку автоматизации сборочного цикла. И а здесь мы как раз оставляем те современные утилитки, которые на сегодняшний день нам нужны, а исключая, да, лишние, как видите, там здесь вот нет ни цмтшников, ни прочего, потому что, а, если первый вариант Бустреп подразумевал, что мы оркестрацию, ну, то есть управление всем делаем через Chrome, да, через какие-то вот библиотечки, а, тошер её цель, а, это подключить чить к Дженкинсу, да, всё. И организовать сам контур последовательных шагов, а именно подготовка окружения, собственно, инициализация хранилища, да, из готового. Дальше прогон синтаксический платформы 1С, если сваливается, то уведомление, что всё-таки синтаксис базовый развален, смысла нет передавать дальше. Следующее - это вызов станализа проекта SARUB. Ну, и, а, последовательно, а, прогон дымовых тестов, модульных, сценарных тестов, публикация отчётов Люр, а, использование современного ЯIT, то есть для результатов модульных тестов. Ну, и сборка поставки конфигурации, да, то есть по результатам всего у нас будет размещённая цевка, которая прошло вот это всё тестирование. И мы можем брать, понимая, что вот эти все шаги у нас прошли.

А так хороший вопрос от Алексея. Почему это библиотека Анни Дженкин SLП? Сейчас А мы у нас и на слайдах будет это Jenkin Slap. А у нас здесь внутри находится сейчас мы презентацию переключусь. То есть как раз будет про Jenkin Swap. То есть Jenkin элементы Jenkin Swap используются так. У нас здесь плагины, которые задействуются и сейчас, то есть необходимые нам А всёвсёвсё, Алексей, да, это вариант, который я говорил сейчас. А почему это? Почему не вот это? Ну, и вот про эту библиотеку. Это самая как бы навороченная большая библиотека. А мы сейчас про скорость, скорость запуска. То есть цель а нашей как бы вот этой библиотечки - это быстрая адаптация, прогон, а сборка, прохождения тестов. А библиотека от первого бита марксистская, то, что я вот упоминал, это, ну, достато самая, наверное, крупная наворочная библиотека, а вот которая есть на сегодня. А в том числе и к себе мы какие-то элементы из Jenkin Swap берём, но конвейер, который она использует, да, сам, он достаточно непростой. А для того, чтобы его стартовать, ну, тут вот, видите, даже сама инструкция, а вариантов гораздо больше. То есть здесь она и трансформации делать, и конфигурирование, и результаты сборки разные помещать. э запуск самой библиотеки, то есть и первоначальная настройка, она немножечко посложнее, но результат, да, у нас вот прямо огромный пайплайн, да, со срокой конфигурацией, с онаркубом, то есть, ну, нем скажем так, если рассматривать, сначала адаптируемся, учимся вот эту всю запускать простенькую библиотеку, а если хочется уже по-взрослому, да, большие-большие делать, то мы можем перейти и адаптировать себя Дженкинс просто вот с ходу, а если не имели опыта с работы с такими библиотеками, то есть и с Дженкинсом настроить Дженкинс, будет посложнее. Поэтому, как сказать, Алексей, то есть мы с коллегами, э, с первого бита тоже общаемся, собственно, какие-то моменты тоже есть, а они развиваются активно. Мы берём элементы для быстрого старта, то есть наша задача, да, какие-то вот взять элементы. А у них это всё, то есть это максимально, да, со всеми наворотами. И вот если же брать по релизам, тут 162, то сколько уже очень большое количество и выпуски релизов достаточно частые, тость её развивают. Так что это, как сказать, следующий уровень. Для тех, кто хочет, можно сразу, да, на эту библиотеку переходить.

Так. Сейчас вижу вопрос, да, немножко к нему вернусь. Давайте сейчас опять перехож на презента. А, теперь, а, собственно, что мы, почему мы про библиотеку начали? А, сама по себе библиотека, она, во-первых, хранится в может быть в другом репозитории, да, Тхабе. Нам нужно эту библиотеку взять себе и на основании этой библиотеки а начать собирать саму конфигурацию. Поехали. Мы берём стандартный код, копируем конфигурацию. Дальше переключаемся на нашу тестовую детал. А, создать новая миграция GitHub. А, клонирование по URL. А, так и название. А, ну давайте пусть будет перенос репозитория. Нажимаем и с гитхаба в нашу систему переезжает структура вот этого репозитория. Переехала. Так, сейчас. Так, так, так. Ага. Стоп. Вот. То есть это руководителя курса, да, библиотеки открытые, а в том числе, да, здесь и разные другие есть интересные штуки, которые могут нам понадобиться. А это, да, это форк. Э можно провалиться. То есть мы, говорю, что мы её адаптировать для себя. То есть форк просто снес ушли. Дадада. То есть ээ серебряная пуля её сделала и, соответственно, вот из разных кусочков собрали свою биолетечку. Всё верно, Алексей. Поэтому и ушер сохраняется. Так просто сама по себе серебряная пуля, она как-то потерялась в истории, да? ушли. То есть инженерные практики, сами по себе они без прикладного применения не такие конкурентно, да, оказались. И вот в рамках как раз отвечая на вопрос, где там самые лучшие инженерные практики. А инженерность 1С, ну, Эмин, да, сама 1С. А если же брать про, как сказать, именно команды, да, которые как-то стараются инженерные практики развивать, ну, с ходу, да, ну, кроме 1С это первый бит марксистка, да, вот развивает у себя что-то. Дальше это развивает ураруса, да? И сейчас ещё наши коллеги, секундочку. Так сейчас как которые стараются поддерживать. Так, тактак. Что не так много компаний, которые как-то стараются быть лидерами и идти вперёд. Так, ну так у Раруса контрибция, да, наружи очень слабая. Собственно, они внутри у себя выставляют, но а-а какие-то аэ обмены, да, то есть с коллегами у них в меньшей степени выдаются. Так, секундочку. Так, ладно, здесь не буду сильно отвлекаться. Чуть попозже, да, ещё вот компания, может быть. А это биотех, а это именно если брать ээ контрибуцию open source. Дада. Вот Антон говорит, что пуля слилась с первым битом, людей разбежались, ээ, библиотеки делали, да, что-то вот IBS, да, собирала крупные франчайзи, да, свои делают. А биотех из таких контрибьюторов, которые в openourстве много чего выставляют. Так что вот из таких крупных компаний, ну, вот из крупных франчей, я бы только трое на троих назвал, в которых заметно влияние на нас с вами и, собственно, оказывают помощь всему сообществу. То есть, ну, исторически стали, так сказать, ээ приносят пользу не только себе, но и, а, всем коллегам по цеху.

Так, сейчас, секунду. Так. Так. И продолжим. Так. А мы склонировали. Теперь это у нас на своей системе есть. Теперь забираем библиотеку себе. А с помощью, ну, давайте для разнообразия VS-код мы делаем клонирование. Так, а идём клонирование репозитория GIT. Тоже также указываем наш с вами нашу ссылочку. Выбираем есть назначения нашу папку. А, и мы хотим открыть новом окне. А вот Да, Bioteотеchnolog, да, они, а, у них очень много инструментов в Так, и вот ссылочка на их Telegram-канал Биотех. А не так мало, кстати, 607 всего лишь подписчиков, хотя очень много файликов, обсуждений. И те уделители, которые они выпускают, это unit promit 41S, это всё вот как раз позволяет, а, то есть вносит достаточно полезные вещи на наших с вами. Так, открыли. Вот библиотечка склонировалась. Каким образом мы её начнём использовать? Ну, давайте я пошату покажу. А, то есть первый старт, ну, опять же может быть либо через конвейер, а, либо путём выгрузки в папочку src, да, на структуру нашей конфигурации. Ну, тем самым мы м такрц выбор выгрузить. Склонировали. Теперь мы уже, а, переключаемся на VS-код, как второй вариант инструмент. Идём сюда. А здесь у нас предлагается выполнить фиксацию сообщения. Точно также мы здесь пишем инициализация. Нажимаем а фиксация и отправка. И тем самым мы инициализировали конфигурацию, да, и можем начать разработку. Так, сделаем. Идём дальше.

Теперь у нас есть конфигурация, да, у нас есть склонирный репозиторите. Нужно, собственно, сами скрипты проверить по настройкам Джейсона, да, и прежде чем всё это начинать подключать в непосредственно а к библиотекам Дженкинса. Так, давайте сначала пробежимся по основным файликам нашей библиотеки. Так, Tшеer. А, и давайте пройдём. Так, что у нас здесь есть из файликов сходу? Так, гит атрибуты. А здесь батнички-то этот так игнор, а то, что не помещать, соответственно, это всякие служебные файлики от VSC, а это папку build исключить, да, ну, и технические, да, папочки, когда мы работаем с ВС-кодом, соответственно, чтобы система их не размещала, так у разработчиков иначе будут конфликты при работе с помощью кода, да, с данным репозиторием локальным. А дальше а здесь new, то есть специфической, когда привязки здесь не имеет, это уже библиотечный файлик, да, вызывающий, собственно, нашу так дальше. Тут уже, собственно, наш Pipeline. А что нам здесь может потребоваться? А тут элементы до настройки самого Дженкинса. Именно аа с какой меткой у нас сам Дженкинс устанавливается, да? А сейчас про него тоже чуть-чуть расскажу. и настройки, соответственно, Явы, да, под наш, а, конвейер. Так, здесь мы пока вернёмся к настройкам, потому что нано посмотреть метки. Так, дальше эту библиотечку мы не трогаем. Это тоже отвечает за самсборку. Так, э вот, собственно, следы и первоначального контрибьютора, да? То есть это ссылочка на а библиотеки, разработанные серебряные пули и как импортируемые в нашу систему. А какие репозитории, да, у нас будут использоваться? Вот, собственно, корневое имя нашего проекта. Здесь давайте мы уже начнём менять. А что это у нас? Тест. А, ну пусть будет, ну, пусть будет Е. Так, SSL, же мы использовали тест SSL. Так. Ну, и дальше это непосредственно наши, а библиотечки инструментальные. Так, окей.

А теперь прокинс немножечко, да? То есть у нас есть всё. Теперь нам нужно определить, как этот конвейер нам запуститься, как настроить базовый Jenkins. А здесь он у меня уже установлен. Ну, давайте чуть-чуть, буквально мы пройдёмся. Так, зашли. Первое, что нужно сделать - это выполнить подключение. библиотеки, а, и добавить её в самом Джинкинсе. Идём в администрирование. Так, идём. Так, сейчас, секунду. Так, здесь всё нормально. Так, и здесь у нас, а, идёт описание настроек Дженкинса. Опять же, как Дженс настраивается под сборку, тоже есть много информации, что вот обычно включается в тестовый конвейер, кроме а вот этой библиотеки, а, да, непосредственно репозитория, а, Sonar CUB, там, где к этому готовы. А, но опять же, если, э, инфраструктура не позволяет, да, то есть можем ограничиться вариантом АПК от 1С, но он не такой быстрый, да, как, соответственно, Sonarп с его техническим дотестированием, он гораздо быстрее работает, чем а наш с вами JKS, ой, чем аа АПК. Так, ну, и вот наша библиотечка, да, настройка Global Trusted Pipeline Libraries. И нам сейчас сюда нужно подключить. А так, Jenkin SL у нас подключено. И сейчас посмотрим. И мы сейчас подключим библиотеку User. Так, секунду. Она у меня уже подключена. А сейчас проверим. А, да. А, собственно, вот она у меня уже импортирована. То есть библиотеку указываем. То есть мы описываем, что в этой библиотеке находятся наши методы. То есть версия по умолчанию, то есть мы ссылаемся на исходной версии самой библиотечки, располагается

Она в репозитории, да, если всё это оставляем по умолчанию. А настройки, ну, опять же, здесь базовые настройки, которые указываются при создании. Что, а, при появлении методов, отсылающихся, да, на библиотеку User, она обращается с помощью современного способа Mod кту, находящимся на гитхабе, да. Здесь мы можем, соответственно, уже поменять путь на свой локальный. Так. Так. А здесь мы ничего не делали. И сохранить. Так, всё, Jenkins мы подключили. Библиотеку здесь подключили. А, вернёмся назад. Так, к презентации. Так, а настройки проверили. Так.

И теперь пройдёмся по элементам конвейера. А в больших конвейерах непрерывной интеграции CI/CD, а обычно включается вот несколько шагов. Опять же, последовательность может быть разной, а, но такая вот выбранная, да, последовательность старта каждого шага, она позволяет нам, а-э, во-первых, если что, если каждый предыдущий шаг критичен для последующего, нет смысла забывать запускать дымовые тесты, да, если там, а, идёт рост технического долга и, собственно, его должны исправить раньше, чем, а, а интерфейсной формы. Но а этапность может быть любой. То есть у нас, как говорится, могут коллеги договориться, что вот эти два этапа они всегда последовательные, а SonarQube, дымовые тесты и вот эти все виды тестов запускать одновременно, да, в параллельных ветках. И по результатам прохождения всех этих шагов должна сформироваться сборка и формироваться файл итоговой поставки. А здесь уже зависит от архитектора, от ресурсов, э, особенно на этапе дымового тестирования. Здесь прямо вот точно многопоточная, потому что я думаю, из кто из вас запускал дымовые тесты, видел, а насколько они тяжёлые могут быть. А, ну и, соответственно, здесь могут быть у вас вопросы. А первый этап — это инициализация окружения, подготовка базы. А что здесь у нас должно выполняться? У нас исходный код, а, который до этого Jenkins, собственно, забрал, сформировал, да, в Git. Jenkins запускает конфигуратор в пакетном режиме и формирует чистую базу данных для того, чтобы исключать артефакты прошлых релизов. То есть у нас идёт инициализация самого окружения, прежде чем а запускать повторно. А так дальше. А прежде чем а делать все остальные шаги с тестированием, а нам нужно пройти, собственно, два пройти врата качества, да. Первый критичный, а, прогон синтаксического контроля средствами самой 1С, а, выявление, да, ошибок, вызовов, и конвейер прерывается в этом случае, а, и дальше не продолжается. А SonarQube зависит от настроек. Ээ, если у нас, э, не увеличилась сложность, да, соответственно, технический долг у нас не вырос или там рост не настолько критичен, а, то SonarQube пропускает дальше, если не критично, но при этом, да, уведомляет, что, коллеги, а мы движемся куда-то не туда, да, у нас растут сложности, всё-таки проведите внутреннюю работу. Вот. собой, да, чтобы нам перейти дальше.

Так, сменим экран. Так, сейчас секундочку. Как это всё выглядит в Jenkins при подключении конвейера? А, ну, само подключение конвейера в Jenkins — сюда тоже как бы целый отдельный цикл, да, как его настроить. Сейчас покажу по первым шагам и результат. А при входе в Jenkins, да, соответственно, здесь было пустое окошечко, да, с сборочными линиями, то есть всеми вариациями, которые сформировались. Мы начинаем с создания данной линии. У нас pipeline, который, соответственно, имеет ссылочку, да, на ранее описанную. А здесь мы сдаём его имя сборочной линии. Окей. Так. И дальше мы указываем в настройках, э, откуда мы забираем библиотеку. Pipeline script from library, из GitHub. А указывается откуда, а и указывается репозиторий с нашего pipeline. Указываем его. Так. А дальше вот уже идут нюансы, а ветки, которые будут строиться. Ветка master. Здесь пока мы не трогаем ничего. Script Jenkinsfile. Это тот скрипт, который будет выполняться при старте конвейера. Нажимаем такчку сохранить. И, собственно, первоначальные настройки, но мы не сделали ни настройки базы, ни какие-то дополнительных. То есть мы сейчас пока вот, то есть все эти настройки вносятся, да? Да-да. Алексей, там несколько есть моментов. Давайте вернёмся назад. А, хорошо бы, да, вот это поставить, не делать конкурентные. Хорошо бы вот это поставить, если запустился, да, в прошлой было зависшее, его прервать. А дальше вот это ставить, удалять устаревшие сборки, а, соответственно, больше там семи дней, да, сборка нам не нужна. Хранить сборок, а, если идёт больше, там не больше трёх. А следующее как раз вот в настройках полного пайплайна — параметризированная сборка. И здесь указываются те параметры, которые мы передаём на вход скрипта. Указывается путь к базе. Мы сейчас посмотрим в готовой сборке. Указывается, ну, то есть строковый параметр пути к базе, credentials parameter — логины, пароли, если они есть при авторизации. А, ну, булевое, понятно, да, значение. Соответственно, сейчас это всё в готовой сборке. Мы пройдёмся, посмотрим, какие параметры бывают, так как их мы все передаём для того, чтобы у нас сборка выполнялась. Так, вернёмся назад. Так.

А, ну, и давайте вот какую-то из готовых сборок, которая ранее выполнялась. Так, сейчас вот у нас так это а всё немножко сборки другого типа. А это вот мультибранч сборки с множественными ветками, а необходимы, когда у нас несколько разработчиков над проектом, то есть, ну, на реальный случай. А если вот такие сборки, это одноветочные сборки для случаев, если мы прикручиваемся к, а, хранилищу и в Git у нас кроме одного служебного пользователя, от который, ну, кроме GitSync'а никто не будет ходить, то есть вот этих вот мультиветок у нас не будет, соответственно, необходимости отслеживать несколько веток и их состояния нет, а можно всё завернуть в обычную ветку, то есть в один pipeline. Ну, и давайте посмотрим структуру сначала обычную. Так, это какой-то чный сейчас. Ну, давайте посмотрим на нём. А что вот результаты инициализации репозитория и посмотрим, какие у нас здесь настройки ещё дополнительно были указаны. А в параметрах указывается, да, имя базы данных, которая будет запускаться. В параметрах указывается также имя сервера 1С. Э при авторизации а служебный пользователь, да, это тут на всё в скрипте прописывается. Так, здесь соответственно путь. Ну, давайте, чтобы он не сбивался. То есть проверяется наличие существования репозиториев, тон подключиться, если что, про них уведомляет. А так дальше, дальше. Ну, и здесь путь был немножко другой, соответственно. И давайте вернёмся назад, сейчас какую-нибудь, а простенькую сборку с вами запустим. Так, сейчас сборку. Вот. сборка, да, уже с большим количеством вариантов. То есть, собственно, а после того, когда мы вот в настройках сейчас здесь как раз больше будет больше параметров, то есть вот здесь и удаление устаревших сборок было, да? Ну, давайте вот эти настройки, которые предложили, тоже сразу же сделать. Поставим. Удаление устаревших по умолчанию ставится. Так, имя от базы — это всё есть. Так, репозиторий, да, я удалют вариант, что это тот репозиторий, в котором у нас сохранятся исходные файлики src. А далее так, всё о'кей. И теперь так сам конвейер, когда стартует, а мы нажимаем собрать с параметрами. То есть это процесс небыстрый, если прогон всего этого выполняется. Ну, вот сейчас, если запустить, то так как э репозиторий, да, уже перемещён, то он его не соберёт. Но в котором репозитории, который могли поменять, а по всем шагам у нас пройдёт. И, соответственно, что будет делаться? А будет, э, проверка, что репозиторий жив. А дальше checkout Git, соответственно, с гита забирает файлики, которые до этого туда улетели. собирает CF-файлик, обновляет базу данных тем CF'ами, которые собрались, запускает сценарные тесты, которые у нас были сформированы, и, а, формирует итоговый отчёт по результатам прохождения, а, наших сценарных тестов. Собственно, скриптик дали, дали настройки, сформировали хранилище, дальше настроили расписание запуска, э, запустили и периодически можем ходить на вот эту страничку отчёта Allure, а, который нам выдаёт на каких фичах, да, то есть у нас упала конфигурация. Для тех из вас, кто формировал Allure отчёты из Ванессы, да, это всё знакомо. Преимущество, да, что вот эту страничку мы публиковали, да, и вплоть до того, что эта страничка, да, может улетать в какой-нибудь там мессенджер, Telegram или если кто-то использует наши мессенджеры, то, соответственно, и может от них всё это дело уходить, а фиксируется, да, кто там запускался. Ну, и тренды, да, с результатам прошлых запуска.

Так, давайте сейчас, а что нам необходимо для того, чтобы это всё у нас взлетело? То есть вот этот кусочек у нас отвечает уже за этап сборки и прогона для окружения. Вернёмся, пробежимся дальше по презентации. То всё-таки за время, да, у нас не так облегчилось результаты, да, но что-то у нас есть. Так, по фильтрации дефектов, а то, что вот мы проговаривали, да, на синтаксическом контроле рвёмся сразу и не движемся дальше. На SonarQube проверяем, дальше разрешаем двигаться. А динамическое тестирование проходим, да? Опять же, если мы делаем вот самый быстрый запуск дымы в автомате Jenkins'ом с генерации до отчёта Allure, это прямо вот очень быстро всё собирается, оно крутится, вертится и выдаёт нам отчётики ежедневно, да, соответственно, даёт нам возможность спать спокойно. Ну, здесь всё понятно. Эти сценарии с помощью искусственного интеллекта сейчас дописать гораздо легче. Ну, как видите, а может быть, даже что-то вот здесь вот и кто-то уже с агентами строил для себя на линии, что при получении ошибок там система себя переписывает. А что позволяет аа конвейер, да? А-а, у нас идёт различное помещение кода хранилище. Конвейер, да, анализируя коммиты и, соответственно, собирая их, позволяет из них вот эти сделать виртуальные ветки и проанализировать и помочь нам собрать итоговую сборку, да, и если будет что-то не так, то в случае использования вот такого комбинированного варианта, то изменение, произошедшее вот в этом помещении, а, вот может откатить и изолировать, то есть немножко заблокировать, но это уже меньше подаётся автоматизации, то есть это нужно уже участие ваше в разборе конфликтов на уровне а репозитория. А автоматическое ветвление в Git, то, что вот как раз я описывал, да, идёт анализ, а парсинг истории Git по результатам, а помещения в хранилище с помощью регулярных выражений. Тоже также скрипты добавляются. И у нас вот создаются, да, все водоветочки, который разработчик не руками создавал, да, делали задачки, а по результатам комментариев. А, соответственно, а задачки, у которых комментариев не было, то есть и те, а, помещения в хранилище, которые коллеги делали, минуя это, а, соответственно, уходят в карантин, да? А что это такое было? Что позволяет сделать? То есть, по сути, э, мы собираем альтернативное хранилище, да, альтернативную CFку с очищенными, а, от, ээ, некомментированных изменений разработчиков изменениями. Тем самым у нас другая конфигурация собирается. То есть 1С CD имеет такую вот плоскую, да, хранилище с кучей, в том числе и, может, даже несанкционированных изменений, которые не прошли тестирование. Они исключаются путём вот этой виртуализации с веточками. А мы, соответственно, создаём новую CFку, да, и можем, соответственно, быть спокойными, что, а, вот её мы уже можем отправлять на припро на тестирование.

Так, перед тем, как, так, перейти к экономике и ещё к результатам, сейчас немножечко про курс. А что это один из элементов до открытого урока. У нас здесь несколько прямо тем. пробовал сложить и в одну поместить, довести до результата, да. Но вот, как вы можете отметить, да, чтобы всё это собрать, а, нужно несколько, да, подряд, а, быстро делается, когда мы готовы к этому. Ну, и опять же, э, цель всего нашего курса, чтобы вы самостоятельно, да, могли всё это разворачивать и на проектной работе готовиться. Курс достроим, исходя из трека, что в результате у вас в отделе, если мы отвечаем, да, должна заработать, а, во-первых, сборочная линия, во-вторых, применяться практики GitFlow, а, использоваться элементы проектирования, в том числе и с элементами построения библиотек, где-то искусственный интеллект, где его допустимо применять, как допустимо применять, а, с контролем производительности, современной интеграции. Опять же акцент у нас на аа 1С Jenkins и то есть, собственно, те платформы, которые сейчас встраиваются во все современные платформы. Ну, и вот на CI/CD, да, там один только Jenkins, по-моему, сейчас уже, наверное, три занятия достаточно немало. Так, ну, нас контрибьютор, в том числе многих из проектов, технический архитектор Олег Никита Иванченко, может, фамилия знакома, это автор 1Script и непосредственно ведёт авторские занятия по своему 1Script в рамках нашего курса. Ну, и мы как бы свои элементы курсов идём, да, каждый по своей, то есть можно прочитать. Обучение в живом формате, соответственно, с реальными ответами на вопросы, которые возникают у вас, с фидбеком по домашних задания. И мы каждый запуск адаптируем к тем изменениям, которые прошли там за аа последние там полгода и зачастую даже в рамках одного курса, да, следующие занятия могут быть адаптированы, если что-то вдруг пошло там на рынке по-новому, да, какие-то изменения, что-то вышло новое или там прорыв в искусственном интеллекте, и там нужно нам будет там завтра а всем э срочно встраивать и агенты во все наши сборочные линии. М. Значит, будем адаптироваться и использовать. А ближайший запуск в конце июня, длительность 4 месяца, да, кода можно перейти. А карта курса для того, чтобы рассмотреть, какой блок, например, мы сейчас смотрим. Мы сейчас как раз вот элементы автоматизации работы разработчика, контроля качества кода, элементы, которые линии взяли и, а, построение интеграции. Так вот, Антон задал вопрос. Опыта есть коммерческий опыт в бэке 4 года. Опыт EDT есть, да? На EDT тоже делается акцент, да? То есть по нему ведёт. Вот, собственно, сейчас сд секундочку. программе, да, в полной программе, да, у нас сейчасдут ответить. EDT даётся, потому что, ну, во-первых, то, что вот мы сейчас с вами смотрели на хранилище, да, в EDT, а гораздо легче, да, и вот этот этап, связанный с GitSync'ом, он пропускается, и нам нужно только отработать, собственно, второй кусочек, связанный с конвейером автотестов, сборки и так далее. А на входе у нас уже есть EDT. И даже к EDT мы уже же подключаем и синтаксический контроль, и SonarQube элементы. То есть, в принципе, знакомить в хранилище, ой, в в этот в Git-репозиторий а из EDT, если у нас не прошли вот эти вот контрольные процедуры, будет категорически нельзя. Да, то есть, ну, при условии таких вот контролей, я думаю, может быть, кто-то даже из вас сталкивался. Так, и первый вопрос опыта для прохождения курса. Смотрите, а у нас а специфика? То есть аа чистого 1С, наверное, здесь есть элементы, да, но не так много. То есть требуется понимание, да, то есть как 1С'овские-то элементы требуются, но, наверное, там глубокая разработка, да, там глубокий разработчик, это не является самым критическим для нас. А так как цель это расширить пул, зачастую вот многие 1Сники, я думаю, даже сталкивались с этим, они имеют, ну, даже если даже работают с EDT, а остальное окружение не знают и не могут поставить задачи. То есть наша цель не просто там научить самостоятельно руками, да, DevOps'ерскую работу выполнять, но и научить ставить задачки другим коллегам, научить что-то распределять. Ну, а когда нет никого, чтобы могли бы взять, сесть, как вот у меня руководитель архитектор, да, наш в роли архитектора сейчас выступает. И по сути вот это всё окружение, начиная аа с базы, с хранилища на Linux с подключением Apache и заканчивая, да, вот этими элементами, связанными с окружением, доводит, да, вот Татьяна же, тоннельное зрение, да, э-э, так как даже вот эти какие-то базовые элементы в 1С ээ понимание, что, а, например, какую-то операцию можно и нужно, да, уже делать не только копаясь в синтаксисе 1С, а имея расширение, да, даже как решать задачки, а что-то можно решить с использованием искусственного интеллекта. Это можно адаптировать, встроить, да, в процесс. Даже вплоть до того, что вот в том конвейере, который мы сейчас сделали, а при использовании API система может сама ходить с вопросами на тот же, какой-нибудь инструмент. Ээ для начала можно бесплатным GigaChat'ом, да, воспользоваться. А будет проблема, да, Эмиль, проблема будет мастера, но как сказать, нравится ли такая тенденция? Скорее всего, не очень, потому что специализации не будет. А приходится быть, чтобы следовать трендам. То есть то, что раньше нам выдавалось, а, как сказать, делилось на специалист, сейчас мы заменяем на ИИ-агентов, а, на вот такие вот инструменты типа конвейера, да, базового. А вот его настройку, какие-то генерации скриптов к нему мы уже, да, используем, собственно, для тех же там корректировок. Используем элементы искусственного интеллекта, понимая, что в результате получается. То есть тот же вот 1Script создаём, да, с помощью искусственного интеллекта, а фичер файлики генерируем с помощью искусственного интеллекта. То есть это, ну, да, вот Татьяна мастерами быть, контролями мастеров, ну, в какой-то мере быть экспертами своей области, а и понимать, что вот эти вот мастера, да, там админы какие-то DevOps'еры нам лапшу на уши не повешают, а смогут мы сможем с ними там говорить на равных и требовать и вот это поставки, вот это, вот этот, вот этот момент, э, и не бояться, собственно, говоря, тех результатов, которые получится. Даже вот а взять про кругозор, а если взять специалиста на обычном, то есть вот, например, у нас мониторинг, контроль производительности, а есть три инструмента, да, которые можно делать мониторинг производительности. Это 1СУ Центр управления производительности — медленный, не шустрый. Визуализировать на телевизорике, э, никак, да? То есть, если вам скажут: "Мы хотим вот здесь вот на телевизоре в помещении видеть, как у вас крутится". А-э, два других инструмента есть. Ну, Zabbix в рамках курса мы его не рассматриваем, он как бы отдельно немножко для админов идёт. А мы же берём Grafana, более универсальный инструмент и просто показываем, как эту Grafana всю завести и выдавать из 1С метрики на дашборд. И причём это очень быстро всё делается и достаточно положите. И как раз вот амин, я просто больше этим самым мастером отрабатываю, когда кто-то выполняет апдекс, а, ну вот Александр Торас. Апдексы, да, те же самые апдексы. Смотреть в 1С грустно, скучно. Мы апдексы через Grafana выкидываем и показываем их на дашбордах. Да, и выглядят они гораздо красивше, чем типовые. Есть конфигурации, да, готовые. Угу. А вот Эмин говорит, 1С монитор поставили. Комфортно, да? Ну, вот есть, да, конфигурации, которые адаптированы. Так, ну немножечко пройтись, да? То есть ээ что ещё скриптами дописывается? Но вот это всё, конечно же, требует ээ подключения. помощников каких-нибудь, которые вы кто дочитаете для того, чтобы скрипты создать и сформировать ветки. Ну, опять же, библиотеки готовые есть в той же, по-моему, Marxistko, да, есть, по-моему, такие скрипты, которые формируют, а, ветку в автоматическом режиме, исходя из того коммита, сообщения, которое разработчики оставляли. То есть вот здесь вот надо договариваться о синтаксисе, то есть как писать сообщение, чтобы у нас потом там решётка, да, там таск какой-то, чтобы потом вот из этого единообразия у нас там формировались ветки. Соответственно, если а несколько а помещений делается под одну и ту же задачку, да, то вот эта ветка а автоматом, а собирается и все изменения под эту ветку скрипт формирует. А если же там ветка не найдена, да, или там помещение сделалось без указания ссылочки на IDшник запроса, то ручной аудит. Вот такой вот вариантик применяется. Изоляция, это то, что как раз в EDT уже автоматом проходит. А-а при конфликтах форм, соответственно, изменения разработчика. Но вот вот здесь вот момент с формами. Э, да, их как-то можно объединять. Ну, вот здесь вопрос спорный. А мы, э, как смотря для чего делается изменения по формам, а, чтобы они не конфликтовали, должны быть программными. Но это неудобно. И в случае, если мы ведём, ведём, например, свою собственную какую-нибудь продуктовую разработку, ушли от типовой конфигурации, нам, ну, как бы может быть не так критично, но тем не менее, да, это всё можно использовать. Так, сохранение консистентности ветки — это те файлики, которые у нас не собираются. А, ну, и, ээ, безопасное тестирование логики, а также может скриптом выполняться прогоном локальным, то есть перед тем, как в удалённый репозиторий всё это уходило. А, соответственно, даже вызов вот этого помещения в ветку, которое вот мы сейчас сделали из EDT или код просто кнопочкой, должно делаться через, а, предварительные проверки и одобрения от синтакс-контроля и от там SonarQube, да, если это в идеале делается. Вот так. Ну, здесь опять же элемент автоматизации, который можем применять, какие-то делать приоритизации. А скрипт может, собирая вот этот вот копии, по сути, нашего хранилища, может удалять проблемные, а, файлики, да, то есть типа там не озвучены, да. Единственное, что а у нас в результате, да, может что-то вот рассыпаться, но тут вот нюансики есть. То есть коллеги могут что-то там так переломать и это всё будет или починить, э, и не прокомментировать этот помещение в хранилище, что в результате у нас не соберётся конфигурация, да, опять же вот решается тем, что аа идёт прогон и перед тем, как всё у нас сформируется, должно пройти комплексное тестирование, что у нас сам репозиторий не сломался. А на финише, собственно, у нас проходит выгрузка и формирование финального файла конфигурации репозитория, да, который всеми тестами прошёл. И он у нас помещается в локально папочку. Сейчас покажу. А так билд может просто он это А сейчас в этих в папочках не покажу, потому что сам билд секунду. Он в этих в Jenkins'ах есть. Так, секунду. Да, сейчас. То есть формируется CF-файлик во временно вот этой папочке от Jenkins'а, да, когда вот он работает. И этот файлик, он уже перекладывает ещё в одну папочку, да, соответственно, чтобы можно было из неё, а, ну, либо он автоматом может накатить изменения в какую-нибудь этот тестовую, а, конфигурацию, а, либо же, э, выложить CFку, а дальше уже из этой CFки забираются изменения. Ну, это в зависимости от того, как переходят изменения. В идеале, конечно же, всё должно быть веточками и конфигурация, а, для тестирования и какой-нибудь пред-прода. Всё это уже берётся только из Git-хранилища. Никакого отношения к этому иметь не должно. А который вариант консервативный, который решается на хранилище, это то, что а конфигурации вот эти вот уже к хранилищу не привязаны, да, либо ведутся к своим собственным хранилищам, что очень неудобно. медленно, ну, и очень грустно. Поэтому в идеале конфигурации ээ тестирования, то есть контртестирование, контр предпрода используют Git. А вот в продакшн, да, там уже CFка, которая красивенькая, из предпрода выгруженная, помещается и обновляется там отдельными задачами, отдельной линией, зачастую выходящей уже за зоны нашего контроля. То есть это продакшн, соответственно, там админы, а, либо служба поддержки, если у нас есть такая изоляция, они всё это помещают, копируют и отвечают, собственно, уже за выкатывание в продакшн. Наша задача линии — это выдать собственно результат, который прошёл все тесты сейчас и проблемку сборки закрыл.

Так. По экономике. А, ну, здесь, а, скажем, какой есть минус, да? Нам нужно немножечко поучиться. Э, сейчас это сделать легче, потому что мы в качестве ментора, когда мы вот эту основную базу накопленную контроль прошли, а где-то с помощью до как раз нашего курса, а дальше мы уже понимаем, кому как, какие вопросы задавать, накопили базу, и с помощью этой базы, да, можем уже там с тем же искусственным интеллектом задавать вопросы и ставить мастеров, которые вот Татьяна писала на место. Что у нас быть? То есть здесь длительные ожидания, они уходят до внедрения автоматизации. Здесь у нас метрики, автоконтроль, который изначально проходит и часть ожидания снимает. Соответственно, разработчики не курят, результат получаем быстрее. Ручное ревью, соответственно. Ну, здесь вот нулевое я бы взял в кавычки, потому что без знаний, а стек дорогой, со знаниями, да, и с умением всё это уже с использованием библиотеки покрутить гораздо всё интереснее. А вот этот у нас уходит, так как задачи становятся изолированными. И то, что мы в любой момент без поиска того, кто кем, чем, как убито, система нам подскажет, и мы на репозитории всё это можем отступить и увидеть дальше. Ну, здесь, ээ, соответственно, а что может быть? Э, здесь мы можем сфокусироваться на интеграциях, на каких-то специфике обмена, а рутину, отвечающую, да, вот за какие-либо, да, вот контроли, да, соответственно, всё это мы можем убрать, исключить.

Так, вернёмся назад. Так, сейчас экран. Собственно, что он себя должен представлять собой наш конвейер? Если так вот кратенько подытоживая, а это, ну, базовое хранилище, да, с пользователем, который имеет такую же связку. Имя пользователя у нас связано с его именем в Git. А чтобы потом Git, соответственно, исходя из имён пользователя, да, раскладывал это по правильным именам пользователя, авторизующимся в а-а репозитории, да, чтобы от них от имени этих пользователей формировали ветки, им приходили уведомления. Так, есть. Следующее, а это, соответственно, локально установленный Git. Это инструмент для работы с локальным Git-репозиторием. Это удалённый репозиторий, желательно свой собственный, а, не имеющий ограничений. То есть на GitHub можно получиться на маленьких конфигурациях. Ну, а вся мощь и весь контроль уже висит у себя. Так, немножечко про аа вебхуки. Аа что здесь делается? То есть, ээ, смотрите, а что это делается? То есть в тот момент, а когда у нас выполняется коммит в хранилище на события отправки, а, соответственно, мы указываем адрес обработчика. Это будет у нас входящее, ну, здесь особо не настроено, у Jenkins'а выставляется обработчик, а, соответствующий, э, на то, чтобы ловить наши эти сообщения. То есть мы дёргаем Jenkins, говорим, что что-то у нас тут товарищи закоммитили, чтобы Jenkins сам по себе по расписанию не дёргался, а Jenkins просто в режиме ожидания находится, что он каждый раз не мучает ресурсы. И только когда а в хранилище, в репозитории у нас поместили аа код, а только вызывается из репозитория обработчик старта процесса на Jenkins'е. Jenkins, соответственно, стартует вот ту вот нашу сборочную линию. Так, это которая на определённый этот ключ ловит и выполняет сборку. Собственно, кратенько, если говорить, то вот так. Вот так. Эмин как раз про сборку визуализации всех метрик в одном месте. Так. Ага. А, ну, вот, кстати, да, так. 1С монитор сборка визуализация. Ну, кстати, а, чуть-чуть, да, в сторонку. Э сборы метрик, э, прямо тоже можно. Так, а сейчас здесь отсюда не перейду. Так, у меня Grafana здесь не развёрнута. Ну, по сути, сейчас, сейчас, сейчас, сейчас я спокойно ссылочку одну покажу. То есть, что может Grafana? Так вот, то есть можно точно так же, да, в весь этот конвейер добавить а Grafana. А она, да, про нагрузку серверов, но есть готовые прямо расширения, встраи конфигурации, которые обрабатывают агрегированные значения, то есть цифровые типа табличек с апдексом и так далее, и передают их на сборщик, на Prometheus. И дальше сейчас вот дальше выдают их. Сейчас так 1С, а выдают их на дашборде. о состоянии наших систем. Ну, здесь вот просто, да, какое-то состояние кластера 1С. Ну, точно также можно метриками и визуализаторами выдавать ээ там насколько у нас там с формочками поменялось, какие-то обмены выдавать агрегированные. А что касается техжурнала, это отдельная тема. Его нужно распарсить где-то отдельно проанализировать, ээ, и дальше тоже передать соответственно в Grafana уже агрегированные значения. Ну, да, вот для не 1С Grafana. Ну, тут на выбор аа тут, как сказать, 1SP или там 1С-монитор, когда убирается промежуточный вот этот набор микросервисов, э, да, с ними становится, э, чуть-чуть попроще жить, потому что, чтобы взлетела Grafana, нужно настроить передатчик с метрик в каком-нибудь там Node Exporter, если брать под Linux. Дальше сборщик Prometheus, который агрегирует данные и выдаёт на Grafana и Grafana как визуализатор, то есть три. А, а в случае же ЦУПа у нас есть агент и есть сам ЦУП, который всё это рисует. Так, ёлка, ёлка, ёлка, ёлка. Если честно, я, ну, Elasticsearch для ТЖ как-то применяли коллеги, да, вот для разбора ТЖ. А вот Kibana как-то это я уже не встречал, если честно.

Так, давайте двинемся к выводам. Вот так. Что наша цель? А, собственно, эволюция, которую мы должны пройти, да, и как бы называться город архитекторами, всё-таки заниматься анализом наших интеграций, а, настройкой и быть постановщиком и задач для нормального формирования фабрик сборки, то есть выдавать в эту сторону. Собственно, заниматься и развитием IT-ландшафта, то, что позволяет как раз расширение кругозора. Вот и Эмин хорошую, да, тему говорит в эту сторону смотреть. Это требует отдельно до тематики. То есть да, обучение и на техжурнале прямо интересная тема, но требует тоже своего отдельного подхода. А так что так о вопросом, да? То есть так что у нас про ёлку дамы немножко обсудили. Сейчас, секундочку. Так. То есть бояться здесь нам ничего не надо. А поэтому строить линии можно, нужно, а страшного ничего нет. Таких вот из компонентов библиотечки, а берём, да, используем, да? А как это? К сожалению, а количество компонентов всё ещё остаётся большим, да, условно микросервисы. Они всё ещё остаются микросервисами, чтобы это как-то исключить. Мм, и всё сделать с REST'ами 1С. Не всё можем, да, с REST'ами 1С сделать, да, где-то вот самос, да, приходится там подпинывать, да, и внутри само 1С, да, аналитики, аэ, я имею в виду не один аналитик, а, а какие-то метрики собирать, э, ну, бывает медленновато, в том числе требуются ресурсы, которых не всегда есть. А наличие практики, да, наличие вот этих вот библиотек, разбор в тоже сторону и передачу, да, каких-то результатов, в том числе локальные системы. Это всё-таки будущее. А, и вот то, что Эмин как раз пишет, аа, передачи в какую-то такую аналитическую, там зачистка и так далее результатов работы и, а, выдаче метрик, собственно, уже на основании и куда мы движемся, кто у нас хорошо пишет код, кто плохо. Ну, опять же, смотря как это использовать, ну, не с точки зрения наказания, а вот развития. Может быть, какие-то треки развития будет предлагать, уроки и так далее. То есть, да, моменты есть, роботы, а, учат человека. Так вот, кстати, э следующее занятие у нас 18 июня открытое, где будет посвящено 1С разработку CI/CD, а-а, разработки через спецификации к инфраструктуре MSR. Э, вот то, что Эмин говорит, а, как раз рекомендую подойти и послушать, да, может, какие-то моменты сдать, потому что вот эти элементы будут в наш курс включаться, а, соответственно, посмотрите, что такое SCDD, разработка через спецификации, а, как готовятся собственные MSR сервера, это проксированные конфигурации, адаптированные под работу для ИИ. Вот, собственно, та разработка, которая нам необходима, потому что сейчас мы уже проводим эксперименты, когда нам необходимо прямо через какой-нибудь мессенджер задавать ассистенту 1С какие-то вопросы, задачки какие-то ставить эксперименты. И по сути онто не превращается, да, становится помощником, понимающим базу, снижающим стоимости рутины и в онлайне отвечающим на те вопросы, которые там прямо вот могут на совещаниях возникать. Чик-чик-чик. Можно какие-то вопросы, там, моменты, метрики, а, непосредственно с конфигурации получать. А это, а, и архитектору, аналитику это прямо золотым будет источником данных. И это всё у нас крутится внутри, э, нашей инфраструктуры. Поэтому приходите. А так, прошу результатам, да, запрос заполнить немножко. У нас больше получилось. Ну, вот, а быстро при наличии знаний, но, как говорится, сейчас это не страшно, есть кого спросить, к обратиться, есть где это поэкспериментировать. Вам спасибо за вопросы, тоже за информацию. Так, и приходите, да, на следующий урок. Да, будем делиться опытом. Как раз всё. До свидания, хорошего всем вечера. До следующих встреч. Так.