Transcription
Сегодня очередной доклад от меня, аа, и я думаю, что не последний. А в общем-то, если вы вдруг пропустили, есть записи, заходите, пожалуйста, подписывайтесь на нас, кто нас смотрит в Ютубе и других платформах. Поэтому добро пожаловать.
Сегодня будем окунаться в действительно рабочую вещь, потому что я решил этим поделиться с вами, а после того, как, а вдруг неожиданно, а столкнулся с тем, что рабочий документ, аа, дал мне довольно много пищи для размышлений. И когда мне удалось наконец-то его сделать в глубину, я понял, что до этого я делал их неправильно.
А если вдруг кто меня ещё до сих пор не знает, можете быстро прочитать тут про меня. Интересуюсь всяким, делаю разное, работаю сейчас в основном как solution архитектор, поэтому делюсь с вами сегодня технической работой. Не зря же там написано "Architecture Decision Record" название.
А что сегодня будет? Немножко в другом формате я представлю сегодня, потому что мы будем ходить, а, по документу, который я раздербанил на слайдах. Вот. И начнём, грубо говоря, с чего-то более-менее знакомого, что могло бы быть. Затем, а, плавненько пройдёмся по разным частям этого документа, что я сделал в них, что для меня было новым, что, в принципе, показалось интересным, да, и, а, даже затронем такой момент, как информационная безопасность и совершенно новый хайповый с у вас топ-тем двадцать пятого года взятый момент, связанный именно с CCD драйвери.
Итак, а я про себя рассказал. Сейчас давайте, кто у нас тут? Расскажите, пожалуйста, тут есть ли у нас DevOps'ы? Люди, признавайтесь. Вот. Ага. Кто-то, по идее, что-то должен писать, а я ничего не вижу. Вот это интересно. >> А есть рука? Ээ, кто-то может голосом сказать. Виталий, да. Да. А давайте вкивайте. >> Надо. Здравствуйте. Надо представиться, рассказать о себе или как? Или просто достаточно, что я DevOps связан? >> А давайте пишите в чат, короче, чтобы я знал, что у нас тут, потому что для разных людей нужно рассказывать по-разному. Вот. А если у нас C-level, CTO или там, не знаю, Head of Development, Engineering Manager, куда-нибудь вот туда. О, а просто разработчик. Прекрасно, да? Разработчиков я ещё доберусь. А, архитекторы есть. Волно. Вот, вот я люблю, когда приходит архитектор. Ага. А-а, спасибо большое, что пишете. Это очень приятно. Сразу видно, что вам интересно. Аа есть, наверное, может быть, здесь есть кто-нибудь вообще не особо технический, кому просто интересна стала эта тема. Вам будет интересно, но тяжело, честное слово. Ну, у нас, наверное, нет такой аудитории, Андрей. Ну, то есть у нас в основном всё-таки, наверное, инженеры собираются. Может быть, чуть-чуть QA бывает, но в основном да. >> Да. А, ну не, на самом деле, бывают люди, вот приходили на ВАЗП, которые вроде как технические, но они, допустим, с Security были тяжело знакомы. А CCD, вы знаете, тут был такой недавно проект у меня, на который я захожу. Я разговариваю с ними и говорю: "У вас инфраструктура через код есть?" И тишина. А там вроде такие вот матёрые архитекторы, DevOps'ы, они такие сидят и не знают, что ответить. Я говорю: "Ну вот что такое?" Ну вот, ну да, мы знаем, что такое Terraform, и мы его используем, когда нам нужно 10 машин развернуть. Я думаю, ну да, вот такой уровень бывает иногда. Так что ничего страшного, все по-разному сами заходят в эту тему.
А давайте тогда начнём. А чтобы понять, о чём мы разговариваем, неплохо было бы знать, а вообще, что это такое за термины. А для меня было очень интересно узнать, что на самом деле этот, а Continuous Integration появился сильно раньше, чем а наш мир познал, так сказать, и даже Extreme Programming, хотя он как раз популяризировался Extreme Programming'ом. И те люди, которые стояли у истоков и популяризировали это направление, они, собственно, и положили основы. А из этого выходит очень интересные несколько вещей, которые они не очевидны, но я сегодня их затрону, такие философские немного.
А Continuous Delivery - это ещё такой следующий шаг, появился сильно позже. И а я очень рекомендую а знакомиться с творчеством товарища Дейва Фарли. Он, у него есть канал MSE, который до этого назывался Continuous Delivery. Если вы хотите прокачать понимание такого Трубританского акцента, даже немножко шотландского, ну, короче, welcome. А у него очень интересные видосы были. Сейчас он больше куда-то топит философию. В общем, человек за Agile, за Kanban, за Trunk Based Development, за DORA. Ну и короче такое.
А Deployment, Continuous Deployment тоже часто как будто бы поднимается под CD. А хотя это такой ещё более радикальный подход, а чуть-чуть мы его затронем. Но когда мы говорим про CCD, мы не имеем в виду Continuous Deployment - это скорее именно Continuous Delivery.
А что я всегда для себя считал, и может быть, другие, вы тоже можете как-то припомнить, что вам приходилось обычно писать для таких документов, которые описывают себя ICD, да, аа, или там релизную политику или что-то такое. А-э, для меня в первую очередь было три вещи. Аа это стратегия ветвления. Я помню, ещё лет 7-8 назад такие были жаркие споры в архитектурном комитете, как правильно ветвиться. Тогда ещё вроде бы а была такая первая волна Gitflow. И энтузиасты, разработчики хорошо знали Gitflow, а вот архитекторы ещё не знали или да, ну, ещё не знали, потому что тогда уже такие старые дедки сидели в таких местах. Вот. А сейчас наоборот, все архитекторы более-менее хорошо знают, что такое Gitflow, а разработчики уже учились у людей, которые не сильно помнят. Ну, в общем, это обязательно нужно писать, потому что люди очень веселятся, когда делают ветки.
А-а, триггер сборки, да, очевидно, что, собственно, запускать ICD пайплайны нужно на какие-то события. Ну, и, в конце концов, стратегия промоушена, а в каком случае куда что идёт, с dev на stage и так далее, зависит от того, какие, конечно же, у вас есть среды. И вроде бы как всё. И, может быть, какие-то, может быть, детали туда нужно добавить, куда там артефакты собираются. Ну, в целом, для меня всегда этот документ был похож на вот подобные секции. И я всегда успокаивался, когда заканчивал какой-нибудь архитектурный документ вот на этих трёх штуках. Ну, и времени, может быть, не было так много, да, и доходило это скорее до каких-нибудь DevOps'ов, которые сидят в клауде.
Но тут, а, до меня пришёл другой проект, на котором я был единственным архитектором. А команда платформами была на стороне заказчика с небольшим опытом, да ещё и в on-premise. И пришлось задуматься об этом во всём чуть-чуть поглубже.
Ну давайте начнём с ветвления. А у нас стратегия ветвления, она на самом деле прямое влияние имеет на себя CD, потому что она говорит о том, как изменения проходят от идеи до реализации. А мы помним, что Integration - это всё-таки а-а, линтер, да, я не знаю, у меня такого не было, если честно. А линтер он включён в этот в CI в CI-ные пайплайны, да, а линтеры, но прямо именно в продвижение, если у вас где-то на релизной ветке всё плохо работает. Ну, сейчас мы, кстати, дойдём, может быть, до этого, где какие гейты нужно ставить, похвалить. Ну, короче, возвращаемся к нашим баранам. А, соответственно, где проверяется, да, становится артефактом это всё туда же. И кто и когда имеет право продвигать? А, в принципе, именно из того, какие мы ветки делаем в нашем репозитории, я вполне верю, что у нас есть люди, которые на Mercurial работают или на SVN, да. Но большинство людей сейчас работают на Git всё-таки, поэтому я буду его упоминать.
А, а что у нас, собственно, есть? Ну, из всего огромного разнообразия веток, давайте я выделю две полярных. А я выделю Gitflow и который у нас, э, очень сильно популяризировано в командах, а, и оно позволяет достаточно классно работать. А, скажем так, собрало весь весь опыт работы ветвления именно. И есть супер такой вариант противоположный, а, который, собственно, Дейв Фарли продвигает. Trunk Based Development. Мне тоже посчастливилось поработать в таком варианте. Очень интересно. И поначалу кажется, до какого фига, особенно если спойлер потом как бы это как в анекдоте. Сначала Барсик боялся пылесоса, потом ничего, втянулся. И эти два подхода, они очень философски отличаются. Там такая даже религиозная война может быть между адептами одного и другого решения. Но самое интересное, что у них фундаментальное различие, а, влияет ещё на ICD. А, но начнём пока немножко издалека. А дело в том, что Gitflow - это идеальная реализация под Scrum, а Trunk Based Development под Kanban. И если вы пытаетесь сделать условно Trunk Based Development в Scrum, это, конечно, хорошо, но вы по сути не работаете с Scrum, может быть, может быть, работаете, да, но вам, наверное, в этом случае стоит больше на Kanban переходить, потому что вывод у вас как бы идёт именно в сторону наиболее быстрой интеграции, в то время как Gitflow готовит батч аа изменений и стабилизирует, да. А фактически это тот натуральный способ Scrum, который есть. Конечно, есть люди, которые стараются делать тестирование в течение спринта и хотят выводить это с помощью веток. Так тоже можно, но там есть свои нюансы, связанные с тем, что всё-таки есть итерация и в начале спринта мм сложнее ветки выводить. Но в целом дискуссионная вещь. Э давайте пока положим, как будто бы докладчик верит, что это так. Конечно, всё не совсем так просто.
Ну итак, а есть у нас это Gitflow? Аа, конечно, они немножко по-другому отличаются. Полностью согласен, там такие веточки есть, да, конечно, у нас фича ветки есть и в Trunk Based Development. Здесь мы, конечно, не поставили себе Git. Кстати, рекомендую, если вы хотите немножко пострадать потом себе испытывать большое удовольствие от Pull Request Review, это тоже всё, но всё-таки радикальная штука.
Итак, а здесь такая стандартная красивенькая схема, а нарисованная вправо. А но у неё, собственно, нужно знать, а где же мы собираемся триггерить какие-то сборки. Ну, очевидно, что мы хотим её триггерить на отведение веточки. Возможно, да, не факт. А-а, скорее всего, мы хотим её делать при merge. А-а, при, наверное, при каждом вот этом движении developer, да? А, наверное, мы хотим ещё при релизных ветках, потому что релизные ветки у нас, а, собираются и кладутся куда-то. Аа, скорее всего, нам бы хотелось ещё при диплое, когда у нас релизная ветка закрывается. Ну, и для самых отчаянных а нужна какая-то сборка хотфиксов. А, честно, хотфиксы вообще очень сильно выбиваются из релизной политики. Как правило, люди забывают их написать, а настолько сильно, что даже я не стал описывать её в этом докладе, потому что Hotfix - это ситуация такая немножко отчаянная, и, как правило, её стараются избегать, а, тем не менее, собрать её можно. В нашем случае можно было бы считать, что а hotfix будет себя примерно вести так же, как релизная ветка, потому что можешь посмотреть, что она в конечном итоге кладётся в те же самые веточки в main и develop.
А с Trunk Based Development всё немножко иначе, а потому что там никакой релизной ветки нет. То есть нам хочется, наверное, собирать э релизы, да? А, возможно. А опять же, это зависит от того, какой у вас способ работы. А вам, вероятнее всего, на 100% понадобится собирать каждый коммит в master. А здесь, собственно, и работает CI. А, и, конечно, вам наверняка придётся какие-то из этих версий собирать на, а, другие среды. А здесь есть некоторые различия, потому что в отличие от того же Gitflow, здесь нужны какие-то определённые условия, при которых master, а, master коммит пойдёт дальше.
А что интересного, да? А если мы взглянем на философию Gitflow, то очень легко, в принципе, догадаться, что она сама по себе, а нарушает полностью принцип Continuous Integration. А хотя бы потому, что интеграция в main у нас происходит очень долго. Плюс сама концепция разработки здесь, э, часто вырождается в то, что фича ветки достаточно долгие. А, и несмотря на то, что develop у нас, грубо говоря, обновляется часто, а разработчики склонны считать его грязным настолько сильно, что он может прямо содержать очень нерабочий код. А в то время как Trunk Based Development в этом плане ближе к истокам, наверное, поэтому люди, которые сидят в этом стане, они ближе к Agile, Kanban, Clean Programming и такое.
Как управлять релизами. А здесь, собственно, происходит переход от веток к самим циклам. И я сейчас буду вам показывать большие страшные диаграммы. Но для начала давайте разберём, когда же у нас всё это происходит. Аа есть вещи, связанные с разработкой фичей. Это в первую очередь всякие merge'и. Это непосредственно второе - это сборки dev ветки или development, связанные с development средой. А, конечно же, тестирование и prod, а, выход в продакшн, доставка туда. Аа, как правило, со средами, связанными как dev, stage, prod, естественно, не обязательно, что они так называются. И у фичи ветки, соответственно, никакого никакой среды нет. Они исполняются в виртуальной среде, поднимается там в Docker'ах образы, базы и всё такое. Тесты крутятся и никуда это дальше не плодится.
А что у нас с фичей и dev? А если же по Gitflow смотреть, то вот у меня была такая диаграмма. Это первая её часть, первая и треть для Gitflow, когда у нас merge request создаётся на merge request у нас создаётся build. Он фактически что-то там билдит и никуда дальше не идёт, да. А вот при merge'е у нас идёт, соответственно, только CI и образ, создавшийся кладётся в temporary папочку, потому что зачем нам это всё дело держать куда-то? У разработчиков могут быть довольно много этих версий и деплоев.
А-а, в моём случае я предлагаю сразу рассматривать микросервисную архитектуру, потому что она наиболее интересна с точки зрения CCD. У неё свои особенности. Вот. Аа интересно то, что реакция на эти сборки, что dev, что release, они одинаковые, достаточно симметричные. Вот только уходят они либо на dev, либо на stage, то есть релизный ветка уходит на stage. Вот. А с Trunk Based Development немножко иначе. А, конечно, здесь может показаться, что похоже, да, потому что на merge request фича ветки в master у нас всё то же самое. А вот только build на stage здесь нет. А потому что А а почему, наверное, смотрим дальше, потому что а вот здесь происходит немножко более активная позиция команды, а именно тестировщиков. Но при этом CI'ка проходит, да, у нас есть какой-то образ, и он уже складывается не в temp директорию, да, как здесь, которая чистится, а она уже складывается вполне себе в такую конкретную релизную веточку. То есть мы здесь прямо CI конкретно делаем. Только здесь фишка в том, что начинается она по тегу. В отличие от обычной сборки, мы не говорим какую. Если команда разработки считает, что версия достаточно стабильная, а тег, а триггер, пошли собирать QA. Аа у нас, в принципе, есть несколько деплоев, да? А они происходят в разное время. А QA начинает тестировать, а помним, что здесь уже всё задеплоено, QA ничем не управляет, начинается тестирование. Закрываем релизную ветку. Dev коммитится, уходит это в релиз. Точно так же идёт сборка. А то, что пошло в master build. И это вот только сейчас уходит в настоящую релизную папочку. Одновременно с этим, когда заканчивается демо-сессия и мы всё получили, у нас хорошо есть добро от Product Owner'а, а мы собираем интересную штуку под названием Snapshot Manifest. Я о ней расскажу чуть позже, а почему этот артефакт нужен и какой он роль несёт.
А с Trunk Based Development всё чуть-чуть иначе. Здесь а QA решает, что нам бы задеплоить версию и выбирает версию, которую хочется не задеплоить. Все остальные точно так же проходят. Дальше у нас идёт тестирование. Тестирование заканчивается. И заканчивание окончание тестирования. Кстати, здесь демо отсутствует. Вот прикол. Ну, она тоже здесь, допустим, есть. А триггерит создание манифеста. А, напомню, что релиз у нас уже здесь существует и всё, что у нас здесь лежит, оно уже собрано. Поэтому ничего, второй раз собирать его куда-то укладывать не надо. Вот такие небольшие различия есть.
А с Delivery всё просто, оно одинаковое. А когда Product Owner или другой там Engineering Manager решает, что требуется уже выходить в prod, а-а мы, а делаем сборку, и сборка здесь, э, происходит немножко интересней. Аа деплоим мы не микросервисы, а мы деплоим Snapshot Manifest. Конечно, можно деплоить микросервисы отдельно, но дело в том, что тестировали мы ведь особую сборку. Нет, демо не отсутствует. Демо присутствует, просто диаграмма такая вот. А-а, на самом деле вполне себе можно в Kanban делать демо, а другое дело, что это нерегулярное событие. Вот. А получить обратную связь. А в конце концов можно делать демо в каждом случае при релизе, если мы работаем крупными фичами и Kanban строится по концепции постановки проблемы, нежели задачи, да? То есть, грубо говоря, я как кто-то там хочу сделать что-нибудь, да? А вот уже как мы это делаем, это решает команда. И тогда обычно задачи становятся большими. И команда берёт и реализует эту задачу крупненькую и показывает, как она решала. Вот. А нет, это не Scrum. А в Scrum точно так же можно использовать задачи. Если вы посмотрите Scrum Guide, у него нету понятия user story, там Product Item. Вот. Ну не суть, короче, это мы немножко в другую сторону уходим. Вот.
А деплоймент у нас здесь идёт того набора микросервисов, который мы оттестировали. Это довольно интересный ход вперёд, потому что до этого я видел концепцию, что между, а, стабилизацией микросервиса и стабилизацией всей сборки есть дополнительный этап. То есть мы можем оттестировать отдельный микросервис в стабильной среде других микросервисов, а потом уже его промоутить куда-нибудь. А здесь в этом случае существует дополнительный этап тестирования End-to-End или ещё какой-нибудь смок-тестирование, но я предложил в этой концепции после демо всегда тестировать результат тестирования, выражать вот в этой штуковину и деплоить её.
А что это такое? А, ну нет, давайте сначала по-другому говорим. А, собственно, в чём разница? А-а, дело в том, что в Gitflow у нас более-менее симметричные пайплайны. Здесь можете всё скопировать. Одни оперируют ветками и готовятся к релизу в бронче. В то время как в Trunk Based Development у нас один пайплайн в dev, а в stage другой, оперирует больше тегами. Теги, напомню, это те же ветки, только без возможности делать цепочки. Git'у на самом деле пофиг. И а как и любой ветке - это всего лишь указатель, который держит. А вы можете это всегда проверить. Если вы дропнете ветку, но у вас в этой веточке будет тег, то она дропнется ровно до тега.
А по Gitflow у нас QA не принимает никакого участия. А в Trunk Based Development то, что мы делали, мы, а, давали возможность QA выбирать ту версию из того тега, который они хотят потестировать. А, соответственно, в каждой версии было понятно, какой функционал сделан. Они переключались между ними и тестировали. Там готово одно, тут готово другое.
Аа, собственно, что такое Snapshot Manifest? А-а, очень хорошо иметь, а-а, несмотря на то, что как бы мы отдельно все деплоимся и вообще такая независимость всего процесса. Нам никто в микросервисной архитектуре не говорил, каким образом должны проходить тестирование процессов, потому что аа если у вас тестирование приложения независимо от микросервисов, то у вас, скорее всего, не микросервисная архитектура, а так, так называемые, э, о, господи, SCM или короче какой-то есть такой другой подход, когда у нас, э, а каждый отдельный, каждая отдельная система, она имеет свой backend, frontend и базу. Вот там вы можете тестировать отдельно. А всё-таки микросервисы, они очень часто имеют общего клиента. Даже если этот клиент по микрофронтенду построен, а вряд ли вы сможете найти 100% такие флоу, которые вот только в одном поведении этого только один микросервис затрагивает. Это хорошо, что если затрагивает так, но у них нету такого прямо один к одному, один к одному связки клиентской части и бэковой. Поэтому вы всё-таки тестируете общую сборку. И я бы предложил здесь именно дать аа сборщик артефакт вот такой вот Snapshot Manifest.
Ну что он из себя представляет? Какая-то версия, допустим, да, можно назвать её не 2026, а можно назвать там primary, там, а мажорно-минорный там какой-нибудь билд, да, а описать сервисы, какие у нас сервисы есть, какие у них версии, какие у них имиджи есть, потому что мы же их все задеплоили и тестировали этот конкретный набор и вывели его на демо конкретный конкретный момент. Точно знаем, что всё стабильно. А Security на всякий случай. А Security мы обязательно обсудим чуть дальше в Security части. А всё, ничего сверхъестественного, это не какой-то формат, это не это не специальная вещь, которая кем-то специально понимается. Этот файл, по сути, содержит просто указание. Вот это всё вместе нужно деплоить. Но если вы видите, что при деплое у вас один из микросервисов он ту же самую версию содержит, ну, значит, вы его оставляете как есть. Все остальные, те, которых версия отличаются, они меняются. В этом случае вы можете откатывать, накатывать, делать всё остальное добро тем же самым макаром, что делалось бы по отдельности. А зато здесь точно знаете вы, а какая версия есть, а где это очень хорошо помогает. Здесь по какой-то причине, не в нашем примере, да, а client profile service был показан, но а продукт решил его не деплоить. Ну, по причине того, что там, допустим, подождём, пока не будем выводить дальше. А дождались а других микросервисов, да? А, да, может, скорее всего. А другое дело, что здесь я рассматриваю Snapshot Manifest как артефакт всей сборки, да. Вот. А, а, допустим, мы ждём, когда client service у нас тоже обновится. После того, как мы сделали демо client сервиса, у нас тоже собрался Snapshot Manifest, и мы правда и после чего, естественно, у нас будут выходить в prod сразу два.
Операционная модель. Мы разобрали аа основную идею того, когда там триггеры, какие у нас релизы, какие у нас артефакты. Но а давайте теперь окунёмся больше в техническую часть физическую самого CD процесса. Многие люди читают ICD как аббревиатуру из четырёх букв, хотя на самом деле, как я в начале говорил, две вещи разные. И если помните, на тех диаграммах, которые я показывал, я даже там их разделяю. Аа а если копнуть ещё глубже, то вообще у них, э, исполнение совершенно по-разному выглядит, несмотря на то, что и то, и другое - это CI/CD пайплайн.
А давайте на Continuous Integration. А-а, ну, в первую очередь, как бы, в основном, мы видим это так. А, у нас есть какая-то репа, у нас есть раннеры, у нас есть триггер, э, туда идёт код, э, мы его, значит, задеплоили, точнее, как-то прогнали всякие линтеры и так далее, пошли, а, ну да, реагируем на разные фичи, dev, release, master, а, developer что-то там коммитит, э, всё происходит. А, да, у нас есть различные моменты, когда это делается. Либо там merge request, либо post merge, когда мы уже сделали его. При этом пайплайны все отличаются, очевидно, потому что, например, если мы хотим, например, сделать quality, а, мягким, аа, например, по количеству тестов покрытия, есть одна небольшая хитрость. Если же вы сделаете, например, жёсткий, а-а, жёсткую проверку на процент покрытия кода, у вас сразу возникает очень неприятный момент, который все почему-то думают, что это о'кей. Аа момент такой, что каждый merge request, который хочет прийти в dev, обязан обязан иметь а покрытие тестами. В чём проблема? Проблема в том, что такой подход, а, конфликтует с best practices пулреквестов, такими как атомарные коммиты и также принципом Continuous Integration. А принцип Continuous Integration вам не говорил, что вы обязаны покрыть код тестами ни разу. Он говорит обратно, что вам ваш код должен попасть как можно быстрее. Аа это часто приводит к тому, что вы можете распараллелить задачу между кучей разработчиков и стараться экспериментировать и находить решение, а и потом его покрывать тестом. Да, вы можете пойти в Trunk Based Development, да, это Test Driven Development и сначала написать тест. Но это также значит, что вы сначала напишете тесты непонятные и дальше будете куда ставить код. Никто не говорит, что тот, который код вы написали, что весь тот код, который вы написали, он будет интегрирован в тест. Хорошо, если будет, но мы же говорим про команды, не принадлежащие фэндому. Это такой вопрос, потому что люди, с которые работают с нами, это не идеальные разработчики, у которых всё сложилось. Ээ мы работаем с обычными людьми, не с супергероями, которые попали в эту замечательную пятёрку. Вот где всё работает хорошо, а у нас всё работает так, как получается. Поэтому мало ли что хотите, можете Quality Gate на тесты поставить. Наконец релизной ветки или на отведение релизной ветки у вас всё свалится, потому что тестов недостаточно, а деплой будет пока временно, например, меньше. Сюда же отходят различные дополнительные тесты, которые, например, performance. Зачем вам гонять их каждый раз? Вы можете их а под конец релизной ветки точно так же.
А чего нам ещё здесь не хватает? Нам не хватает, э, локального репозитория, а-а, которые мы можем себе скачивать, ээ, всякие разные штучки. А у нас же ещё есть собственные библиотеки, которые мы туда хотим класть, да? А ещё у нас должна быть своя часть, куда мы кладём всё: бэкенд подписанный, все бандлы, манифест и так далее. А сборочки мобильные и snapshot manifest file. Тоже артефакт же. Мы всё должны это класть. И вот по-хорошему в Инфре лучше эти штуки разделять, потому что если первая а хранит external библиотеки и она а доступна для, скажем так, записи извне и менеджерится какими-то людьми, которые вот туда вот кладут библиотечки внешне, да, а может быть здесь настроено скачиванием, да, ээ то здесь вещь должна быть абсолютно закрытая. Максимально запечатанно всем, чем только можно и проверяемое.
А, да, это можно использовать как руководство действия, либо поругать меня, и я тогда, возможно, улучшу эту диаграмму, и через полгодика выйдет новая версия этого прекрасного доклада. Что с Continuous Delivery? А она отдельно идёт. А я помню, был несколько раз у меня разговор о том, почему же нужно это тело отделять, да? Дело в том, что а эта штуковина, она ничего не собирает, она берёт вот эти вот защищённые, проверенные а артефакты и деплоит. А сюда также идёт взаимодействие с, а, ЕК репозитория ЕАС. Аа у нас здесь же идёт работа с секретами. В моём случае это был Волт, который туда девоскладывали секретики. Это всё через а кубернатовские секреты шло в Run. Вот. Аа, соответственно триггер у нас был либо productр для прода, да, либо, э, триггер внешний аа по процессам CI. Всё, естественно, какая-то зеркабеледи часть была, потому что нам всё-таки надо всё это дело смотреть и реагировать.
А что здесь интересно? Вот эта вот штука сидишная, она настолько сильно изолирована и закрыта, что мне пришлось несколько раз разработчикам объяснять, что а никакие доступы к Argocd у вас не должны быть. Вот максимум, что сюда посмотрите, пожалуйста. Здесь у вас быть не должно очень сильно, потому что это этот компонент, он самый опасный из всех. Почему? Спойлеры. А будем смотреть об этом чуть дальше в разделе про Security. А Argoс, почему не Gitlab Runner? А дело в том, что он находится внутри, а кубера. И если это был бы Gitlab CI Runner, то он внешний. Ему требовалось бы, а выдавать права, а это очень плохо. А это значит, что кто-то к нам снаружи с Кубера, а ему открыты ворота. Чтобы избежать этого, лучше пользоваться, чтобы он пулил из репы, чтобы он брал всё, что нужно с из репозиториев артефактов, вместо того, чтобы делать пуш снаружи. Это один из таких небольших моментов, который показывает, как у нас отличается а доступность нашего главного уязвимого узла, а непосредственно кластера исполняемого.
Вот и мы подошли к этой замечательной части, по которой мне задавали вопрос. Берегитесь. Здесь, в принципе, очень много всего понятного, но почему-то люди не применяют эти принципы для сборки. CCD - это ещё одна поверхность атаки. Аэ поверхность атаки - это термин из информационной безопасности. Под ней принимается любой компонент, элемент, что угодно, который можно поломать. И мы знаем, что там, допустим, гитве, сервисы, база данных, снапшоты или что-то ещё является поверхностью атаки, да, но CCD - это не менее уязвимая вещь, а потому что а здесь работают люди, здесь работают компоненты, часто мы можем даже встретить эпатии какие-то системы, да, а наверняка кто-то из вас пользовался cloud Sonarм, например. А, то есть вы видите, да, у нас идёт внешняя интеграция. А представьте себе, если вас кто-то перехватил, вы идёте на настоящий клс с son и ваш код утекает наружу. Аэ, всё, дальше можно вас очень хорошо вычислять, где у вас слабые места.
Ну, давайте посмотрим, а что из себя представляет а поверхность атаки CCD. Она, на самом деле, не такая простая. Я беру в качестве примера аа то решение, которое было у меня. Это в Кубере, да, с Argocd, но предположим, что здесь это просто deployment engine. У нас есть куча разных репозиториев, у нас есть оркестраторы, есть раннеры. А что интересно, да, вот и внешне интеграции, понятно. Здесь вот поставщики dependency, если вдруг вы разработчик, задавались вопрос: "Нафига вам локальный маган?" Вот зачем, чтобы вот эту вещь закрыть? А иначе будут вас атаковать и ещё и тут. Плюс у вас контроля больше над ним. А права, конечно же, да, у вас точно также могут, например, ломать через логи, потому что взламывая логи, злоумышленник может получить больше информации, да? Ну и понятно, да, если куда-то где-то что-то влезли, всегда это пойдёт вот вот в эту часть, да, она не защищена, потому что вот этот вот товарищ, который даже рядом лежит, который забирает вот отсюда артефакты, он может получить, а, и передать сюда что-нибудь вредоносное.
А, а что именно он может передать? А угрозы бывают вообще, а, такие известные, стандартные и при этом почему-то не учитывались раньше этим. А мы можем просто поменять код не авторизованно. Таким образом, ну, по тем же самым причинам, какие это в обычном софте есть, просто взломали доступ к коду, получили, а, произошёл тиity у этого, у разработчика вытащили, да, они авторизованно поменяли код, поменяли код инфраструкчего кода и репосто и всё. А мы, собственно, секреты спёрли, да? А мы увеличили свои эти привилегии тоже, а сделали код, который будет исполняться вредоносный, лазить куда-нибудь наружу, компоненты интегрировать плохие. А изменение артефактов мы можем не обязательно непосредственно менять код, можно просто попробовать взломать репозиторий, а, и там уже подменить сами файлы. А артефакт будет выглядеть так же, он будет вести себя так же, только будет сожжать что-то плохое. А dependent abuse - это как раз связанное с внешними зависимости, они тоже могут быть подвержены атаки. А неавторизованный деплоймент, да, как ни странно, если у вас есть доступ к сидишке, этот CD может строить вам веселоху. А, ну и, конечно же, любые попытки скрыть свои собственные следы в логе, а также являются одним из вариантов угроз.
А, и, как вы понимаете, это такая матрица. А для каждого из вариантов угроз может бить по разным компонентам. А в том числе вот там по внешнему украчищ, да, мы понимаем, что этот риск вообще не под нашим контролем, но на самом деле а сделать очень тихую атаку, которая заключается в темперинге, в изменении артефактов во внешнем репозитории вообще не составляет никакого труда. А точнее, представить себе это можно. Хотя, честно говоря, я, если бы меня спросили об этом года четыре назад, я бы, конечно, сказал: "Ну, что-то странное вы говорите, тут же всё проверено". Вот. На самом деле нет.
А чего у нас дальше-то? А сценарий, так как э в принципе очень много разных вариантов, давайте просто посмотрим на вариант, когда мы получили доступ неаторизованный к CCD раннерам. Почему мы можем это сделать? Почему такое может случиться? Да, потому что злоумышленник получил, например, креды аа бывшего Девопса, Devops может быть бывший. Вы его там не удалили из своей компании, а у него есть все доступа. А ваши машинки, они ранятся, например, в каком-нибудь облаке, который не под VPN, а там зашёл, если знаешь, URL и или вперёд, у вас всё уже есть. А доступ к кранерам прошёл. Всё, у вас на продакшене или на каком-нибудь стейдже что-нибудьте крутится то, что не нужно. Может быть интереснее, если вы в Source залезли, да, можно закоммитить что-нибудь такое, а этот коммит, соответственно, содержит вредоносный код. Он, например, а отсылает какие-нибудь небольшие логи во внешнюю среду. Также пошло всё это в деплоймент и крутится ваш на вашем продакшене уже что-то не то, что вам нужно.
А, как я говорил, у вас может быть библиотека попасть в н central не та. То есть это тихонечку всё делается, да, они там всё это дело сканируют, но если эта атака вызвана другими такими какими-нибудь нестандартными ситуациями, там можно, например, попробовать а диза какой-нибудь вызвать на мане там через восстановление снапшотов сновить что-то не то. Короче, вариантов туда попасть много, они, конечно, очень маловероятные, но такое существует. подтянули эту плохую зависимость сюда, да, не проверили её, что она оттуда откуда надо. Пошло опять же дальше. А вот здесь, если у вас в инфраструк через код залезли, то у вас вирусякие и плохие программы полезли прямо сразу же а ваш продакшн массово могут залезть вообще в любое место, скажем, проментирована будет вся среда. А поэтому этот репозиторий самый страшный для атак.
А, ну и самое клёвое, когда у вас кто-то пробрался и вашу модель, а доступ ваш полисе изменил без вашего желания. Может быть, он просто зашёл в среду и смог добраться именно до файлов. А защититься, конечно, от этого можно. А если у вас полисе из Екоcode, а любой код можно тестировать. А, собственно, что нужно делать, чтобы от этого защититься? Ну, а, во-первых, конечно же, listст privilege. А здесь очень важно, потому что вот, например, тот же самый CD ничего не может писать в репозитории, а этот, господи, сий-ка может только писать. Вот. И читает она там тоже только из ограниченного числа. А, конечно же, нужно защищать сам флоу, чтобы не было доступа к нему никакого снаружи. А изолировать различные пайплайны а друг от друга, там вся от CD или же это фичев про DEF. А обязательно нужно защищать все креты и секреты. Это солтом с CMS, а, KMS и этот, господи, SecretТменеджер. Аа очень интересная штука, мне нравится, это проверка самих артефактов, чтобы у нас точно всё, что вы собрали, всё, что вы, а, имели снаружи, чтобы их можно было подписать, там, а, не очевидно было, но, короче, сийка подписывает эти артефакты все, а сидишка сверяет, и мы тогда никогда не задеплом. Ну, точнее, вероятность снижается, да? мы не задеплоим то, что неверифицировано. Вот. А мы, конечно же, обязательно смотрим на всякие логи, реагируем на алерты и так далее. Конечно, очевидно, это редко кто делает, но надо надо делать правый кдку.
А-а, это часть, связанная с Delivy. Тут мы, в принципе, как будем касаться достаточно известных вещей. Ничего тут сейчас я вам, ну, не скажу. Я же, когда это делал, я задавал себе вопросы. То есть для меня как архитектора важнее не методы, а то, как их выбрать. Ну и для меня были следующие вопросы самыми важными, которые мне позволяли выбрать один из трёх стандартных подходов. А какой у нас даунтайм, да? Потому что, ну, за за короткий даунтайм надо платить. А могут ли работать версии одновременно? Это вообще суперстрашный вопрос, особенно для архитектора, потому что, особенно в микросервисах монолитах, как правило, типа нет, нельзя там, типа, потому что там и схемы несовместимы, и API, хотя тоже можно всё сделать. А вот если два микросервиса работают одновременно над схемой, ну, некоторые могут работать, некоторые нет. А насколько мы должны уметь откапываться, да? Потому что, ну, не все не все решения требуют быстрого откапы. А какие у нас вообще, в принципе, инструменты на обзербалити, хлсчеки и так далее? Это критически важно влияет на канареечный тепломент. Вот если у нас этого нет, то будет довольно тяжело. А, конечно, бюджет, потому что если мы не готовы, если мы готовы экономить на инфраструктуре, то, наверное, а тот же самый Greгenб у нас не подойдёт. И, конечно же, где у нас риск, а в какой части? А может быть нам нужно больше время там на тестирование или что-то ещё, поэтому мы готовимся и смотрим какие-то троиранны и так далее. Может быть, как раз конречно здесь сработает лучше.
А, собственно, три стандартных. Мы, конечно, alles с ней не рассматриваем, потому что он немножко устарел. Вот, э, rolling update. А, практичный, дешёвый. простой также просто ломается, как всё остальное. Ничего у вас здесь хорошего не будет. Например, нету быстрого отката и а у вас не будет быстрого переключения, будет у вас не будет даунтайма. С другой стороны, вам придётся жить с двумя версиями запущенными. Возможно, какие-то сервисы будут недоступны, да. А с Blue Green деплойментом, если вдруг кто не знал, это вариант, когда у вас есть фактически две параллельных инфраструктуры. А, и идёт переключение. Единственное, что меня в нём всегда смущало - это переключение базы данных. А потому что там есть ещё момент, когда его когда базу нужно патчить, прогонять все эти, а, сQэльки миграционные. И в этот момент у вас как бы нужно всё-таки стопать работу. Вот это меня всегда вызывало самые большие вопросы аа в этом варианте. Ну и канареечный деплоймент тоже штука, которая заставляет вам одновременно на базе жить две версией. И она нужна не всем. Это часто битусишные приложения. И знаете, почему так так очень классно это всегда работает? Нам очень сильно рекламировали в своё время этот конеречный диплом, но оказалось, что он нужен только темпаниям, которые пришли к успеху, то есть у которых массовый пользователь, и им нужно очень внимательно подходить к тому, как они меняют свой интерфейс и смотрят на него. А далеко не всем решениям требуется реально идти в свою аудиторию и смотреть, как вот у меня тут до записи спрашивали, что там, как был ли опыт там с казином каким-нибудь, да? Ну вот там, наверное, почти наверняка. А банковское приложение тоже. А почему? Потому что зона, допустим, гостевая в банковском приложении - это ваше начало на воронку продаж. И то, как быстро пользователь, получив приложение, пойдёт и заведёт какой-нибудь продукт приложение, там карточку откроет, счёт, депозит, это ваш хлеб. Поэтому там, допустим, канаречно имеет смысл. А с другой стороны, возможно, там не совсем плоймент, возможно, там игра с конфигурациями, но так или иначе, а такие вот стратегии основные. Э вроде бы у нас больше ничего такого специфического не придумали. Пишите в чат, пишите в комментарии, пожалуйста, если вы не согласны, если у вас есть свои варианты.
А миграция базы. Ну, нельзя пройти мимо этой штуки, потому что C - это обычно про запускаемые сервисы. А баз данных у нас как-то обычно обижают. А есть а стандартный режим, когда мы автоматически, а апдейтим базу во время пайплайнов. Аэ, здесь цель понятная, continuous integration, всё такое, чтобы всё быстрее работало. Риски большие, но скорее так высокие риски в плане пробилити, да, а севериity небольшое, потому что у нас blast rради, он касается исключительно девелопмента, то время как продакш такой недопустимый. Для продакшена нужно делать контролируемый а сценарий, когда у нас это всё проходит только специальные апру. Это опять же, если вы достаточно зрелая компания и у вас есть такие workflow, плейбуки на апгрейд, вот это все дела, себе тоже прописали, то тогда да, а стоит делать так. Я видел людей отчаянных, которые запускали Liquid Base всегда в базовом режиме, даже не автоматическом, вот этом, да, они его ставили на запуск приложения. Этим людям очень тяжело запускать приложение. То есть они на старте прямо умирают. При апгрейде в продакшене там происходит просто кошмар. Вот поэтому здесь именно стоит, а выносить это отдельно, не из запуска. И, более того, лучше какой-то пролкей делать. Кроме того, это как раз-таки более контролируемый процесс. Вы можете и откатить, и накатить, и поправить. Всё это у вас нут.
Откат а является неотъемлемой частью, конечно же, любой выкладки, потому что а нам нужно задать для себя сначала вопрос. Ну, как всегда, без вопросов нельзя выбрать решение. А что для нас откат, да, потому что не всегда, допустим, мы можем сказать, что мы, допустим, откатываем базу, не откатываем базу, может, какие-то сервисы откатятся, другие нет. Может быть, у нас кроме баз данных есть и множество других компонентов, которые также апгрейдятся, но нам, в принципе, не является это критичным. Аа вот а здесь это обязательно все нужно спросить. А какие сигналы, да, что происходит? Потому что в наше время автоматизация - это всё. А а если не автоматизировать ролбек, то ну его надо автоматизировать, наверное, из каких-то сигналов, с алёртов или ещё чего-то. Можно, конечно, всегда сидеть, смотреть влоги, как оно там работает, и ролбочить, если нет, но никому, наверное, уже в наше время не хочется это делать. А, да, конечно, здесь могут быть варианты гибридные, вручную, но понимать, кто это делает, тоже стоит. А это зависит от того, какая у вас команда, какие-то ресурсы и так далее. Организационная структура. Аа, и как бы вот расширяя первый вопрос, да, надо понимать, что мы не отменяем, потому что, а, могут быть мажорные какие-то изменения в базе данных, могут быть минорные, аа могут быть, э, ну, такие отчайные попытки что-то поменять. Вот лбек не всё должен менять, не всё должен откатывать. А, да, собственно, ответив на эти вопросы, мы можем выбрать стратегию, её прописать. Каких-то прям, а, чётких, единственных вариантов, как с самим, а, deyment strategy, здесь, наверное, нет. А просто это должна быть инструкция. А есть такая назвал playbook. Вот его тут как раз надо писать. Что делать? А, либо писать скрипты, соответственно, если это автоматическая бонус.
А-а, что не вошло, а-а, потому что любая методология, она очень прекрасна на бумаге линейно и так далее, но есть вещи, которые не помещаются в основном плане. Что стоит ещё писать? Аа в этом документе можно много чего писать, на самом деле, но я вот сейчас перечислю отдельные пункты, которые стоит упомянуть. А, конечно же, правила именования. А есть много вариантов, и это как всегда религиозные войны о том, как надо правильно именовать. Выберите свой вариант, да, по номеру года, месяца, минор. У меня очень часто там нравилось смотреть на вытянутые лица девопсов или разработчиков, которые видели в третьем числе, там build number, например, автоматически генерированный C. То есть это всё лучше сразу выставлять, потому что там уникальность версии и её идентификатор - это ключевая вещь. А, естественно, стоит, э, прописать различия для эхо, потому что те диаграммы, которые вы видели там, это всё-таки, потому что он более-менее понятный, он крутится где-то, но у нас крутиться может не толькоэнд, но ещё и фронт, и мобилка. И мобилка, естественно, там, а, какой-нибудь, ээ, Harmony OS пятый, если вы вдруг сталкивались, да, он там по-своему деплоится, iOS со всеми так, как Android, ну, и так далее. Вот. То есть это всё тоже тоже стоит учитывать и прописывать, особенно если у вас приложение не выкладывается какие-то стандартные места. Вот. Или, например, там Microfonнд. В одном из проектов у нас был микрофронтенд, который выкладывался вообще в другой в другое место. И там, грубо говоря, много-много разных виндаров. Они, каждый из виндаров делал свою часть микрофронтенда, а заказчик, его команда, она делала shшел. И у нас там были всякие приколы из сер, как правильно тестировать с с этим с авторизацией, потому что авторизационный модуль, естественно, отдельно, как а у нас там все эти IP и gitвеи защищались и так далее и тому подобное, то есть здесь а всё может быть очень-очень сложно.
А, конечно же, лучше выписать все пайплайны, написать, какие у них есть свойства, просто, чтобы был реестр и было всё понятно, то мало ли что там кто-нибудь замот. А, очень хорошо упомянуть различные дополнительные проверки. Ээ, Supline Chain Assessment, а это, короче, новая штука. Она как раз-таки проверяет, а то, что у вас все зависимости, они те, за кого себя продают, аа защитит вас от таких, а, мм, зловредного кода, э, который был кем-то там заинжектирован. А, конечно, стоит самим ещё что-то проверять. Например, вот это вот то, что я говорил на уровне CD, проверять его подписанность. А как управлять секретами, да? А потому что это можно реально делать очень по-разному. Выберите свой вариант, пропишите, чтобы было сразу чётко всем понятно. А потому что, ну, DEOPS может делать что угодно, а архитектор тот, который человек, который за него потом. Оп. И наблюдаемость ICD. Это артефакты не не связанные непосредственно с ICD, но связка туда должна быть. А потом будут вопросы: "Адайте мне, пожалуйста, доступ к Cargoc, я хочу логи посмотреть". Нет, вы посмотрите логи в графане, вы посмотрите логи где-нибудь в cloudче и так далее. То есть стоит это дело тоже прописать, потому что, ну, давайте честно, надо писать ADR от начала до конца, потому что иначе ADR, как меня подспрашивали, исполнять не будут. А так что просто подумайте, кто будет это дело читать, и зададите, задайте себе вопросы. А что им ещё понадобится, чтобы сделать свою работу? Спасибо вам большое. А какие ещё темы у нас есть? Аэ, ну, конечно же, сегодня мы посмотрели тему с CICD. А есть много других разных тем, часть из которых мы здесь уже видели, часть из которых с удовольствием расскажу вам. А, и есть ещё много других тем. Скоро этот слайд у меня лопнет от того, что можно рассказать. В общем, пишите, а, пишите на платформу, пишите в комментариях, чего бы вы хотели услышать, и мы обязательно подготовимся. А пока вы думаете над вопросами, вот вам шпаргалка с ключевыми тезисами сегодняшнего доклада. Можете с вопросами или писать их в чат. Кого вы думаете, я посмотрю, что там мне задавали? Угу. Вот. А-а, с чего начать внедрение CICD? Аа, знаете, короче, CCD, а, всегда это такая вещь долгая, она там типа строится порядка там полутора-двух месяцев, может быть, даже до трёх месяцев доходит в зависимости от того, где вы сидите в Cloudдепре. Опремощё вообще может быть долго. Я помню у нас все для Оркла, Oracle Cloud Infastructure тоже был достаточно долгим, потому что а мы там видеохостинг делали, короче. То есть это очень сложная штука. А начинать надо, конечно, с автоматической сборки версии, то есть сийки. Сделайте у себя вот эту часть для дева, и будет вам счастье, потому что надо хотя бы, чтобы тесты гнались, да? Лучше сделать так, чтобы у вас хотя бы просто тупо тесты собирались, а дальше делайтемент в де. А после депломентов def обычно там смотрится сейчас я увидел вопрос, да, точнее комментарий. А после дипломентов def лучше заняться такой вот санацией и строительством нексусов всех всех этих, господи, репозиториев regдстре артефакторе. А потому что если у вас хорошая разработка, то у вас, скорее всего, будут там и внутренние библиотеки, и микросервисы какие-то. И вы, наверное, хотите себе затащить dependenнcy, чтобы тоже их можно было сканить. А-а, подпись стоит на этом этапе сделать, но можно и отложить. Подписание бери, чтобы можно было дифицировать. Параллельно можно заниматься строительством стейджа, но строительством стейджа стоит заниматься только тогда, когда вы уже враформе или в чём-нибудь ещё а сделали образ вашего деф окружения. Архитектор параллельно с этим, естественно, описывает архитектуру детст, но, естественно, стоит заранее закладываться. Причём там в продакшене какие есть отличия, чтобы инфраструктура была более-менее стандартизирована. Как только у вас stage age задеплом, э, и все триггеры есть, а можно дальше смотреть, а в сторону различных дополнительных тест этих тестов, типа supply chain, sonor для саста, может быть, дополнительные какие-то инструменты длямика. секрити тестинга, что-то такое. То есть это туда лучше идти. Ну и последнее, конечно, production. Он обычно связан с тем, что у вас появляются очень дорогие компоненты, и вы их деплоите только перед непосредственным выходом в эксплуатацию. Есть, конечно, всякие приколы серии, там preproduc, UAT, есть другиементы, типа demo envirймен, куда, допустим, если у вас платформа или что-то такое, специально деплотся версии для того, чтобы демонстрировать новым потенциальным клиентам вашей платформе. То есть если у вас, например, тот же демо есть, то это чаще всего завязано на релизный цикл. Поэтому DevOps получает задачу сделать эту штуку как можно быстрее. А там к архитектору приходят всякие разные вопросы и серии: "А как сделать вам фактически продакш рейти?" Э, это продакшн рейти тема environment а-а защищённым, да? А ещё там такое бывает, что им пользоваться уже реальные пользователи, они настоящие програмисты, поэтому их надо защищать. Вот. Ну, это фактически я вам всё рассказал на этот вопрос. Я надеюсь, ответ получен. А как автоматизировать соблюдение? Автоматизировать нельзя, потому что нельзя автоматизировать людей. А что можно сделать? Аа, ну - это всё-таки спецификация. А у нас, э, в проектах, в которых я обычно участвую, у нас, когда задача ставится команде разработки, там обязательно есть, а, связь, связанная с функциональными требованиями и диаром, который их сопровождают. То есть, по сути, разработчики получают три артефакта. Это а спека, а это дизайны идиарка от архитектора. Ну или надпись, что ничего там делать не надо. Вот если же эта идиарка касается технических вещей, то, наверное, всё-таки это входной входная постановочная задача для ГОПС. Вот поэтому, ну, не исполнять их, э, нельзя, если вы их поставили для исполнения. Вот. Аэ, другое дело, что вам придётся трекать, что из него было выполнено, а что нет, и какие хвосты и какие изменения вы вносили, но это уже отдельная вещь. Так, аа у меня ещё был вопрос, как адаптировать искусст AI инструмент. Это немножко отдельная вещь. Давайте я в конце про неё отвечу. А в докладе не упоминались темплейты для сеID. А почему не упоминались? Потому что пайплайны строения - это в сторону Infrastrct код. Э, и когда у вас он один, то вам приклеить не нужен. Если у нас микросервисы, как у меня диаграм, то вам обязательно это надо, потому что, а, нельзя писать отдельные мм нельзя писать templatйт, точнее, сорри, нельзя писать пайплайны каждый раз в руки, а, а иначе вы ошибётесь где-нибудь и будет всё плохо. А обязательно это всё нужно дело брать из темплейтов и автоматизировать их создание, а иначе будет плохо. А, да, я это не описал. У меня вдиарке этого не было, но я обязательно подумаю, как это лучше сделать. А-а, как вы определяете наиболее критическую область? То есть, например, до некоторого времени никто не знал, что а кого-нибудь шаихулуд, да, прекрасно, может оказаться пенсией, а ломать уже ломать уже на этапе билда. Как это предугадать? А вообще предугадать это довольно сложно, если не запускать какие-то драйраны. А для этого, кстати говоря, и существуют всякие там green blue деплойменты или женорейчные. А у нас, например, а была библиотечка на Айосе Markда, которая работала в девелопе, но не работала на билде. Аа в эмуляторах она, по-моему, даже работала, а на реальном устройстве ломалась. И мы узнали только на реальном устройстве. То есть, а, ответ, а, стараться приводить, а, среду исполнения тестирования наиболее близко к эксплуатации. Это ключевой момент. Если что, э, за примером ходить далеко не надо. Есть, кто работал в Джаве, есть такая классная библиотека H2, а для тестирования так для того, чтобы иметь базу данных in memory. Так вот, прикол в том, что у H2 SQL он отличается от SQL погрестного, и он ведёт себя совсем не так. И далеко не всё нужно нач потестировать, иногда он ведёт себя иначе, не так, как реальный постав. То есть просто нужно делать наиболее близкие к реальной среде исполнения. А предугадать это нельзя, а просто нужно именно сделать такую меру, как прогон на реальном, на реальной середине. А так, есть ещё какие-то вопросы? Если нет, то я на фановый вопрос отвечу про инструмент аа и я инструмент процессинга. А там а спрашивали про специальный специфический проект, котором у нас очень много хранимок. Аа, честно, всегда можно запускать такого ассистента для попытки анализировать непосредственно эти хранимки, чтобы составить по ним какой-то репозиторий, какую-то базу знаний, да? А если его периодически выгружать и хронимки куда-нибудь вреч бей ставить, обучать, если у вас хотите прямо совсем заморочиться, да, либо же а стараться именно выгружать его в какой-нибудь там соответствующий с с кодированием, а, копайт или что-нибудь такое. А для тестировщика, соответственно, все мм ронинки можно анализировать на обтвление. а комбинировать, делать из них тестовые сценарии, а для аналитика делатьреверс инжениринг требования, а потому что, ну, описывать самому руками такие вещи сложно будет. А мне кажется, как-то так. Надеюсь, я ответил на вопрос. А если вы не хотите писать в чат, но у вас есть желание что-нибудь сказать, пожалуйста, впрыгивайте и задавайте вопрос. Подождём минутку. Прошло чуть меньше минутки. Я так понимаю, что желающих нет. Аэ, большое спасибо всем за сегодняшний вечер. Подписывайтесь на нас, приходите, пишите комментарии. Будем рады встретиться снова. >> Спасибо большое, Андрей. Всем доброго вечера. До новых встреч. Пока-пока. >> Что там запись останавливается? А >> мы сейчас сейчас я остановлю, да? >> Угу. Да, всем спасибо. Ох, ну что, получилось секюрити часть рассказать, как их просили? >> Ну, надеюсь, >> да. Ээ, ну, потому что был этот запрос в комментах на Ютубе тогда, я тебе скидывала, который >> А почему? Потому что на самом деле как бы ничего удивительного-то нет, потому что те же самые системы, их точно также можно взламывать, как любой другой софт. >> Вот. Yeah.