Лекция об основных процессах команды Digital Suite: аналитика, разработка, тестирование, релизы и вывод функционала в продакшен.
Key Takeaways
- Стримовая организация позволяет автономно развивать бизнес-направления с собственными командами.
- Аналитики играют ключевую роль в коммуникации между продуктом и разработкой, обеспечивая четкое понимание требований.
- Тимлиды обеспечивают качество кода, архитектурную стабильность и обучение команды.
- Процессы релизов и вывода функционала в продакшен строго регламентированы для минимизации рисков.
- Тестирование, включая нагрузочное, и devops критичны для поддержания стабильности и производительности продукта.
What the video covers
- Обзор структуры и эволюции команды Digital Suite с 2016 года, переход на стримовую организацию.
- Описание ключевых ролей в команде: аналитики, тимлиды, backend и frontend разработчики, тестировщики, devops.
- Подробное рассмотрение процесса аналитики: сбор требований, взаимодействие с продуктовыми владельцами, подготовка архитектурных документов.
- Обсуждение процессов разработки, review кода, тестирования и нагрузочного тестирования.
- Регламенты спринтов и релизов, типы релизов и их подготовка.
- Процедуры вывода функционала в продакшен, вопросы обратной совместимости и управления доработками.
- Роль devops и нагрузочных тестировщиков в обеспечении стабильности и производительности продукта.
- Важность синхронизации процессов между разными стримами и командами для эффективной работы.
- Упоминание поддержки контентных и других смежных подразделений, участвующих в разработке и релизах.
- Планы на дальнейшее углубленное раскрытие отдельных процессов по обратной связи от слушателей.
Chapters
- 00:00Введение и цели лекции
- 04:48Структура и эволюция команды
- 09:48Роли в команде разработки
- 14:48Процесс аналитики и взаимодействие с продуктом
- 24:39Обзор процессов разработки и тестирования
- 29:02Нагрузочное тестирование и devops
- 49:23Регламенты спринтов и релизов
- 54:38Процедуры подготовки и вывода релизов в продакшен
Full Transcript — Download SRT & Markdown
Speaker A
Начнем. Значит, у нас 3-я лекция. Наверное, кто-то же с моего предыдущих, предыдущие были больше, наверное, по технике. Эта лекция решил сделать процессной. Здесь не супер подробно будет рассказано про каждый процесс нашей команды, нет, по верхам. Но зато после этого можете оставить там какой-то фидбэк, и про какие-то части мы расскажем более подробно, сделаем прям отдельный стриминг про это еще что-то. Значит, напомню, что этот курс лекций сделан для того, чтобы те люди, которые там чуть меньше погружены в технику и больше не погрузились, могли общаться с командой на одном языке и в целом для синхронизации. Потому что в разных стримах разные процессы, уже есть какие-то, где-то люди не знают про что-то. Вот, то есть синхронизировать. В частности, этот раз я попросил коллег помочь мне.
Speaker A
Вот здесь представлены ребята, которые помогли собственно сделать эту презентацию, за что им большое спасибо. О чем поговорим собственно после этого слайда? Кому не интересно, могут отключиться. Надеюсь, вам будет интересно. Первых поговорим, я расскажу, так как присутствую на проекте самого начала.
Speaker A
Расскажу чуть-чуть о том, какая у нас общая команда, какая была, какая стала, почему, про основные роли разработки, то за что отвечает. По каждому процессу пройдемся: аналитика, разработка, review, тестирование, нагрузочное тестирование, devops. Вот чуть-чуть поговорим про процессы.
Speaker A
Регламенты — это спринт и релизы, каким из боёв тип релизов, почему так произошло, что у нас есть типа релизов, их нужно запрашивать, всё, что не нравится продуктовому миру. А значит, про какие-то ещё процессы, релизная связана с релизом, как вообще непосредственно устанавливается релиз, как и подготовить номера для этого делаются. И дальше мы поговорим про вывод функционалов в продакшен.
Speaker A
То есть знаю, что когда мы сделали, разработали под функционал, его ещё нужно правильно вывести в продукт. Вот здесь мы немножко поговорим о только открывать доработки, про рубильники, про обратно совместимость, что это такое и почему она вызывает боль у пользователя, как мы с ней боремся, ну и так далее. Ну, поехали.
Speaker A
За окном был 2016 год, мы начали проект, у нас сформировалась монолитная команда. Не помню, сколько человек было, но это был такой после комбан. Вот, то есть мы что-то делали, потом к нам накапливали релизы и так далее. В какой-то момент мы поняли, что происходит конкуренция за ресурсы, очевидно. И потому что там, например, нужно такой функционал разработать, там какому-то духовному нужно что-то другое. Вот и началась комбанка ресурсов. Собственно, собрались мы в моём 2018 году, решили, что мы будем работать по храму, разделимся на стримы и будем разбивать витрины, так называемые.
Speaker A
Ну, то есть это бизнес-направления. Вот, как сейчас помню, появился у нас стрим CIS, это информация для Паши, у нас так назывался стрим сайт, вот который потом переименовался в сайт, появился продукт, появился, наверное, тогда ещё не было суда, появился интернет-магазин, там потом подъехал программ лояльности. Но и дальше начали стримы прибавляться.
Speaker A
Ки боятся, чем основная разница, безусловно, в том, что каждая команда — это автономная единица, которая имеет в себе backend-разработчиков, контент-разработчиков. На следующем слайде подробно поговорим. То есть в команде, ну, собственно, та стратегия она работает и по сей день. Периодически мы делаем, не так часто, фичи тем, до тус под конкретный проект является команда, и потом оно восходит снова по своим стримам. Например, нас сама регистрация, самая первая часть делалась именно в таком формате. Такое тоже практикуется.
Speaker A
Ну и про роли в команде. Безусловно, ролей куча, прошу никого не держаться. Я оставил только такие роли, именно которые работают в кипении разработки над фичей. Это в первую очередь аналитик. Почему перо чуть? Потому что это первая единица, до которой поступают требования, которая идёт работать задачами. Безусловно, это поступает требование от продукт оунера. А здесь я не указал, мы подразумеваем, кто умер, это такой флагман стрима.
Speaker A
Вот дальше у нас присутствуют в тех или иных стримах тимлиды разработки. У нас отдельно есть виды разработки backend, из земли для разработки frontend. Если тимлида нет в команде, стрим курирует какой-то разработчик, почти тимлид из другого стрима. Чем эти ребята занимаются? Они в целом задают направление, обучают новых сотрудников, проводят review, говорят, как делать правильно.
Speaker A
Архитектурная с ним можно посоветоваться как тестировщику, так аналитику, так и любому другому разработчику. То есть ребята, которые обеспечивают наш проект стабильностью с точки зрения того, чтобы поэту пять лет мы можем его сих пор легко дорабатывать. Нет никаких дебрей особо, ну, за исключением некоторых моментов. Вот этот в частности заслуга.
Speaker A
Дальше и безусловно есть работка, backend, frontend нашей команде. У нас нет столько разработчиков, точнее есть, но они скрывают своих потенциалов. Не вот на чем-то одном сосредоточились и разрабатывают. Значит, у нас есть стрим тестирование, где-то есть прям стримах, например, во флэте есть там Паша, который является блюдом тестирования, он привязан к стриму. Есть другой подход, когда есть там Андрей, допустим, даже они таки вне стримов, но тем не менее курируют ребят.
Speaker A
Безусловно, тестировщики, авто тестировщики, которые занимаются покрытием, дальше об этом подробно поговорим. Есть ВТО тестами, есть ребята как бы вне команд. На самом деле они так или иначе связаны с каким-то командами. Это devops и нагрузочные тестировщики, которые обеспечивают собственно всю техническую работу, связаны с выводом функционалов в продакшен, с нагрузкой и так далее.
Speaker A
Вот, ну безусловно есть ещё подразделения, которые активно участвуют в разработке или выводе в продакшен, например, отдел контента, copyright, ещё различные ребята, которые активно участвуют в функционале. Но вот команда среднестатистической разработки, стрим, так называемый, с ребята, которые принадлежат, присоединены к стримам, они выглядят именно так.
Speaker A
Процесс аналитики — самый сложный слайд для меня, почему? Потому что я сюда планировал разместить нашу диаграмму из мира, она никак не влезла ни на 1, ни на 2, и даже не на 3 слайда не смог уместить. Поэтому решил просто буллитами написать и сказать, чем занимается у вас аналитик. Важно отметить, что аналитики разных стенах и по-разному занимаются задачами, поэтому это нечто такое объединённое. Чем занимается плюс-минус?
Speaker A
Можно отметить, что у нас помимо аналитика есть и ведущие аналитики. Вот это те ребята, которые тоже обучают других ребят, помогают им с их задачами, делают какой-то экспресс-оценку, архитектурное видение, составляют в каких-то моментах, когда какая-то сложная фича. Вот мы поговорим про того обычного аналитика.
Speaker A
Значит, первое, что он делает, кстати, если кто-то захочет аналитиком, присутствующих на встрече поправить, смело врывайтесь, говорите. Значит, первое — это, может, поступают требования, ну, например, продуктовый или заказчик, да, там берёт за ней. Он изучает это требование, собирает вопросы, которые у него появились после изучения, идёт общаться с продуктовом, ну, в редких случаях сразу с заказчиком, а может быть и нередких, основных продуктов, и всё-таки решает с ним открытые вопросы, понимают вместе с ним, как это будет выглядеть интерфейс, если интерфейсная часть имеет место быть.
Speaker A
Вот зачем затем он изучает интеграцию, архитектуру. Там, кто не знает, у нас на проекте практически на каждом стриме присоединён архитектор. Язык digital — это человек, который также продукт, как аналитик, только начал ранее, значит, на раннем этапе. Вот и готовят некий документ, который называется ПАМ, так называется, дальнейшее архитектурное видение. Такое вот. Значит, там описывается в основном интеграции, там для наличка представляется уже вся необходимая информация, которая раньше когда-то он ходил сам там к смежным подразделениям, танки и ещё кому-то. Чем это очень важная полезная работа.
Speaker A
Ну и в целом там какое-то архитектурное видение уже продукта описано, больших дам изучила, дают алешин архитектуру. Он общается тесно с детектором, закрывают открытые вопросы и идёт общаться с заказчиком, решать какие-то открытые вопросы с ним.
Speaker A
Значит, дальше где-то появляется дизайн, где он имеет место быть, нужно его обязательно смотреть, то что есть, я на этот дизайн где-то что-то не напишу и что-то...
Speaker A
техническую работу связаны с уводом функционалов продакшен с нагрузкой так далее вот ну безусловно есть еще подразделения которое активно участвует в разработке или выводе в а на вопрос например одел контента copyright еще различные ребята которые активно участвуют функционале но вот
Speaker A
команда среднестатистической разработки до stream так называемый с ребята которые принадлежат присоединены к стримам они выглядят именно так процесс аналитики самый сложный слайд для меня почему потому что я сюда планировал разместить нашу диаграмму из мира она никак не влезла не на 1 и на 2
Speaker A
и даже не на три слайда не смог уместить поэтому решил просто буллитам написать и сказать чем занимается у вас аналитик важно отметить что аналитики разных стенах и по-разному занимаются задачами поэтому это нечто такое объединенная чем занимается + -7
Speaker A
можно отметить что у нас помимо аналитика вещи и ведущие аналитики вот это те ребята которые тоже обучают других ребят помогают им с их задачами делают какой-то экспресс оценку архитектурное видение составляют каких-то моментах когда какой-то сложной фича вот мы поговорим про то обычного
Speaker A
аналитика значит первое что он делает кстати если кто то захочет аналитиком присутствующих на встреч поправить смело врываетесь говорите значит первое это маечку поступают требованию ну например продуктов не либо заказчик да там берёт за ней он изучает это требование
Speaker A
собирает вопросы которые они появились после изучения идет общаться продуктовом ну в редких случаях сразу заказчиком а может быть нередких основных продуктов и все-таки решает с ним открытые вопросы понимают вместе с ним как это будет выглядеть интерфейса если интерфейсная часть имеет
Speaker A
место быть вот зачем затем он изучает интеграция архитектуру там кто не знает у нас на проекте практически на ему как около каждому стриму присоединён архитектор языка digital это человек который также продукт как аналитик только начали ранее значит раннем этапе
Speaker A
вот и готовят некий документ который называется пам так называется дальнейшей архитект vision такое вот значит там описывается в основном интеграции там для наличка представляется уже вся необходимая информация которая раньше когда-то он ходил сам там к смежным подразделением танки и еще кому-то чем
Speaker A
это очень важная полезная работа ну и в целом там какой-то архитектурное видение уже продукт описано больших дам изучила дают алешин архитектуру он общается с тесно с детектором закрывают открытые вопросы и идет общаться заказчиком решать какие-то открыто вопросы с ним
Speaker A
значит дальше где то появляется дизайн где он имеет место быть нужно него обязательно смотреть то что есть я на этот дизайн где-то что-то не напиться и что-то не молиться нужно решить эти вопросы дальше прикидываться архитектуры то есть какой-то
Speaker A
архитектурное видение и обсуждается здесь очень много и написал лиц с которыми происходят обсуждения в зависимости от ситуации аналитиков низким судитесь конечно необходимые обязательные ребята с кем-то нужно согласовать вот то есть опционально ну в общем если брать в совокупности то это
Speaker A
команда безусловно это тим лиды либо разработки либо анализа это в каких-то случаях наш системный архитектор на проекте этом сергей моргунов это дежит архитекторы которые делают экспресс архитектуру интернешнл архитектура эта команда мобильного приложения если работка затрагивают какие-то обе которые
Speaker A
используют командного меню приложения либо например ведь может обсудить а используется ли api и нужно ли там сделать какую-то обратную совместимость вот и это конечно же команда контента который будет выводить функционал production чуть дальше аналитик делают техническое задание то есть это знаем подробно не
Speaker A
буду пояснять это отрисовка процессов дпм или диаграмм кисик из диаграмм ки писания там последовательности действий что нужно сделать чтобы то или иное действие произошло значит дальше аналитик как вы знаете там из предыдущих лекциях у нас есть монолитной части микро сервис на
Speaker A
аналитик определяет где собственно будет жить фича мы не стремимся там все и сразу переносить микро сервисы мы делаем это рационально но стараемся по крайней мере и вот аналитик в частности коллег где-то фича будет жить ну и дальше у нас есть
Speaker A
процесс который кстати говоря я вот немного где встречал это проектирование яму то есть у нас аналитики занимаются нет ни разработчики для аналитики ну с помощью разработчиков иногда занимаются проектированием интерфейсов rest api напомню наш фронт бы каждого общается по
Speaker A
api я арестую вот поэтому в виде я мало аналитик проектируют swagger и гитаре эту а пешку иначе согласовывать разработчикам ну и так далее дальше формирует этот скол ptz который состоит уже из диаграммы за писание замула и отдает на review время примерно тот же
Speaker A
список где то он обязательно где-то опциональный ну так или иначе там в совокупности все эти ребята участвуют согласований и review вот иногда на самом деле это не так часто review происходит с заказчиком и продуктов миром дальше аналитик диком
Speaker A
позирует задачи вместе с командой либо сам если уже понимает там если там там понятно как делать там самый просто разбивка это бэкон фронт-энд ну и дальше уже там если нужно разбивается там font and band еще на подзадачи значит дальше ставится задача на внешней
Speaker A
системы например аналитик ходе анализа какого-то требования понял что есть интеграция с там например ssb взял этот постельку как любой уважающий аналитик протестировал ее вот и нашёл какие-то баги вот нашел баги и пошел завел заявку в системе где эти записываются в данном честно
Speaker A
избег в этом примере вот и проконтролировал что это там исправление будет дома своевременно дальше есть еще момент который нас достаточно подробно описан в вики это постановка задач на devops то есть часто когда делается задача у нас возникает необходимость каких-то
Speaker A
настроек конфигурации и так далее ну самый простой конфигурации то там определение и рлс которым мы будем интегрироваться гулял по которым интегрироваться с внешней системой какие-то параметры типа tn таймаутов так далее но все это заводится задача найти vox отдельным
Speaker A
процессу и аналитик следит за тем чтобы задача попадать попали вместе с вич и если он не проследит есть вероятность того что fitch попадет на целиком продукте фоне будет работать в случае к сожалению бывали поэтому нас появился регламент значит случае изменения т.д.
Speaker A
у нас есть обязательства помещений от всех заинтересованных людей например если меняется я мол мы обязательно должны поместить коллег и с мобильного с мобильной разработки иногда бывает такое что мы делаем плов заканчивается поэтому стараемся все таки случае отрабатывать и за этим тщательно следить
Speaker A
вот значит как я сказал ставится значки на devops если в дизайне например не хватило каких-то экранов то идет общение с дизайнером ставится задача дизайнера с просьбой нарисовать недостающие момент и дальше идет согласований текста с копирайтом идет там плотная коммуникация
Speaker A
и поддержка это задача менеджмент этой задачи с команды разработки с командой тестирования и так далее то есть аналитик ведет задачу должен довести задачу от начала до конца значит дальше он пишет инструкцию для контента если необходимо согласовывать это инструкцию
Speaker A
с контентом далее участвуют в дыма в интеграционных тестах вот ну и не во всех случаях но всё чаще и чаще он чувствует еще постыдных каких-то работах то есть там смотрит собирает какие-то метрики если есть какие-то дефекты сразу после
Speaker A
релиза обрабатывает их анализирует и сразу дает разработку либо не сразу в и так далее вот я специально приложил ссылочку на более детальную схему вот можно будет не посмотреть там большая большая схема с такими м этими да нет в
Speaker A
общем и мы для громко идем дальше процесс разработки что делает разработчик когда к нему пришла задача ну во-первых он читает т з а у него возникает куча вопросов иногда мало вопроса но правила вопросы возникают вот он их задаёт
Speaker A
обсуждается аналитиком ну и начинает там что-то разрабатывать для этого создает системе контроля версий отдельную ветку нас все разрабов разрабатывается по фичино вот и свою часть он делает свои ветки стартуют разработку там бэкон frontend суть важно вот заканчивают разработку и
Speaker A
обязательно тестировать свой код вот недавно мы встречали с разработчиками общаясь на эту тему пришли к тому что таки нужно собой всегда тестировать это тестирование разработчика я то есть это базовый кейса проверяется то есть маски из некоторых рабочих и поверяют кит
Speaker A
ограниченные кейс и это на редко исключения для этого есть тестировщики вот значит моменте разработки истец разработчик часто обращается к аналитику и привлекает на протестировав общем решает вопрос из команды которые возникают затем разработчика дает задачу в review чуть ниже когда бы он будет про процесс
Speaker A
разработки я расскажу зачем вообще review нужно я пока что просто примем тот факт после review ему делать им нет как правило на самом деле не всегда ниже расскажу разработчик исправляет замечания и переводит тестирования тестировщиков тестируют причем в этом в этой ветке
Speaker A
и дальше разработчик исправит все найденные баги баги практически всегда находится вот далее разработчик следит обязан следить по крайней мере за свои веткой если необходим ли bass то есть актуализация скажем так свои ветки потому что там он мог разрабатывать там
Speaker A
фичу две недели до за эти две недели в основной ветки накопилось уже многофункционал и который так лишь пересекается с тем что разработал он это он делает три bass актуализирует свою ветку и переводит в мир затем происходит уже абсолютно другой процесс о котором
Speaker A
поговорим чуть ниже и это фич попадает в продакшн чуть подробнее про review важный момент я точно знаю что некоторых продуктов неров никто продукт оунер не понимали зачем это нужно я вот так и снял некоторым некоторые возможности сих пор не понимают поэтому точно нужно
Speaker A
рассказать про это зачем вообще нужна review я честно скажу видел проекты которые были без review но это проекты которые умирают там через год-два вот потому что их невозможно дорабатывать любая доработка она превращается в какую-то глобальную переработку вот в нашей компании ребята
Speaker A
встречались с такими проектами когда дорабатывали что такого не делали с нуля в этот процесс прямо вы необходим какие задачи он решает во первых это этап контроля качества все это делается не потому что разработчикам какой-то некомпетентно за ним нужно
Speaker A
проследить там посмотреть накосячил ли он это делается там другим причинам дает контроль качества во вторых это как получения контекста другими членами других разработчиков например там на западе но по стримам тимлид из команды inbox например знает что происходит в геймификации потому что
Speaker A
проводит review вот понимает какие там технологии используются ты знаешь какой функционал там есть что можно использовать потенциально и так далее получили контекста отдали это повышение скилла разработчика на самом деле и как разработчика которая в reviewed потому что ему оставляет комментарий как это
Speaker A
делать правильней с технической точки зрения ну и на самом деле повышается скилл и regular а потому что увидит порой там как можно на самом деле сделать иначе хотя он там до этого так и не предполагал сделать что может делать
Speaker A
ревью что входит его зон ответственности он указывает явные ошибки не нарушения соглашений которые нас описанные рубрики в разделе для разработчиков он задает уточняющие вопросы которые ну к разработчику который писал тот вход для того чтобы найти какую-то истину критическое мышление так называемая и
Speaker A
предлагает в каких то моментах более лучше изящное решение для того чтобы это можно было потом переиспользовать под важно отметить что в целом у нас нет на проекте в этом плане рану пройти демократия то есть оставить комментарий выше квесте может любой любому может
Speaker A
младше разработчиков ставить steam ряду и тебе это ставить вашим разработчику так или иначе у нас за каждой команды закреплен там основной reviewer кто делал этот review вот то есть если вы видите что если ваши villar например duo рта вы видите review свежим аргунова или
Speaker A
например там от новенького разработчика это тоже нормально на этом нужно и плохо реагировать это порядке вещей там мы команда мы оставляем коментарии если видим что-то плохое или видим что что то что можно сделать лучше а важно отметить что когда старший
Speaker A
разработчик тимлид тогда и оставляет комментарий с ними можно не согласиться вот но не формате я не согласен не буду делать а абсолютно четко привести аргументы убедить разработчика старшего том что нужно делать именно так вот и порой не соглашаются когда понимаешь что
Speaker A
обмен на себе победителя виды review не можно вопрос быстро к предыдущему слайдов вот человек который делает review он тоже считает с либо только в чисто вход как бы смотрит находит ошибки только в коде и а смысл вот это
Speaker A
разработки и погружаются я понял вопрос вообще в целом review сделано не для того чтобы отловить бизнес баги какие-то и так далее сделал для того чтобы это чисто техническая составляющая то есть он смотрит в основном код но во многих случаях
Speaker A
review веру для того чтобы если это большая какое-то значимая задача они эта маленькая он на и смотрит это за для того чтобы погрузиться чуть больше чуть дальше глубже а точнее вот и может уже оставлять комментарии по бизнес-логики вот то есть такое тоже
Speaker A
практикуется но это не маска все-таки это больше там техническая часть а какие у нас виды review бывают все думают что настолько тимлид review the разработчика на самом деле тоже давно не так основной тип это когда тимлид review этого разработчика
Speaker A
вот есть еще вид когда у нас а чуть более опытный разработчик там или чуть более погруженный в конкретной предметной области ввиду другого разработчика который чуть менее погружаем вот область и затем происходит уже такой review по диагонали старшим товарищем тем видам
Speaker A
еще один из из вид на самом деле применяется только в одном месте когда разработчик имеют разработчика без повторного review тимлида например то происходит когда есть какая-то изолированная часть функционала разработчик ней супер компетентен там комитете только он даже там ливер и тим
Speaker A
лиды на этом вот детали реализации вот и какой-то разработчик пришел и доработал social тогда при допустимой review в таком формате а тим лиды не остается без review да у нас тим лиды review & the tune дав например там тимлид с тремя
Speaker A
би ту би есть и милиции продукт и flight вот ребята другой другой review то есть семье это не человек который нельзя любить самом деле даже системного архитектора reviewed ни одна задача без review насколько не должна проходить вот и есть такой недавно мы ввели такой
Speaker A
процесс кругового ревью на самом деле популярный часто используются других командах это когда идет ну например разработчики там тимлид у нас сделал задачку скидывает в чат и говорит ребята посмотрите еще 2 человека кто успел паре weevil могут два человека
Speaker A
превью достаточно одного про от одного разработчика вот например нас такое применяется в стиме korg потому что там собственно только тим лиды ну практически до поэтому там где от круга лари тестирование самом деле по тестированию здесь можно много чего
Speaker A
рассказывать я попытался точнее андрей попытался а я немножко отформатировал привести это в такой компактный состоянии 2 основных вещи мы тестируем отдельно в бэг-энде front-end и мы тестируем связку front-end и back-end бэкон входит у нас интеграции тестирования api тестирования наших
Speaker A
админок там пересидим там админок бэк-офисов там суза еще чего-то вот тестируется что попадает в реляционной реляционной базы данных там в кафку и так далее и frontend на я часть это тестируется функциональность купи уже берутся маршруты от объекта и берется тестируется там
Speaker A
соответствием и тестируется кого-то браузер ность сейчас мы переходим уже к тому что часть функционала у нас реализуется только побью например для мобильного приложения мы с коллегами обсуждаем как возможно потенциально нашей стороне проводить такие тесты без участия коллег с мобильного приложения
Speaker A
вот ну и мы тестируем безусловно обработки всех типов ошибок то есть не только паски и сортировщики уже тестируют граничные кейсы первый кейс вставлять класс эквивалентности . вот такой углубленно тестирование для чего-то там slt стены который делает разработчик а визуально процесс
Speaker A
тестирования выглядит так делать какой доработка либо баг фиксинг тестировщик идет в git love разделся и сиди и там есть кнопочка сборки на тестовый стенд он у каждого дозировщик а ей свой тест стенд вот такая мини копия на предыдущих лекций рассказывал мини
Speaker A
копия продукт его с ограниченным набором данных из нож к другим контент вот на тестовом стенде на кадр руку проводит фичи testing там что-то правится по итогу когда все хорошо stermy прошла успешно задачка отправляется мир и тимлид делает держит эту задачу основную
Speaker A
ветку чуть дальше перед регрессом там все это дело попадает на некий талон на стенд уже в основной ветки и о задачки если требовали контент и настройки настройки делаются на эталоном стенде для чего для того чтобы эти настройки потом
Speaker A
сохранились то есть когда любой стенд будет и накатываться контент по ним будет и накатываться и этот контент уже будет наиболее актуален для этой фиче вот ну и в частности для авто тестова талон стента же необходим потому что на
Speaker A
нем ребята с него берут чем раскатано уже и по ним пишет автотест а значит и дальше все это дело раскатывается после талон на стенд энергия тесты стенды прошу прощения и versions стенды у нас всегда в таком сам актуальном состоянии то есть если фича
Speaker A
дело станет на этом уже не баланса то это выражение баланс уже выйдем на какую-то страницу перед регрессом вот она уже прям собрано вид газа важны надо дополнила свой передачи там я не знаю насколько экстрима у нас есть еще
Speaker A
после успешного тестирования задачи в приемку попадает это налить больше то мы должны кейса и уже после именно аналитики на хорошее замечание самом деле там не только в вашем стриме есть три сделал такую обширную версию вот но в целом то
Speaker A
замечание действительно имеют место быть такое практикуется как минимум 2 стримов вот когда аналитики еще принимают задачки и на самом деле лекарства по позитивный момент попробуем командующий design review вводить после после тестирования и аналитики так не для всех задач у меня кажется
Speaker A
тоже помогает о круто есть может быть адресован этот процесс мы бы его добавили диаграмм было бы круто я бы на монтаже вставил сказал вот так бы и равана но пока тестировать процесс отдельная колонка design review именно в продукции ну круто кстати другим
Speaker A
командам на заметку может быть тоже пригодится так ведут нас тут до черта тут что-то добавить они почти достал стендов самый стандартный тест стенд это тест остин тестировщика разработчика аналитика там настройка на тестовой интеграции но здесь пример приведен биллинг на самом деле не только биллинг
Speaker A
мы избе имеется безусловно это там и какие другие тесты интеграции хочет содержится тестова контента то там три четыре сайта и настроенный талон на контент который остаюсь другими тестировщиками то есть забирается дамп раскатывается талон на стенды раскатываться другой стенд
Speaker A
значит на этом тестом стенде контент настроен таким образом чтобы можно было бы легко проверять на регрессия 1200 никаких ограниченные кейс вот то есть настройка не не прям к в продукте виа с учетом еще каких-то моментов которые нужно проверять
Speaker A
периодически дальше талон на стенд про него я подробно рассказал самое актуальное состояние вот часто актуализируется самое что ни на есть этот стенд актуально чем продукте фоток то есть вещи которые еще не выведены и настроен они уже есть на этом стенде вот
Speaker A
есть отдельно здесь не стали писать на самом деле есть это авто тестер ские стенда то есть там у нас идет настройка на мог сервисы то есть если на обычном тестовом стенде у нас тесту интеграция с тестом избе то
Speaker A
для авто тестов очень важно предусмотреть различные граничные кейсы для различных длин для определенных абонентов поэтому ребята не используют для авто тестов вот такие вот интеграции с тестовым esbe например они делают заглушки заглушки умные которые там зависимости от абонента отдает тот или
Speaker A
иной ответ по этим поэтому можно проверять различные ограничен значения вот и есть у нас можно отнести тоже к тестам стендом это юзера contest стенд это приближенная продолжен версия стенда на менее мощные но содержит продуктивный контент есть специальный регламент обновления у нас описан вики
Speaker A
вот и вот это супер ценная единица сейчас потому что их не хватает вот там периодически обновляется полностью дамба за контент на составляющая и там продуктивную интеграция за редким исключением иногда бывает что ее от смотрит на тест на самом деле мы
Speaker A
обсуждали в первой лекции по моему можно подмотать на ютюбе переключиться посмотреть потом вот такие основные стендом важный момент когда у продуктовый раз команда менеджер забирает тестировщиков это регрессионное тестирование без него никуда она у нас на протяжении уже нескольких лет
Speaker A
плюс-минус с точки зрения тайминга не меняется то есть это два с половиной три дня два-три дня наверно час занимает вот значит когда вся команда проходит чек-листы на регрессионным стенде вот устанавливаться полностью релизный сборки важно чтобы при старте регресса
Speaker A
не было каких-то супер блокирующих дефектов вот так же релизная версия устанавливается на татарские стенды прогоняются автотесты каждый вам вот где то в середине регресса заводится какието регрессионные баги они правятся отправляются критично дефекты некритичных дефекты могут уйти какой-то backlog
Speaker A
вот и где-то среди нерис начинается заявки на добавление исправлений прелестной сборки на самом деле периодически и просят добавить какие-то задачки которые ну вылезли там входе интеграционного тестирования очень хаотичная с аргументацией иногда их принимают когда приведены соответствующие доводов значит ну и
Speaker A
критерием завершения регресса является отсутствие критических дефектов подгоняется финальный автотесты в никто ничего не обнаруживает критичного нового вот в этом суть книга завершается чуть-чуть поподробнее про процессов то тестирования нас в каждом стриме практически в каждом есть автомате затар который дополнительно которая чем
Speaker A
занимается он пишет автотесты даче видно как это происходит процесс есть доска задач попадает на доску стрима вот проходит ручное тестирование фичи тестинге вот потом готовится мог сервиса про которые сказал либо стопы то есть стабильные который дают один и тот же
Speaker A
ответ либо умные заглушки вот настраивается контент при необходимости вот и дальше написано читается написание авто тестов мы пишем автотесты как на интерфейс так и на пкм часть ну по сути api проверяем вот значит дальше эти тесты пишутся прогоняются отлаживается и
Speaker A
добавляются общий пул регрессионных тестов в следующий раз когда revisions теста будут запускаться но вот это же попадет вот это когда она свечного и если свеча до работалось функционал уже работал например на нем не было теста или фича до работалось вот заводится
Speaker A
задачка на автоматизацию на доске tfs точно также подготавливать или актуализируется мог сервисы контент значит все это делается на базе общения с ребятами которые тестируют занимаются ручным тестированием вот дальше пишутся точно также api либо интерфейс интенсивно тесты на базе
Speaker A
мануальных тасс кейсов и точно также теста попадает общий пул прогона по version их авто тестов вот во многих стримах то практически на всех я думаю игорь уже ввёл и не только игорь этом паша вот у нас идет непрерывное взаимодействие с
Speaker A
автомате зато rus ими тестировщиками это как мы видим на практике жизни необходимо потому что если автомобиль зато работает изолированно то тестировщиков то он не покрывает критичные кейсы она задача до уменьшить дальше будет какая польза до приносит автотест это ускорение
Speaker A
регрессионного тестирования на самом деле это не то чтобы ускорение это сохранение текущего срока текущего тайминга вот и когда автомате зато взаимодействия с ручным тестировщиком он понимаю что вот эта фича она руками проявляется очень долго покрытие допусти не так долго им покрывает а в первую
Speaker A
очередь вот процесс прям показывают себя хорошо на практике когда ребят под на взаимодействует вот у многих стримах это дается пользу значит также мы обеспечиваем прозрачность выполнения визуализацию покрытие в тестами на следующем слайде я не знаю видно или нет но здесь два
Speaker A
скриншота красиво приемного первый скриншот ну у нас есть такой продукт который называется карты покрытий автотесты вот он уже рабочие его можно пощупать пока что сделана только для api для бэкон покрытие но уже круто да мало у кого такие штуки
Speaker A
есть вот это собственно разработкам и собственно смотрим по каждому стриму а какое у нас примерно покрытие то есть мы берем slogger смотрим какие там есть методы вот во всем этом есть всего мы покрытие фичи то есть это там должно
Speaker A
быть выполнено кто-то то это вот считаем в этом случае фичу покрыты это отслеживается на и view вот таким образом мы вводим такую карту покрытие для каждого стрима и можем смотреть еще историчность то есть например сколько было процентов покрыта в продукте мая
Speaker A
сколько стало июля вот всегда берется лично относительно того функционала который сейчас есть на каком-то стенде вот кому интересно будет напишите я думаю что игорь скинет да игорь можно же ужас кидать коллегам то ссылочку или богатой в пилотном режиме городские
Speaker A
цветы уже можно принципе все работает ну я прям по и франку до посмотрел честно потому что я такую штуку пока нигде не видел в таком виде как она есть ну и когда мы прогоняем то тесты мы не результат получаем не виде какого-то
Speaker A
необработанного куска logo ли еще чего тогда мы получаем абсолютно визуально понятный отчет о со скриншотами если это век тесты на каком шаге свалилась который можно обрабатывать который может обрабатывать ручной тестировщик тестировщика кто угодно в целом про нагрузочное тестирование здесь наверное мало не
Speaker A
меньшая часть аудитории знает про то как проводится нагрузочное тестирование зачем она проводится но в последнее время все чаще она необходима на флейтах не на сайтах общем в двух словах что это такое за чем основная цель и нагрузочного тестирования
Speaker A
это в первую очередь оценка производительности функционала приложения сайта не важно на этапе разработки то есть до вывода в продукте вдовы вода в эксплуатацию вот это возможность оптимизировать приложение вот включая там и сайзинг настройки серверов оптимизацию кода и некая
Speaker A
подборка оптимальной конфигурации для системы таким образом чтобы система работала продукте вы хорошо вот мы нагрузку проводим сейчас двумя инструментами наверно в какой-то момент все сотница в 1 вот так исторически сложилось это jmeter и гатлинг основное их различие заключается в том что же метр
Speaker A
подает продуктивно нагрузку и случай система деградирует а он как и пользователи начинают тоже просаживаться а гатлинг в случае система деградирую он продолжает наяривать нагрузку и кладет систему от но это если прям супер верхнем уровне в иске программирование разные картинки таскала функционально
Speaker A
язык программирования на j3 я там в основном это на клики вается в интерфейсе плюс пишет о наполнителе скрипты какие то значит какие у нас бывают виды накручено тестировали на проекте значит первое это тестирование производительности запускается нагрузка для того чтобы определить насколько
Speaker A
нужна система то масштабировать под нагрузкой значит отслеживаются там тайминги выполнения операции и сам смотрится какие-то границы пример приемлемой производительности далее это стресс-тестирование то когда мы понимаем что там нагрузка будет вот такая мы подаем специально больше на период например какой-то рекламной кампании
Speaker A
акции то чтобы посмотреть как система себя ведет pireus tres вот третье это тестирование отказа восстановление то есть когда у нас мы довели систему до того состояние когда на рекламе смотрим чтобы система достаточно быстро могла остановиться это очень важно потому что
Speaker A
бывали случаи на проекте когда система легла а восстановить и очень долго не восстанавливаются не как там в приемлемое время после падения это плохо поэтому такие the stage боев и самый стандартный тест который мы делаем после каждого регресс это stability
Speaker A
тестирование тестер места benz дается продуктивно нагрузка такая как она есть в основном длительная нагрузка какой средний уровень нагрузки берется и смотрится как система сведет в течение какого-то времени вот это четвертый пункт он у нас мазков на большие релизы
Speaker A
вот все остальное у нас опционально какие проблемы решают нагрузка понятно делает обнаружение каких-то недостатков с точки зрения performance кода бывают у нас как-то некорректно настроено не оптимально настроена микро сервис за счет чего там он сбоит при большой нагрузке вот бывают у нас
Speaker A
инфраструктурной проблемы которые тоже нагрузка обнаруживает и бывают проблемы с реляционными реляционным базам данных и мир накид не оптимально запросы можно отследить на этапе до продуктивно вот и так далее можно понять что в любом случае всегда есть там потенциальный
Speaker A
риск того что что-то вылезет продукте вы потому что мы все-таки тестируем направляйте который не является продуктивным окружением от есть какая-то корреляция поэтому иногда к сожалению баги пролазит но много чего мы обнаруживаем боб рода что может не радовать идем дальше чем по таймингу от
Speaker A
супер а devops это ребята которые находятся на стыке разработки тестирование эксплуатации ну наверное больше разработки эксплуатации но с термин тоже что они делают у нас на проекте любые технические задачи связанные с конфигурацией доставка микро сервисов или монолитного приложение в
Speaker A
продуктов настройка и оптимизация конфигурацией балансировщик of нашего основного базового приложения микро сервисов подготовкой разворачивания новых сервисов они поддерживают установку или за которую делают инженеры катишь это значит поддерживать полностью наш тестовый контур включая рублей но кроме его тов и вот у нас поддерживает команда
Speaker A
цска digital и я сказал abs это не просто администратор да этот там чек который я чуть большим компетенциями devops и есть проектные да там и при нашей команды большой есть его пути к digital мы с ним плотно взаимодействуем
Speaker A
значит когда можно и по каким вопросам можно обращаться к диап сам например мы сделали фичу и нам необходимо чтобы эта фича появилась продуктов была настроена на тесте на под лайки найти и так далее например там для теста у нас были и
Speaker A
конфигурация там такой-то улик для интеграции с ес будет ли аятов другой для паблика 3 еще это было примерно перманентно чтобы никогда не сбросилась че дальше у нас там сломался теста вас центр от лайк там pd не актуально и так
Speaker A
далее можно тоже вращаться как его псам заводи заявку ребята решают этот вопрос чем дальше они могут подготовить среды для проведения нагрузочных испытаний подготавливаю тесты окружением и создают актуализирует контент на нем полностью и создают st стенд с red конфигурации
Speaker A
продукте вы и теста делают мне как-то лизации тесто окружения вот и есть у нас вот эти сервисы которых мы с вами говорили там купина исков к кассандре на самом деле там еще больше там кому-то и так далее вот они тоже разбираются
Speaker A
настраивают собственно нет еще делаю там изначально разворачивали вот есть какая-то проблема они разбираются такой список базовых задач бокс идем дальше наверное это все знают вот но повторюсь на это схема у нас есть мир она общедоступна у нас даже где то
Speaker A
есть на в регламенте ссылка мне о чем как мы работаем по спринтом релизом на самом деле до двенадцатого года был не так мы разрабатывали сразу выпускали потом поняли что у нас есть там существенные минусы в это в этом подходе
Speaker A
мы лишили его переработать у нас всегда после спин то есть gap на тестирование то есть столько мы закончили какую-то большую версию релиза разрабатывать у нас проходит еще недели до того как мы указываем продуктов фактически недели вот для чего это нужно для того чтобы их
Speaker A
то экстраординарных событий которые всегда возникают какой-то критический бак на ружин после интеграционного тестирования вот что-то еще вылезла там регрессия что требует более детального анализа и так далее во вторник у нас планирование да потом мы две недели разрабатываем вот потом отводим
Speaker A
отдельную релизную ветку куда не может попадать ничего кроме исправления багов либо согласованных доработок вот раньше лишь нужно согласовывать в этот момент начинается уже планирование и разработка следующего спринта эти две активности идут параллельно не мешая друг другу вот и в конце концов
Speaker A
когда прошло регресс когда исправлены все дефекты собирается резная версия большая отправляется в продакшн и попадает уже в develop тут зелененькую штуку которая уже разработчики что-то разрабатывают такой процесс пока что нам кажется эффективным для с учетом того что есть монолит если вы
Speaker A
были только microserver своим мы бы наверное типа стилинг процесс вот но пока что так значит идем дальше тип релиза в регламенте как вы знаете у нас на проекте существует регламент и почему они есть потому что сталкивались и наступали на
Speaker A
разные грабли когда например не было регламента можно было что-то включить сборку потом это как-то эффект тела это как-то никто не согласовывал поэтому решили что команда у нас большая все таки нужно немножко упороться бюрократии составить регламент и вот на основании
Speaker A
составленных регламентов у нас появилось несколько типов релизов это планово релиз сам обычно которой я рассказывал раньше вот немногие знают мои планы в релиз масс расписываются на год вперед вот и в целом практически никогда не меняют свой даты за редким исключением
Speaker A
значит внеплановый релиз от когда нужна какая-то доработка но она не влезла в планов релиз или ее нужно ставить отдельно бывают такие доработки вот тогда запрашиваются по специальному регламента письме внеплановый рейс и ставятся отдельными работами из технический лист например там оптимизация fontaine да там
Speaker A
привязаться бэг-энда устранение какой-то проблемы такой не критичный но которое требует технических а bredoff вот это отдельный тип релиза кстати там они нас выбирают с пауком то кто не знает lanriz у нас год .
Speaker A
месяц . число . он либо там ну как бы счетчик то если допустим несколько плановых лизу в один день то этот счетчик выдвигается вперед тире р большая во внеплановом р маленькая в техническом т в аварийных работах это и есть это hotfix аварийная
Speaker A
работа это какое-то экстренное устранение проблем иногда бывает даже мои которая вызывает массовые ошибки регламентируются тем что заведен инцидент 2 или 1 степени критичности а дневной релиз недавно запустился может быть об этом не все знают можешь поставить наверно порядках идти до
Speaker A
наш побольше огненных релизов сложно догадаться получается букв т.д. и есть у нас один тип релизов лайтовая это выделенный привилегией вот потому что под них делается массовая такая массированная рекламная кампания нельзя как бы промахнуться вот поэтому несколько релизов в год у нас сейчас
Speaker A
есть сайтах как вы поняли обозначается буковкой f маленькой вот у нас есть отдельная ссылка да кто хочет посмотрит с большим большим регламентом вот продукт оунер уже об этом все знают заказу хотя бы один раз релиз все по этап регламент знают немножко поговорим
Speaker A
про подготовку закрытия сборки но разделим на плановый и любой другой релиз для планового все абсолютно понятно кирова на я сказал нас обходится отключен от шума по моему тебя так значит на чем ты остановился на планов на подготовке плановый релиза от
Speaker A
основной ветки отводится после день спринта резная ветка туда имеет право подать только маг фиксинга либо согласованные доработки вот значит закрывается до 17 30 последнего aspen то значит если он соответственно за каждую сборку разработчики которые отводят и эти резные ветки вот дальше
Speaker A
производится регресс как мы говорили ранее и различном два-три дня примерно вот после того все ошибки исправили их между лет но исправление в маджули в релизной ветки вот все готовы закрывать сборке сборка закрываются вот они закрываются в середине дня которые
Speaker A
предшествуют ночью установки релиза можно перечитать еще пару раз потому что непонятно но я уже привык тех кто занимается резами должен также у нас перед тем как поставить релиз там когда идет регресс так далее проводится с некоторого времени очень важные процедуры
Speaker A
1 процедура это аудит релиза то есть когда садится команда из руководителя поддержки эти блюда тестирования каких-то ребят которые привлекаются к этому опционально они садятся смотрят все все все задачи осмотрщик весты и смотрят что может потенциально навредить в продукте we это
Speaker A
все отдельно выписывается идет выяснятся с этими льдами разработки с разработчиками то есть такое критическое мышление которая дает свои результаты я это чуть-чуть поправлю наверное таварес разработчики объясняют это объясняется со всеми причастными задача блокнота 100 не только расскажу разработки моим
Speaker A
просто со всеми кто работам задачу лыжные что почему это на самом деле как только movie ли этот процесс сразу он показал свой результат вот значит дальше мы из недавних пор вилли 1 уже два релиза сейчас будет третий мы делаем так
Speaker A
называемую репетицию релиза то есть это прогон пускается нагрузка стабильная но stability наоборот like делается установка точно так же примерно как она делается продуктивен и смотрится графики те же самые которые смотрятся в продукте we при установке и дальше выясняется
Speaker A
если какой-то эффект в эти брать com если у нас прерывание во время установки если какие-то проблемы после этого прогона исправляется инструкции для того чтобы на самом релизе уже минимизировать какие-то риски но и у нас еще проводится обычно тестирование
Speaker A
stability каких казал там для каждого большого релиза вот для любых других релизов все выше сказанное имеет место быть но опционально вот значит регрессионное тестирование предусмотрена но тимлид может принять решение о том что какая то часть функционала будет при
Speaker A
грешно дополнительный ресурс возможно на этом прогон каких-то тестов применяется в tst иногда делаются на площадь этой херни когда это необходимо и собственно задача закрывается в день которые предшествуют релизу закрывается до 18 00 это всё есть регламенте значит сборки закрываются в
Speaker A
середине дня которые предшествуют точно так же как и случай плановые лиза есть отдельный регламент для дневного релиза но так как нас чем пилотирует сюда пока что не стали выносить это все можешь почитать уже веке вот мы рассчитан на то
Speaker A
что через какое-то время наступит классные времена и у нас будет только дневный релиза вот все для этого делаем идем в этом упражнении и каждый день дома нет сам процесс релиза там дальше будет пару картинок мы пока расскажу на словах
Speaker A
начали плановый с готов очищается 1 1 2 недели в ночь с понедельника на вторник либо как в данном случае там со среды на четверг так получилось вот исполнитель до релиза это всегда инженер со страницы к digital значит у него есть специальный
Speaker A
инструмент через которым запускает релизную по и буку до выполнения реализован всегда проверяю что сборки есть входящие все с нужные версиями все классно и начнем проставляет нужные версии по плану который подготавливают там команда же не пускать и даши плюс андрея в общем
Speaker A
команды ребят который подготовить рис вот поставляют эти версии запускают эту play букву s при весну участок кто есть чате релиз инфо вы можете видеть вот такие saab не запуск вы ибуки установки или визитом становится weblogic устанавливается там приближаются но ты что-то еще происходит
Speaker A
вот это все транслируется специальный чат кто не добавлен кому интересно может понаблюдать сюда же в каждом треке если там сталкивается с какими-то проблемами ребята они описывают и решают в трейде поэтому на утро когда там нужно посмотреть что установил что не
Speaker A
установилась можно легко отследить вообще в каком состоянии релиз что встала что откачано было и так далее а справа это такая play book для инженера то есть как видит релиз инженер своими глазами что еще что еще всегда для лиза у нас готовится
Speaker A
документациям это релиз на ус где перечислены все баги все доработки фичи которые у нас попадает в триз то есть для того чтобы всегда можно понять что в каком релизе было выпущено это очень удобно значит идем дальше дальше мы
Speaker A
поговорим немного про управление доступности доработок на продукте we как я сказал ранее когда мы выкатили в продакшен фичу это не означает что она уже доступна для пользователей это означает в каких-то случаях это так и есть но большинстве случаев ее нужно еще
Speaker A
до настроить а чтобы она была видна на вебе значит для этого используется настройка контента и или конфигурация либо это по отдельности либо все вместе значит если говорить про настройку контента то должна быть заведена заявка составлена предварительно аналитиком инструкция как
Speaker A
вы там говорили на слайде про аналитику а как нужно настроить согласован должна будет инструкция с командой контента должна быть заведена заявка на настройку этого контента это не будет сделано соответственно этот раздел сайта там какой-то картридж не появится на
Speaker A
продукте вот конфигурация конфигурация выполняют инженеры ck digital либо devops и в некоторых случаях для того что функционал стал доступен помимо настроек контента нужно чё там что то поменять в геноме не либо там конфет напекла сервисе настроить и так далее рубильники на самом деле
Speaker A
рубильники такая необходимая вещь в нашей работе потому что часто нам требуется выкатить функционал настроить его вот сделать так чтобы был доступен для определенного сегмента пользователей но в какой-то момент просто сделать очень быстро операцию которая позволит раскрыть этот функционал для всех вот
Speaker A
рубильники нужны соответственно того что включать-выключать использование фронтов нового метода допустим на бэг-энде включать и выключать использованию pk много методов внешней системы dos интеграции изменить отображение некоторых элементов на фронте показывать или скрывать эти элементы и видоизменять то есть вращать и не
Speaker A
возвращать какие-то параметры нашего rest api на чуть подробнее какие бывают рубильники бывают четыре типа рубильников это рубильник би си си рубильников с принц менеджеры рубильник в нашей конфигурации дин админ и рубильник в конфиг мафия микро сервиса скоро я
Speaker A
надеюсь появится еще один тип рубильника это совсем выглядит она будет тут наша реактивная конфигурация когда мы можем там бизнес конфигурацию меня тире активно применять вот каждом подробнее и связал cai-1 админ это напомню некая админка такая техническая для oracle commerce
Speaker A
туда разработчик может заложить какую-то настройку конфигурацию который можно оперативно применить через интерфейс и потом сделать определенные действия которые применит это настройка permanent какое-то время вот здесь пример приведен что нужен был рубильник для поиска страны в которой находится абонент и
Speaker A
чтобы открыть функционал вот точнее так чтобы при при значении true в в это админке использоваться метод езды который вращает одно значение и при фолз возвращает другое значение соответственно визуально это выглядит именно так и чтобы включить там заводится заявка на администратора
Speaker A
ck digital он идет интерфейс на каждой но здесь это дело включает и заводит у себя там задачку на то чтобы опередить и потом permanent второй тип рубильнику в би си си ю ну здесь все просто это обычные там checkbox или еще что-то мы
Speaker A
что-то можем ключи чтобы выключить допустим был пример там для карточки тарифа есть рубильник возможность кастомизировать тариф вот если активен и если эта галочка активно то в карточке тариф отображают кнопку настроить тариф не активно не отображаются этими изменению же в отличии от предыдущего
Speaker A
управляет отдел контент а вот для того чтобы сделать включить выключить нужно заявка от expense manager точно также управляет отдел контента примерно тоже самое только для картриджей например там есть у нас там в одном из картриджей checkbox enable вот если этот чек бокс
Speaker A
активен the cartridge определенно отображается с рамках если активен то без рамки вот пример такой вид рубильник и последнее это конфиг map микро сервиса значит например и можно включить логирование событий в одном из микро сервисов в частности в данном случае
Speaker A
прием microserver пример лкп тусе вот и придем рубильник который отвечает за лоббирование событий вот управление этими рубильником происходят либо через эти abs офф лиги либо через оделся к digital такой технический рубильник значит дальше про очень важную вещь расскажу про обратную совместимость
Speaker A
участвую которым много разных вич вот но при этом вынужден обращать внимание на то как новая фича будет работать со старым фронтам например старый backend будет новым фронтом работать и так далее так далее что такое обратная совместимость это наличие в новой версии системы
Speaker A
интерфейса или каких-нибудь сущностей которые присутствуют старой системе версии системы результате чего другие интерфейсы конечно другие пользователи могут продолжать работу с новой версией фичи без каких-либо дополнительных действий то есть например мы что-то выпить или и старым 2 фичи ничего не отлетело
Speaker A
чем у нас есть несколько типов проблему с которой мы сталкивались в частности из особенностей оракла это расскажем поговорим о том что очень приводит к таким проблемам совместимостью есть три типа проблем без session и и эксперт менеджеры и описаны висишь нее
Speaker A
проблемы это когда мы что-то добавили в атрибут сущности так и тачки какой-то атрибут сущности добавили либо какое-то атрибут удалили либо переименовали в этом случае может возникнуть обратно несовместимости фака с манжета удаления картриджа это удаление police car также добавление переименования полей в
Speaker A
картридже изменения каких-то значений дефолтный дефолт и изменение типа поле допустим был string стал числовое поле и там массив вот в этом случае тоже будет обратно несовместимость которые нужно обрабатывать и api например мы какие-то дополнительные поля обязательные варки добавить либо какие-то поля убрали bots
Speaker A
интерфейс уже этом рассчитан на то что там эти поля придут они не приходят и все плохо чем как мы с ними боремся если производить какие-то несущественные изменения на панде вот то нужно предусмотреть и там аналитику разработчику и писать и рисовать
Speaker A
функционал таким образом frontend ней чтобы он работал и со старой сборкой из новой сборкой вот если это какие-то существенные уже изменения вот то необходимо создать дубликат и эти карты джей а старые потом удалить вот например там болгар .
Speaker A
баннер на главной странице мы понимаем что этот карточный совместим с какими выкатив его нам придётся делать кучу всего предусматривать кучу всего там перелопачивать коде мы горим окей мы сделаем новый кортеж совершенно мы поместим его на какую-то страницу у
Speaker A
старый будет жить потом когда старый будет нужен мы старую берем будем работать только снова вот ну еще на самом деле есть вариант обеспечения обратной совместимости которой здесь не описан но скоро будет и почти или zolan это некий праздника прохождения аудита и
Speaker A
управления контента специально тулузы то есть ворог ли как я говорил есть такие проблемы с обратной совместимостью которые могут возникнуть при разработке и вот написан практически уже tool который будет виден распадаться скоро я надеюсь который будет определять все таки места и даже потом наверное
Speaker A
управлять вот ну и все я вложился в час чуть больше отварите до важно спасибо большое можно понимать что по каждой из частей это все по верхам безусловно мы с коллегами готовы и будем готовить даже если никто не попросит более детально и
Speaker A
более детального разбора до чтобы все новые сотрудники всех кто хочет углублялись понимали как это работает кому это нужно вот поэтому welcome с точки зрения того кто хочет чтобы рассказать чем-то подробней принимаются заказы со следующим делю
Topics:Digital Suiteаналитикаразработкатестированиерелизыdevopsстримыархитектураобратная совместимостьуправление проектом




![Йозеф Менгеле – ДОКТОР СМЕРТЬ из ОСВЕНЦИМА [История в Личностях] — Transcript](https://i.ytimg.com/vi/3yDnGk7DVCo/maxresdefault.jpg)






