0: Коллеги, привет. Спасибо, что пришли так рано. Вот, надеюсь, будет интересно. Меня зовут Константин Ожерельев. Я работаю старшим разработчиком 1 с в департаменте рпи учётных систем озон. И 1 из основных направлений моей деятельности, это автомати.
1: Процесса разработки в наших командах наш ci используется более чем в 10 различных конфигурациях. 1 с и поддерживает работу как в классическом конфигураторе, так и в едт. И сегодня я хочу рассказать, как нам удалось сократить время доставки.
2: Наших изменений в продакшн. И как это улучшило на наши наши процессы. Надеюсь, доклад будет интересен тем коллегам, которые присматриваются к автоматизации, так и тем, которые хотят осуществить файн тюнинг своего сиай.
3: Пару слов о себе. Я работаю с платформой уже достаточно давно в озон более 4 лет, и за это время мы прошли путь от полуручных выкаток до полной автоматизации деливери, и я верю, что даже сложные процессы могут
4: Быть быстрыми и удобными.
5: Теперь к содержанию рассмотрим преимущества автоматизации перед ручным диплоем я покажу наш стек инструментов, разберём стратегии оптимизации сиайсиди пайплайнов, покажу узкие места и как их преодолеть, и подведём итог.
6: Итак, почему же команды боятся автоматизации? У нас в компании есть обязательные требования по деплою приложения через пайплайн. Но когда мы этот процесс запускали, у нас был переходный период, когда мы
7: Позволяли командам 1 с. Пользоваться своими старыми автоматизациями или каким-то ручным деплоем, и зачастую команды оттягивали процесс перехода на общий ci, и в чем же была их мотивация 1 это привычка к ручному
8: Деплою несмотря на то, что наш пайплайн обеспечивал развёртывание на несколько баз автотесты, откат, разработчики зачастую говорили, что им руками привычнее, быстрее отсутствует какая-то бюрократия.
9: Да, 2, это они неверно оценивали время. Они не учитывали, что ручной диплой с развёртыванием на бас в различных окружениях. Тесты и проверки на самом деле занимают больше времени. Можно, конечно,
10: Зайти в фигурато в продакшене, что-то подправить без Тестов. Ну тогда есть риск, что вы будете заниматься какой-то другой доставкой.
11: И 3 причина это страх сложности. Любые изменения требуют адаптации. И мы поняли, для того, чтобы убедить команды, нам нужно не только требовать, но и улучшать наши инструменты. И поэтому мы оптимизировали свой ci с тем, что
12: Приблизиться к ручному деплою по скорости и превзойти его по надёжности.
13: На этом слайде пример 1 из наших конфигураций. Время диплоя коррелирует с размером метаданных конфигурации, поэтому здесь я приведу наши цифры, чтобы вы понимали контекст временных метрик, которые я буду в дальнейшем озвучивать.
14: У нас порядка 300 справочников, 400 документов, 500 регистров сведений и размер ц файла 950 мегабайт.
15: А на этом слайде видно, что время деплоя нашей основной конфигурации до оптимизации, если опустить тесты, составлял более полутора часов.
16: А после оптимизации нам удалось уложиться в плюс - 30 минут для расширения это время после оптимизации стало ещё стало ещё меньше. Мы там менее чем за 15 минут смогли выкатываться и в случае расширения для нас
17: Именные показатели ещё важнее, потому что мы их используем для исправления в продакшене и ход фиксов. И поэтому где счёт может идти на минуты.
18: Теперь давайте поговорим о стеке, который мы используем, чтобы вы понимали, контекст оптимизации и почему я упоминаю тот или иной инструмент. У нас есть едт конфигуратор гитлаб как средство автоматизации, развёртывания Гитин.
19: Синхронизации хранилища и гид Ван скрипт для скриптовой автоматизация и docker под управлением кубернетес с операционной системой убонту.
20: Давайте теперь разберём вообще, какие могут быть стратегии оптимизации пайплайнов. Можно использовать инструменты от вендора, например, автономный сервер вместо пакетного режима конфигуратора использовать различные стратегии управле.
21: Репозиториями гит на раннерах и механизм кэша и артефактов гитлаба.
22: Теперь давайте рассмотрим вообще концепт гитлаба из чего он состоит у него есть 3 основных элемента это гитлаб сервер или инстанс гитлаба gitlab ямал в котором перечислено что когда и в какой момент выполнять когда сборка, когда деплой, когда тесты?
23: И гитлаб раннеры это приложения, которые могут устанавливаться как служба на локальные машины, и они выполняют инструкции, которые перечислены в ямал файле, и что в этой схеме неэффективно по умолчанию перед тем, как выполнять инструкции из ямала гитлаб.
24: Раннер выкачивает полностью себе репозиторий и только после этого приступает к выполнению скриптов и вот в gitlab есть настройки, которые позволяют это поведение переопределить первые настройки это гид стратеджи она может принимать значение клон.
25: Клон самый медленный вариант, он полностью клонирует репозиторий перед тем, как выполнять задание.
26: Если существует рабочее рабочее дерево на раннере, то оно будет удалено. 2 стратегия это Феч. Она работает быстрее, она переиспользует существующий репозиторий и обновляет его с помощью команды гид Феч. В случае, если репозиторий не
27: Будет, то будет выполнен полный клон. Затем есть стратегия нон. Она удобна для тех случаев, когда нам не нужен репозиторий, когда мы только работаем с кэшем и артефактами.
28: И последняя стратегия это mt она отличается от none тем, что перед тем, как выкачивать кэш артефакты, она полностью удаляет существующий каталог сборки и да, и только потом приступает к выкачиванию кэша 2.
29: Переменная, да, это и 2 переменная гид депт, она управляет глубиной и количеством выкачиваемых версий репозитория. Если мы укажем значение гид депт равно единице, то мы получим последнюю актуальную версию репозитория.
30: Управлять этой переменной важно для больших репозиториев она позволяет существенно сократить объём и количество выкачиваемой информации.
31: Следующий механизм это кэширование и артефакты. И зачем вообще нужен кэш гитлаб? Каждый раз, когда выполняется задание, ей могут, ему могут потребоваться данные и зависимости, которые уже были
32: Были собраны на предыдущем этапе и нет смысла передавать, выкачивать и собирать их заново. Можно передавать их между джобами и пайплайнами и таким образом экономить время. Например, в контексте 1 с. Если мы на этапе компайла собрали ц файл, нет.
33: Собирать его заново на этапе обновления базы. Таким образом, кэш позволяет оптимизировать пайплайн благодаря переиспользованию данных. У кэша есть 3 основных свойства. Это key уникальный идентификатор кэша пас.
34: Список файлов и папок, которые нужно кэшировать и полисе, это политика кэширования. Каждый файл кэша хранится под именем ключа. Вот здесь в качестве ключа используется имя джаббы, что означает, что кэш будет хранитьс
35: В разрезе джобы и джобы с одинаковым наименованием смогут переиспользовать кэш.
36: При использовании кэша следует помнить, что кэш может быть 2 видов локальный и распределённый кэш это настраивается на раннерах в случае локального кэша файлы файлы будут храниться на хосте, на котором запущен раннер, а в случае распределённого
37: Cash они будут храниться во внешнем хранилище, например, в с. 3, и перед тем, как выполнять задание, архив будет выкачиваться из внешнего хранилища, разархивироваться, потом выполняться, выполняться джаба и после чего
38: Обновлённый кэш будет архивироваться обратно и отправляться во внешнее хранилище. При этом кэш не рсинк, то есть файл выкачивается полностью, а не его изменения. И, исходя из вышеперечисленного, следует избегать хранения в кэше больших файлов.
39: И вот ещё вот настройки китаба, которые переопределяют это поведение. Есть такая политика, есть политики кэширования, по умолчанию применяется политика пулл энд пуш, когда мы выкачиваем
40: Полностью кэш перед выполнением задания, потом выполняем задание и после выполнения обновлённый кэш кладём обратно. Можно применять политику пуш, когда мы только сохраняем кэш после выполнения задания или политику пулл. Когда мы только выкачиваем
41: Кэш перед выполнением задания и не кладём обновлённый кэш после ещё есть параметр кэш компрешн левел который позволяет указать уровень сжатия кэша чем выше уровень тем сильнее сжатие и тем медленнее разархивирование.
42: Следующий механизм это артефакты, они также позволяют передавать файлы и папки между джобами и их их отличительная особенность от cash является то, что, в отличие от кэша, они.
43: Позволяет передавать файлы между джобами 1 пайплайна, а кэш позволяет передавать файлы между разными пайплайнами, но наличие кэша не гарантируется. И какие основные грабли при использовании этого механизма.
44: В случае по умолчанию перед тем, как выполнять Джабу, будет выкачено, будут выкачены все артефакты, которые созданы в этом же пайплайне на предыдущих этапах, например, опять же, если брать
45: Если брать компайл, в котором собирается ц файл, и если в этом же пайплайне есть джоба Тестов, то джоба теста будет выкачивать себе собранный ц файл, тратить на это время, хотя на этапе Тестов это
46: Цепник совсем не нужен, и для того, чтобы эту проблему решить, есть ключевые слова ниц, артефакт и dependencies, в которые позволяют указать, какие конкретно файлы, из каких джопа нам выкачивать или вообще отказаться от
47: Скачивание артефактов. И вот здесь вот для dependencies указан пустой массив, что означает, что артефакты выкачены не будут
48: Перед тем, как к следующей теме перейти, я хотел бы добавить, что, что вот эти вот настройки, они, ну, выглядят довольно-таки просто, но достаточно часто встречаются ямлы, в которых на десятки джоб, в которых ни 1 из этих настроек не используется, что означает, что будут
49: Либо настройки по умолчанию, либо настройки из проекта. И это точно не эффективно для всех случаев. Поэтому пользуйтесь, пожалуйста, этими настройками. На этом слайде разбор нашего пайплайна до оптимизация и временные отметки для каждого
50: Этапа. 1 этап это синхронизация хранилища игита. До оптимизации его время выполнения составляло примерно 30 минут. Мы использовали для синхронизации расписание гитлаба, которое запускалось раз в 5 10 минут. Что
51: Вносила дополнительные задержки и провоцировала холостые запуски. Затем у нас идёт этап компайл для компайла. Мы использовали пакетный режим конфигуратора, и время сборки составляло порядка 40 минут. Потом у нас идёт обновле,
52: Stg. Время, время которого составляло около 17 минут. Если нет реструктуризации, потом идут тесты, тесты выполняются долго, их время выполнения зависит от количества Тестов ну, в нашем случае минимум час, и заключительный этап это обновле.
53: Продакшена, время которого, время выполнения которого составляло тоже около 17 минут, и того полный цикл пайплайна, если не учитывать тесты, составлял более полутора часов, но, конечно, в случае основной конфигурации эти
54: Они были разнесены по времени, и когда мы приступали к сборке релиза, хранилище уже было синхронизировано. Тесты мы выполнили ночью, но все равно это достаточно долго. И теперь давайте посмотрим, как
55: Как можно оптимизировать все эти вещи? Начнём с 1 этапа. Синхронизация хранилища эдит. Мы отказались от синхронизации по расписанию и перешли на событийную модель синхронизации для такого.
56: Подхода существует несколько инструментов например, tcp прокси сайт гитхаба этого проекта на экране такой подход, помимо ускорения, позволяет организовать дополнительные проверки пооо при событии помеще.
57: В хранилище, например, проверять статус тикета или проверять, соответствует ли комментарий к помещению хранилища требованиям компании дополнительный буст для этой джаббы стал перевод её в докер.
58: Мы смогли сократить время синхронизации до 5 5 тире 10 минут. Раньше. Эта операция выполняла 30 минут, и тут положительным фактором является то, что по умолчанию в докер контейнере
59: Каталог сборки у нас монтируется в оперативную память, и это благоприятно влияет на скорость выгрузки, конфигурации, файлы, а на этом слайде альтернативный вариант для организации событийной модели работы с хранилищем.
60: Это вебхук, который отправляет запрос на указанный сервер при помещении в хранилище гитхаб проекта также на слайде. Спасибо коллегам за такие прекрасные инструменты.
61: Следующий этап это компайл. Здесь мы отказались от пакетного режима конфигуратора и стали использовать автономный сервер. Автономный сервер работает в разы быстрее. Полная сборка полной конфигурации стала занимать около 5 6.
62: Минут, а раньше эта операция занимала 40 минут. 2, 2 оптимизационный шаг для джоба компайл стало использование стратегии гид депт равной единице. Нам не нужно. Нам нужна только последняя актуальная версия репозитория для того, чтоб
63: Собрать ник и, соответственно, это сократило количество выкачиваемой информации.
64: Джоба компайл собирает ц файлы, передаёт её в следующие этапы с помощью кэша. И тут нам нужно собрать ц файл и положить его в кэш. При этом нам не нужно получать предыдущее значение ц файла, поэтому мы применяем политику.
65: И только кладём в кэш ещё 1 стратегией оптимизации для джобы компайла было запараллеливание её со вспомогательными джобами на этом слайде примеры релизного пайплайна, и видно, что был этап build.
66: Мы отказались от него, запараллелили джобу компайл с вспомогательными джобами, и это в купе с автоном применением автономного сервера позволило нам получать готовый цепник на тот момент, когда вспомогательные джобы выполнились.
67: Следующий этап это обновление стг кондёра. Здесь мы применили стратегию стратеджи равные none, потому что нам не нужно, нам не нужен репозиторий. На этом этапе нам нужен только ц файл из кэша и
68: Скрипты для обновления базы скрипты мы выкачиваем точечно с помощью rest api гитлаба
69: Ну а цепник получаем из cash потом мы посмотрели на другие джобы, где нам не нужен репозиторий, применили там похожую стратегию, и это позволило нам сократить порядка 2 минут на каждой джобе.
70: Также мы для обновления используем оптимизированный механизм обновления в 2, но мы начали его использовать практически сразу. Но вот недавно от коллег узнал, что даже в крупных компаниях не везде он используется, у нас он используется достаточно давно на разных конфигурациях проблем никогда.
71: Не было, так что пользуйтесь.
72: Да, это фрагмент джобы стейджинг. И здесь видно, что мы применили стратегию стратеджи. Равно none.
73: Затем идут тесты для Тестов можно применять несколько стратегий оптимизации, можно распараллеливать тесты, выполнять их на разных базах с разными настройками, можно оптимизировать код конкретных Тестов. Например, мы используем вас адд.
74: Для тестирования домовых форм, для домового тестирования обычных форм и тесты, которые идут с ней из коробки, и в нашем случае только построение дерева Тестов занимало около получаса.
75: Мы оптимизировали этот шаг, перевели его на многопоточку, и время стало занимать около, ну, времени. Несколько минут стало занимать построение дерева, потом важно управлять правильно, артефактами. Я об этом об этом уже упоминал.
76: По умолчанию джоба выкачивает все артефакты, которые были созданы на предыдущих этапах, и, если неправильно ими управлять, джоба тесты может получать артефакт, тратить на это время, хотя для выполнения Тестов артефакты не нужны.
77: Ещё я бы хотел в контексте оптимизации Тестов поговорить о хотфиксах. Мы для хотфиксов используем расширение, они отлично для этого подходят, они быстро собираются, быстро обновляются, но потом все это упирается в джобу Тестов, который может выполняться несколько часов.
78: И тут 2 варианта развития событий. Либо мы вообще не тестируем изменения, которые выкатываем по хот фиксам, либо мы делаем какие-то отдельные быстрые тесты для ход фиксов. Мы не стали поступать, как гарри и сделали, разработали.
79: На фреймворке икс юнит несколько быстрых юнитов плюс сделали 1 тест, который компилирует все модули расширения и выполняет таким образом синтаксическую проверку этих модулей. Такой подход позволил нам получить
80: Быструю экспресс проверку наших изменений перед выкаткой в продакшн.
81: Теперь я бы хотел рассказать про докер и те сложности, с которыми мы столкнулись при переводе джоб в докер основная сложность это то, что время выполнения сравнения, объединения, конфигурации после перевода в докер стало почти в 2 раза дольше.
82: Чем на windows раннере. Это стало блокером для большинства команд. Мы пришлось приостановить переход, разбираться с причинами. И вот что мы нашли. Мы настроили технологический журнал. Это примерно
83: Настройки. Мы отбираем все события без детализации. Аналогичную настройку сделали на windows. Раннеры проанализировали полученные логи и выявили, что в случае докера мы теряем платформенный кэш, так как
84: Окружение в докере каждый раз создаётся заново, временные файлы не сохраняются, соответственно, платформенного кэша нет, и, как решили, помог кэш гитлаба на этом листинге.
85: Показано, что мы в файле локейшна указываем папку для хранения временных файлов платформы, а гитлабу говорим, что эту папку необходимо кэшировать в качестве ключа. Используем строку подключения к базе данных.
86: Таким образом, каждая база данных будет использовать свой кэш, и вот такой подход позволил нам прибли, ну, как бы такое же время получить сравнение объединения, как и в случае windows раннера.
87: 2 проблема это потеря конфикт, дамп, инфа. Этот файл используется платформой для того, чтобы выполнять инкрементную выгрузку файла и он нужен для гесинка, чтобы определять, какую делать выгрузку полную или инкрементную. И опять же причиной.
88: Из за того, что окружение создаётся заново, никаких файлов с прошлого запуска не остаётся. Решили, опять же, с помощью кэша говорим гитлабу, что этот файл необходимо кэшировать. И, соответственно, такой подход исключает то, что мы потеряем этот файл, и он
89: Будет доступен для очередной операции синхронизации.
90: Следующая проблема это то, что для определённых Тестов в данном случае открытие управляемых форм, мы получили резкое замедление. Вот на этом слайде видно, что для windows раннера набор Тестов выполняется за 400
91: Миллисекунд, а для докера это время составляет 3000 миллисекунд опять стали разбираться с причинами, настроили технологический журнал, и тут на самом деле оказалось, что в случае windows ранера из за особенности запуска
92: Служба. Ну, из за особенности запуска раннера тесты фактически не выполнялись, поэтому, поэтому такая разница, ну, то есть, в случае докера они действительно выполняются, и поэтому время увеличилось. Здесь, к сожалению, оптимизир
93: Ничего не удалось, но мы нашли, что у нас тесты какие-то, тесты не работают.
94: Вот, но можно использовать кэш на самом деле. И вот тут видно, что использование кэша для этих типов Тестов даёт прирост порядка 20%. Но следует учитывать, что если вы между запусками Тестов внесли изменения в конфигурацию,
95: То, возможно спецэффекты и какие-то ошибки, поэтому мы такой механизм пока не применяем.
96: А теперь давайте подведём краткий чек лист оптимизации. Используйте автономный сервер вместо пакетного режима конфигуратора применяйте стратегию. Идёт равной единице там, где не нужно выкачивать большое количество версий репозитория.
97: Применяйте стратегию гид стратеджи равный none для job, которые используют только кэши, артефакты запараллеливает джобы, где это возможно используйте многопоточные тесты, используйте быстрые тесты для тестирования ход фиксов.
98: Можно создать отдельный репозиторий для скриптов, для того, чтобы не выкачивать полностью репозиторий там, где это не нужно. Помните про платформенный кэш и про то, что скорость деплоя на самом деле зависит от ресурсов раннера. Поэтому нужно следить за теми джобами, между которыми
99: Которыми эти ресурсы разделяются.
100: А теперь результаты. После оптимизации нам удалось синхронизироваться за 5 минут раньше эта операция занимала 30 минут. Сборка стала тоже занимать 45 минут против 40 минут ранее обно.
101: Стало выполняться за 11 минут, вспомогательные шаги в общем тайминге стали занимать 0 минут, потому что мы запараллелили их со сборкой, и итоговый результат выкатка основной конфигурации за плюс - 30 минут, а для расширения
102: Это время составляет менее 20 минут.
103: На этом все. Да. Коллеги, спасибо за внимание. Готов услышать ваши вопросы. И у нас
104: Спасибо большое. У меня прям есть ремарка. Вчера был вопрос, что, типа, вот мы тестируем на линуксе, а вот на виндовсе работать не будет. Вот доказательство в линуксе в виндовсе не работало у людей, а не работало из за графики. Ну,
105: Не работало из за того, что windows раннер запускается как служба, и там, ну и особенности теста. То есть там тест открывает форму по ссылке. И, ну, собственно, открыть доступ к рабочему столу. Нужно его сначала инициализировать, чтобы он
106: Получилось только потом запустить раннер. Ну, у нас есть 2 вариант запуска ранера, когда мы запускаем его не как службу, а как экзешник, и там такой проблемы нет, понятно. Ну, погнали по вопросам. Давайте вопросы. О, вопросы есть? Так?
107: Спасибо, здравствуйте. Я не очень поняла. То есть, получается, у вас все равно разработчики все выкладывают в хранилище, и вы уже из хранилища подтягиваете в гид. То есть не очень. Мне просто интересно, почему выбрали такое решение, потому что это не очень удобно с точки зрения захвата объектов. То есть 2 разработчика не могу параллельно как бы захватить и
108: Если им нужно, вроде у вас в компании, я так поняла, очень большой штат разработки, почему не сразу все выкладывают просто в гид и уже там все собирать. Угу. Ну, это на самом деле, то есть у нас несколько команд, и каждая команда работает
109: По разному. Есть команды, которые работают на ддт. У них вот этой этапа с хранилищем нет вообще. То есть они сразу коммитят гид, а те команды, которые работают на конфигураторе, они используют связку конфигуратор, хранилище, гид и
110: Хранилище синхронизируется с гитом с помощью gui цинка, ну, есть определённые сложности с параллельностью, да, при таком подходе, но как-то, ну, как-то они решаются административным способом. Ну, это довольно-таки распространённая схема.
111: Классическая, да.
112: В нашем случае, в нашем случае польза Гита в том, что все изменения, которые делают разработчик, аудируются. То есть все версионируется. Мы видим каждое изменение, кто его сделал, и весь деплой только из Гита.
113: А вот тогда вопросики а в тот момент, когда разработчик че то в хранилище кладёт, это какая-то отдельная ветка, связанная с ним, или это там хранилище, связанное с основной, например, death веткой да, в случае, если мы используем конфигуратор, есть 1 ветка?
114: Develop и Гицин синхронизирует хранилище с веткой девелоп. Получается, что я как разработчик, по сути могу просто кнопочкой взять и в ветку че то положить. Но ведь кажется, что базовая стратегия, ну там того же гитлаба.
115: Заключается в том, что комитить в основную ветку это харам так делать нельзя.
116: Я просто тоже подумала, что вы выгружаете версии хранилища, и у вас каждая вот получается выкладка программиста, она у вас отдельной веточкой получается на каждую мерджи квест. Вы там потом принимаете веточки, потому что если программист выложил уже в хранилище, вы сразу забираете в deploy. А-ка.
117: Вы тогда, ну, то есть у вас получается, в релиз собирается сразу все, вы уже потом не выбираете. Не, да, в случае, в случае, в случае, если мы, если команда работает с хранилищем и конфигуратором, каждая, каждая версия хранилища это отдельный
118: Commit в git в 1 ветке develop в тот момент, когда мы приступаем к ветке когда мы собираем релиз у нас от какого-то коммита ветки девелоп ну мы её отрезаем, создаём ветку release и дальше на релизной ветке мы собираем, но.
119: Недостатком такого подхода, вы правильно заметили, является то, что мы не можем выбрать, какие коммиты идут в релиз. Вот то, что у нас сейчас есть в ветке develop, мы релизим, мы используем фичи флаги так называемые, если какой-то функционал не готов, или он там уже
120: Помещён в хранилище, при этом по каким-то причинам мы его ещё не хотим запускать. То есть мы какую-то константу вводим и говорим о том, что этот функционал будет работать там с такого-то релиза, а нету потом сложности отслеживать вот такие ветки, если там, допустим, программист
121: В отпуске, там у него лапки не дошли, там кто-нибудь там аналитик че-нибудь не принял. Ну, этого, у этого подхода. Особенно, если это обычная форма. У этого подхода есть недостатки, вы вот о них говорите, но есть и плюсы, то есть
122: Плюс в том, что разработчик поместил в хранилище и все. Дальше он ничего не делает, ему не нужно переносить между различными, там, я знаю, вот некоторые используют там несколько хранилищ релизное ещё какое-то. То есть разработчик поместил в хранилище и все.
123: И забыл. Ну если ему не нужно, если его код ещё по каким-то причинам не готов, он оборачивает свой код фича флагом, все на этом его деятельность заканчивается. Ему даже не нужно погружаться в то, как работает гид. Просто
124: С 1 стороны, я могу понять, да, то есть 1 сникам не приходится, возможно, познавать для себя новый продукт. Но вот, например, подход, если вы отказываетесь от хранилища и замещаете, ну, как бы вместо него сразу каждый программист выкладывает в гид. Вот тут есть некоторое удобство именно сбора конфигура.
125: Чтобы выкидывать. Давайте это на круглом столе. Я согласен, что возможно, но есть и недостатки. Да, пока Иду до следующего. Вопрос у меня такой, ну, в принципе, если используется 1 ветка, тогда схема
126: С формированием кэшей. Понятно. А вы эту схему с кэшированием не пробовали на многоветочность репозитория? Или вы там другой уже нейминг для кэшей используете? Ну?
127: Банально. У меня ветка фича 1, у соседа ветка фича 2. Если я правильно понял, как у вас будет сформирован, сформирован кэш, то мы с ним получим его одинаковый, но у меня коммит, не знаю, номер 1. У него коммит номер семьдеся.
128: Тысяч, а вы говорите, и у нас кэши будут как бы не очень валидны друг другу применять. Ну а вы там просто в 1, если, если говорить об использовании кэша для того, чтобы ц файл передавать.
129: Там следующий, там в качестве ключа используется хэш коммита. То есть такой проблемы там нет, не, не, не, где вы кэш используете для платформы, где вы используете там конфигу.
130: Этот дам конфигурейшн для экспорта, это на релизной ветке. То есть это только для релиза вас. Да? Все окей. Спасибо. Так, здравствуйте, Гончарук Юрий. Техрешение. Ну так, ремарка к предыдущему.
131: Про плюсы хранилища в 2005 году, это так себе уже, наверное. Вот. Ну, собственно, вопрос такой. У, на, мы столкнулись с ситуацией, вот, с деплоем, что ибм, соответственно, не поддерживает файл поставки, то есть, он не
132: Может сформировать никоим образом. То есть вы, я так понимаю, не пользуетесь файлами поставки, а просто обычное seo делаете на да, мы делаем обычный цф и обновляемся в режиме сравнения объединения. Все хорошо, спасибо.
133: Вопросы. Коллеги, а вот здесь вопрос. Да, здравствуйте. Спасибо за доклад. Николай. Компания гри. Подскажите, пару вопросов появилось в итоге на деплой на прод. У вас в автоматическом режиме происходит?
134: Или это ручное действие. Ну, то есть, ну, для того, чтобы цепник накатился на продуктовую базу, надо нажать плей джобе. Ну, то есть я не знаю, как это назвать.
135: Полностью автоматический или ручной? Автоматизированный. Автоматизированный, да, наверное. Понятно. Пайплайн доходит до этапа, собственно, выкатки на прод, и кто-то ответственный нажимает кнопку выкатить. Да. А что является?
136: Ну, триггером для выкатки на прод. То есть это по каждому коммиту собирается. И есть возможность по каждому коммиту условно на прод задеплоить или нет. Ну, мы собираемся на релизной ветке.
137: Вот все тикеты и кометы, которые вошли в релиз, ну, собираются в ц файлы, и потом, не знаю, в соответствии там с расписанием, регламентом релиз инженер нажимает на кнопку выкатки продакшн, а фиксы у вас?
138: Также в ручном режиме выкатывается или ну то есть обязательно вот это ручное действие ответственного человека или все-таки фиксы в автоматическом режиме? Ну нет, действие, действие это нужно произвести. То есть мы на продакшн на последнем этапе у нас
139: Всегда есть кнопка, на которую нужно нажать, чтобы изменение применилось. Продакшн.
140: Ну то есть там серия пайплайнов для хот фиксов процесс выглядит так, что разработчик помещает изменения в хранилище для хот фиксов. Дальше идут все этапы синхронизации, там хранилища, Гита, тестирование, накатка на стг. И вот
141: Последний этап на выкатке в продакшн нужно нужно получить апруф там от тестировщиков, от всех заинтересованных лиц и после того, как этот опру релиз инженер получает, он нажимает выкатить продакшн н спасибо.
142: Ещё у кого-то вопрос.
143: Вопросы ещё, коллеги? Вот Иду.
144: Да, здравствуйте, Наумов Александр. Я хотел уточнить, был ли вообще вариант использования каких-то таких способов, ну, типа центра администрирования от 1 с или что-то такого для того, чтобы делать релизы и
145: Ну стандартные средства 1 с использовать которые в keep есть или вы даже это не рассматривали мы, я хочу сказать что у нас часть какого-то у нас были требования и мы часть каких-то вещей реализовали с помощью
146: Администрирования и встал вопрос о расширении масштабировании. И сейчас с этим большие проблемы. И мы выбираем, каким дальше способом пойти. И вы рассматривали это или даже нет. Нет, мы не рассматривали. У нас просто есть стек в компании определённый
147: И мы, собственно, использовали тот стек, который есть в компании, по которому есть экспертиза, и те инструменты, о которых я рассказывал. Спасибо. Угу. Тут ведь, если внутрь копнуть того же центра администрирования, там,
148: Под капотом используются Ровно те же самые утилиты, которые используют ранеры там того же guitar н. Гитлаба окей, я хочу акцентировать лучше рака раса пакетного режима конфигуратора.
149: В некоторых случаях айби сиэмди, в принципе то ничего нет, этого не существует, есть ограниченный набор инструментов, который ты можешь использовать там через docker напрямую скриптами, ручками, гитлабом.
150: Центром администрирования про рандек будет рассказ все тоже самое. А, ну как бы точка входа, она 1. Ну ничего другого нет. Обратите внимание на правильный был комментарий. Есть экспер.
151: По тем или иным продуктам и технологиям. То есть, когда у вас есть там условный гитлаб, да, и вы, значит, собираете на нём, у вас есть там штат питонистов, вы используете их силы и не нанимаете там и не
152: Обретаете эти велосипеды, если у вас там, не знаю, там, дженкинс, тим сити и так далее. Вы собираете на нём, и не надо смотреть, что у соседей собрано на условном гитлабе, да?
153: Ещё вопрос, коллеги.
154: Я ещё задам вопрос. Меня, знаете, че, смутило? Ну, кажется, что автономный сервер это вот, ну, такая штука, которая вендором хоть и поддерживается, но явно.
155: Явно рекомендации применять автономный сервер для взаимодействия с продуктивным окружением не существует. Ну то есть vendor говорит, у нас есть вот happy path, да, мы там должны жить вот так обновляться через там конфигураторы и так далее и так далее.
156: Не опасаетесь, не опасаетесь ли вы возможных проблем, которые могут быть при сборке бинарников, а конкретно цфа фешки с использованием автономного сервера и дальнейшей доставки этих артефактов на продуктив?
157: Ну да, мы опасаемся. У нас на самом деле даже был какой-то кейс, когда мы для работы с автономным сервером есть библиотека и бар. И вот у нас был на какой-то платформе инцидент, когда мы собра.
158: Там пустой цвникель на самом деле у нас существует стг контур, и перед тем, как накатить на прод цфн, накатывается на стг, запускается там довольно-таки много Тестов, плюс ручное тестирование.
159: И если какие-то спецэффекты возможны, то мы надеемся отследить их на стг.
160: Типа, прокатило, не прокатило, да? Не, ну в смысле, ну вот, вот был конкретный кейс, собрали некорректный ц, ну, мы это увидели. Вот. И, соответственно, ну, то есть мы опционально, у нас есть опция, мы можем использовать
161: Можем не использовать, да, если мы его не используем, то мы будем собирать цку там в несколько раз дольше. Ну, если есть какие-то проблемы, мы можем переключиться на этот режим и собрать цфк обычным способом. Угу. Спасибо.
162: Что-то вопросов. Вопросы кончились. У меня ещё есть. Давай услышал, что для передачи црки вы используете кэш. Кажется, что гитлаб явно не рекомендует этого делать, говорит.
163: Cash, ну это сущность, которую нужно применять для кэширования библиотеки иных зависимостей. Цэфи это, собственно, классическая сущность, да, которая необходимо передавать как артефакт, сбор.
164: Использовать для этого, собственно, артефакт или нетс? Почему был использован кэш? Да, спасибо. Вопрос хороший. У нас на самом деле для выкатки в продакшн создаётся отдельный пайплайн, то есть есть пайплайн на релизной ветке.
165: Когда мы выкатываем на продакшн, там стартует новый пайплайн, так пайплайн, так называемый, и для того, чтобы передать туда цепник, артефакты не подходят, поэтому мы там на самом деле такую немного сложную схему.
166: Используем, то есть в рамках релизного пайплайна цепник передаётся через артефакты из компайла, допустим, в обновление стг, а в так пайплайн цепник передаётся через кэш, но у нас есть там отдельная джаба, которая проверяет
167: Что в кэше действительно лежит ник валидный, и если она не упала, то мы приступаем к выкладке продакшн, а у вас нексуса нету? Нет, ну это получается зависимый пайплайн. Да нет, который типа пайплайн генерится.
168: Родительским пайплайном. Да, да, там нельзя передавать артефакты, по крайней мере, в бесплатных версиях гитлаба. Точно поставьте нексус и кладите артефакт туда и закачивайте. Да, да, да, да, да, ёлки палки.
169: Так, коллеги, ну, собственно, у нас время истекло, да, сейчас в зале стрельна. Ещё раз большое спасибо. Да, коллеги у нас ещё есть, на самом деле, хотели отметить коллег.
170: Девушка убежала. Да, давайте вам, вам тогда вру.