🖐 Друзья, в 14:40 приходите на следующие доклады:
⠀
🔸 Зал «Конгресс-холл». Петр Артамонов (Evocargo) «Рассказ о том, как мы внедряли IAC для электрических автономных грузовиков»
Лёгкий доклад с байками и шутками — и немного про беспилотники. ПК всячески рекомендует.
⠀
🔹 Зал «Кейптаун». Станислав Левин и Андрей Сухоруков (Лаборатория Касперского) «Secret as a code и случайно заDevSecOps'или?»
Менеджмент ресурсов — тема неновая, а вот как правильно подойти к вопросу менеджмента секретов и работы с ними так, чтобы и безопасно, и удобно для всех участников — уже другое дело.
⠀
🔸 Зал «Сингапур». Олег Сапрыкин и Андрей Радыгин (Флант) «Stateful в Kubernetes. Казнить нельзя помиловать!»
Kubernetes прошел большой путь, чтобы облегчить запуск stateful-приложений. Из доклада можно будет узнать, что изменилось за последние годы и почему запускать stateful-приложения больше нестрашно.
⠀
🔹 Зал «Уфа». Тамаш Фазли (Evocargo) «"Conan-варвар": как мы масштабировали разработку автономных машин и зафакапились»
Доклад раскрывает опыт внедрения системы сборки C++-проектов - Conan - в компании Эвокарго. Рассказывается о затратах ресурсов, проблемах и выводах из этого опыта. Обсуждаются проблемы при внедрении новых технологий сборки и дается обзор полученных результатов преодоления сложностей.
🔸 Зал «Дели+Калькутта». Максим Чудновский (АО "СберТех") «Istio Ambient Mesh — эволюция или революция?»
Если вы задаетесь вопросом, настало ли уже время sidecar-less в теме Service Mesh или нет, то этот доклад все расставит на свои места.
⠀
🔹 Зал «Пекин». Рашид Галиев (Сбер) «DevOps в Сбере — ретроспектива 2017 – 2024»
Докладчик расскажет про путь, пройденный внутренним сообществом с 2017 года. Раскроет подходы, практики и метрики, покажет, как они повлияли на топологии, процессы и инструменты. Поделится проблемами, решениями и новыми вызовами.
⠀
🔸 Зал «Конгресс-холл». Петр Артамонов (Evocargo) «Рассказ о том, как мы внедряли IAC для электрических автономных грузовиков»
Лёгкий доклад с байками и шутками — и немного про беспилотники. ПК всячески рекомендует.
⠀
🔹 Зал «Кейптаун». Станислав Левин и Андрей Сухоруков (Лаборатория Касперского) «Secret as a code и случайно заDevSecOps'или?»
Менеджмент ресурсов — тема неновая, а вот как правильно подойти к вопросу менеджмента секретов и работы с ними так, чтобы и безопасно, и удобно для всех участников — уже другое дело.
⠀
🔸 Зал «Сингапур». Олег Сапрыкин и Андрей Радыгин (Флант) «Stateful в Kubernetes. Казнить нельзя помиловать!»
Kubernetes прошел большой путь, чтобы облегчить запуск stateful-приложений. Из доклада можно будет узнать, что изменилось за последние годы и почему запускать stateful-приложения больше нестрашно.
⠀
🔹 Зал «Уфа». Тамаш Фазли (Evocargo) «"Conan-варвар": как мы масштабировали разработку автономных машин и зафакапились»
Доклад раскрывает опыт внедрения системы сборки C++-проектов - Conan - в компании Эвокарго. Рассказывается о затратах ресурсов, проблемах и выводах из этого опыта. Обсуждаются проблемы при внедрении новых технологий сборки и дается обзор полученных результатов преодоления сложностей.
🔸 Зал «Дели+Калькутта». Максим Чудновский (АО "СберТех") «Istio Ambient Mesh — эволюция или революция?»
Если вы задаетесь вопросом, настало ли уже время sidecar-less в теме Service Mesh или нет, то этот доклад все расставит на свои места.
⠀
🔹 Зал «Пекин». Рашид Галиев (Сбер) «DevOps в Сбере — ретроспектива 2017 – 2024»
Докладчик расскажет про путь, пройденный внутренним сообществом с 2017 года. Раскроет подходы, практики и метрики, покажет, как они повлияли на топологии, процессы и инструменты. Поделится проблемами, решениями и новыми вызовами.
В 15:00 приходите в Зал «Шанхай» на мастер-класс от Алексея Обровца «Введение в нетворкинг: базовые навыки кулуарного общения»
Крайне важный мастер-класс про то, как разговаривать с незнакомыми людьми на афтепати, если вы вдруг не очень умеете, но хотите научиться. ПК рекомендует, ведь эти знакомства — важная часть конференции!
Крайне важный мастер-класс про то, как разговаривать с незнакомыми людьми на афтепати, если вы вдруг не очень умеете, но хотите научиться. ПК рекомендует, ведь эти знакомства — важная часть конференции!
🔥2
Forwarded from mtsepkov (Maxim Tsepkov)
#DevOpsConf Карапет Манасян из MOEX Group. Сколько стоит платформа? Вопреки названию, доклад - не про деньги, он про процессы, обеспечивающие платформенный подход, которые надо наладить. Конечно, процессы стоят денег, но это не главное. Рассказ был о построении платформенной конструкции в рамках MOEX Group. При этом типовой платформенный подход с полной однородностью процессов и единым технологическим стеком у них не подходит, так как бизнес - существенно гетерогенный, есть торговые решения с длинным релизным циклом, есть финтех с коротким тестированием гипотез и есть критическая инфраструктура со своими требованиям регулятором. Тем не менее, они рассматривают сделанное именно как платформу, а не как работу DevOps инженеров.
Принципиальная разница - в другом взаимодействии с разработкой. Разработка обычно относится к DevOps следующим образом: мы выдаем код, и задача DevOps - дотащить это до прода, как хотите. А платформа предполагает сервисное взаимодействие: команда платформы обеспечивает сервис конвейера доставки, а команды разработки используют этот сервис под свою ответственность. Профит разработки - в том, что команда платформы может обеспечить больший уровень сервиса своим конвейером доставки, чем команда разработки собственными силами. За счет того, что многие команды решают одинаковые задачи и при выносе их в команду платформы срабатывает эффект масштаба.
Это изменение границы - наиболее сложный вопрос, оно требует постоянной поддержки, инвестиций - через сообщества и просвещение. Через сообщества также идет обратное движение, обратная связь и сбор потребностей команд. При этом есть политика компании, побуждающая использовать платформу, но нет жесткого требования, так что решение в значительной мере принимает сама команда. Работа с командами, повышение доверие - одно из направлений. И этот подход побуждает команду платформы реально придумывать полезные фичи и учитывать специфику отдельных продуктов там, где это уместно.
Структура команды платформы: change team, которая помогает командам трансформироваться, собирает запросы и обеспечивает поддержку; feature team доработки платформы и core platform, отвечающая за технологические стандарты и единые политики. Всего в ней 26 человек, еще 8 devops-инженеров в конкретных продуктовых командах, что связано со спецификой отдельных продуктов. Задачи от продуктовых команд поступают тремя способами: таск-трекер, демо-встречи платформы и заявки. Дальше идет анализ, как решить поставленную проблему, что стоит делать в платформе, а что команда может сделать, используя существующие возможности.
Про технологический стек: нет единого требования, если бизнес выбрал некоторое решение и считает его полезным, то они должны уметь включить его в конвейер поставки от платформы. Конвейер поставки - один типовой, дальше команды докручивают. Для платформы опираются на open source решения, но когда вы забираете такие решения внутрь, то вы становитесь владельцем, надо поддерживать и дорабатывать. Часто встречающаяся проблема - развернуть несколько экземлzпров решения в рамках группы, но при этом обеспечить общую авторизацию. Приходится дорабатывать, и это непросто.
Что достигли: единая точка правды инженерных практик - в платформе; от 50+ devops инженеров сократилось до 26; разработчикам стало видно что происходит на проде, эту границу сняли; платформа обеспечивает публикацию по требованию и выделение ресурсов для тестирования. И видно, что с ростом разработки линейного роста команды платформы не происходит, а по devops - было. Инженеров платформы надо обучать внутри, готовой такой специализации на рынке нет, если искать - то в вакансиях надо писать devops, отбирать и это не дешево.
Принципиальная разница - в другом взаимодействии с разработкой. Разработка обычно относится к DevOps следующим образом: мы выдаем код, и задача DevOps - дотащить это до прода, как хотите. А платформа предполагает сервисное взаимодействие: команда платформы обеспечивает сервис конвейера доставки, а команды разработки используют этот сервис под свою ответственность. Профит разработки - в том, что команда платформы может обеспечить больший уровень сервиса своим конвейером доставки, чем команда разработки собственными силами. За счет того, что многие команды решают одинаковые задачи и при выносе их в команду платформы срабатывает эффект масштаба.
Это изменение границы - наиболее сложный вопрос, оно требует постоянной поддержки, инвестиций - через сообщества и просвещение. Через сообщества также идет обратное движение, обратная связь и сбор потребностей команд. При этом есть политика компании, побуждающая использовать платформу, но нет жесткого требования, так что решение в значительной мере принимает сама команда. Работа с командами, повышение доверие - одно из направлений. И этот подход побуждает команду платформы реально придумывать полезные фичи и учитывать специфику отдельных продуктов там, где это уместно.
Структура команды платформы: change team, которая помогает командам трансформироваться, собирает запросы и обеспечивает поддержку; feature team доработки платформы и core platform, отвечающая за технологические стандарты и единые политики. Всего в ней 26 человек, еще 8 devops-инженеров в конкретных продуктовых командах, что связано со спецификой отдельных продуктов. Задачи от продуктовых команд поступают тремя способами: таск-трекер, демо-встречи платформы и заявки. Дальше идет анализ, как решить поставленную проблему, что стоит делать в платформе, а что команда может сделать, используя существующие возможности.
Про технологический стек: нет единого требования, если бизнес выбрал некоторое решение и считает его полезным, то они должны уметь включить его в конвейер поставки от платформы. Конвейер поставки - один типовой, дальше команды докручивают. Для платформы опираются на open source решения, но когда вы забираете такие решения внутрь, то вы становитесь владельцем, надо поддерживать и дорабатывать. Часто встречающаяся проблема - развернуть несколько экземлzпров решения в рамках группы, но при этом обеспечить общую авторизацию. Приходится дорабатывать, и это непросто.
Что достигли: единая точка правды инженерных практик - в платформе; от 50+ devops инженеров сократилось до 26; разработчикам стало видно что происходит на проде, эту границу сняли; платформа обеспечивает публикацию по требованию и выделение ресурсов для тестирования. И видно, что с ростом разработки линейного роста команды платформы не происходит, а по devops - было. Инженеров платформы надо обучать внутри, готовой такой специализации на рынке нет, если искать - то в вакансиях надо писать devops, отбирать и это не дешево.
🔥2👍1
Как «навести порядок в зоопарке» сложного ИТ-окружения? Ответы – на стенде Monq!
Приходите знакомиться с командой, а также:
✔️Примите участие в исследовании о сбоях в ИТ и получите дизайнерский мерч.
✔️Получите эксклюзивный доступ к платформе.
Monq – платформа ИТ-мониторинга и автоматизации для управления состоянием ИТ-окружения любой сложности. Помогает проактивно реагировать на сбои. В «коробке» – мониторинг инфраструктуры и интерфейсов, зонтичный мониторинг, аналитика, low и no-code автоматизация.
Реклама ООО "Монк Диджитал Лаб" erid: LjN8JzKh6
Приходите знакомиться с командой, а также:
✔️Примите участие в исследовании о сбоях в ИТ и получите дизайнерский мерч.
✔️Получите эксклюзивный доступ к платформе.
Monq – платформа ИТ-мониторинга и автоматизации для управления состоянием ИТ-окружения любой сложности. Помогает проактивно реагировать на сбои. В «коробке» – мониторинг инфраструктуры и интерфейсов, зонтичный мониторинг, аналитика, low и no-code автоматизация.
Реклама ООО "Монк Диджитал Лаб" erid: LjN8JzKh6
🔥7
Приходите на стенд Синимекс, чтобы узнать о продуктах компании и пообщаться с техническими экспертами!
Также ребята подготовили для вас:
- активности в квест-боте;
- настольные игры и баланс-борды;
- квиз и лотерею!
Всех гостей стенда ждут призы и хорошее настроение!
Реклама ООО «СИНИМЕКС ДАТА ЛАБ» erid: LjN8KUcL4
Также ребята подготовили для вас:
- активности в квест-боте;
- настольные игры и баланс-борды;
- квиз и лотерею!
Всех гостей стенда ждут призы и хорошее настроение!
Реклама ООО «СИНИМЕКС ДАТА ЛАБ» erid: LjN8KUcL4
🔥5👍1🤩1
🖐 В 15:50 встречаемся на следующих докладах:
⠀
🔸 Зал «Конгресс-холл». Дмитрий Евдокимов (Luntry) «Безопасность Kubernetes-кластеров: вредные советы»
Из доклада в стиле Григория Остера вы узнаете, как не надо настраивать кластер Kubernetes, от маэстро по безопасности K8s Дмитрия Евдокимова.
⠀
🔹 Зал «Кейптаун». Алексей Игнатов (АО "СберТех") «Управление горизонтальным автоскейлингом в on-premise-инсталляциях K8s»
Отличная возможность посмотреть, как фишку автоскейлинга, характерную для облачных провайдеров, можно реализовать в своей onprem-инфраструктуре.
⠀
🔸 Зал «Сингапур». Максим Ванюшкин (Тинькофф) «Kafka. Деградировавший кластер, или 168 часов траблшутинга»
Доклад о решении проблем в Kafka: от низкоуровневого траблшутинга до устранения серьёзных сбоев, угрожающих работе сервисов. Будут освещены сложные конфигурации, инструменты мониторинга, лайфхаки и тонкости, полезные при работе с Kafka для предотвращения неожиданностей в кластере.
⠀
🔹 Зал «Уфа». Илья Кочнев (СберМаркет) «FinOps в Облаках»
Практический опыт построения FinOps в крупной компании на нескольких облаках. Полезно для тех, кто давно хочет внедрить этот подход у себя, но всё руки не доходят.
🔸 Зал «Дели+Калькутта». Виктор Евдокимов (Альфа-Банк) «Kubernetes vs Mesos: как мы кластер из 240 микросервисов мигрировали в кубер из mesos/marathon»
Из доклада вы узнаете о том, какова стоимость миграции с одного оркестратора на другой, какие при этом были сложности и можно ли было их избежать.
⠀
🔹 Зал «Пекин». Виталий Астраханцев (АО "СберТех") «Как мы сделали оркестратор релизного конвейера для 2500+ команд Сбера»
На примере разберётесь, почему был выбран Jenkins, а не GitLab, зачем нужен отдельный оркестратор для CI/CD и какой взгляд у Сбера на дальнейшую роль DevOps-инженеров.
⠀
🔸 Зал «Конгресс-холл». Дмитрий Евдокимов (Luntry) «Безопасность Kubernetes-кластеров: вредные советы»
Из доклада в стиле Григория Остера вы узнаете, как не надо настраивать кластер Kubernetes, от маэстро по безопасности K8s Дмитрия Евдокимова.
⠀
🔹 Зал «Кейптаун». Алексей Игнатов (АО "СберТех") «Управление горизонтальным автоскейлингом в on-premise-инсталляциях K8s»
Отличная возможность посмотреть, как фишку автоскейлинга, характерную для облачных провайдеров, можно реализовать в своей onprem-инфраструктуре.
⠀
🔸 Зал «Сингапур». Максим Ванюшкин (Тинькофф) «Kafka. Деградировавший кластер, или 168 часов траблшутинга»
Доклад о решении проблем в Kafka: от низкоуровневого траблшутинга до устранения серьёзных сбоев, угрожающих работе сервисов. Будут освещены сложные конфигурации, инструменты мониторинга, лайфхаки и тонкости, полезные при работе с Kafka для предотвращения неожиданностей в кластере.
⠀
🔹 Зал «Уфа». Илья Кочнев (СберМаркет) «FinOps в Облаках»
Практический опыт построения FinOps в крупной компании на нескольких облаках. Полезно для тех, кто давно хочет внедрить этот подход у себя, но всё руки не доходят.
🔸 Зал «Дели+Калькутта». Виктор Евдокимов (Альфа-Банк) «Kubernetes vs Mesos: как мы кластер из 240 микросервисов мигрировали в кубер из mesos/marathon»
Из доклада вы узнаете о том, какова стоимость миграции с одного оркестратора на другой, какие при этом были сложности и можно ли было их избежать.
⠀
🔹 Зал «Пекин». Виталий Астраханцев (АО "СберТех") «Как мы сделали оркестратор релизного конвейера для 2500+ команд Сбера»
На примере разберётесь, почему был выбран Jenkins, а не GitLab, зачем нужен отдельный оркестратор для CI/CD и какой взгляд у Сбера на дальнейшую роль DevOps-инженеров.
👏2
Forwarded from mtsepkov (Maxim Tsepkov)
#DevOpsConf Евгений Харченко из Райффайзен Банк. Как DevOps влияет на эффективность организации? Очень интересный доклад о реально наблюдаемой корреляции между показателями инженерной культуры и метриками эффективности. На масштабе 3000 сотрудников в 148 командах. Метрики касаются применения инженерных практик и интегральной производительности по модели DORA. А по культуре - на модель Ron Westrum, которая разделяет три вида: патологическую, бюрократическую и генеративную.
Деление культур опирается на 6 факторов: обмен информацией, сотрудничество, общая ответственность, отношение к ошибкам, анализ причин, улучшения, и для определения генеративной культуры они по каждому фактору сформулировали гипотезы-вопросы, которые предлагают оценить по 5-бальной шкале Лигерта от полностью несогласен до полностью согласен. Гипотезы:
* В командах происходит активный обмен информацией.
* В командах происходит взаимодействие ролей.
* Есть общая ответственность за продукт и платформу
* В командах свободно делятся информацией об ошибках и неудачах, не опасаются осуждения
* В командах Проводятся анализы причин проблем, ошибок и неудач
* В командах приветствуются новые идеи по улучшению процессов
Кроме оценки к каждому фактору есть дополнительный вопрос: надо проиллюстрировать вашу оценку примерами, например, в чем проявляется или не проявляется общая ответственность. Для таких вопросов есть варианты ответов со множественным выбором и можно написать свое.
Что интересно, средний индекс культуры хорошо коррелирует с инженерными практиками и метриками производительности. В общем-то, так и должно быть, ведь не зря говорят, что devops - это культура. Однако, многие к этому относятся скептически. Метрики показывают ,что это - не так, и работа с культурой - важная составляющая. Результат работы с которой можно измерить. Ну, с точностью до того, что люди начнут подделывать ответы, но это - тоже часть культуры. Но корреляция - побочный результат. Опрос - не для этого, а чтобы увидеть картину в целом, выделить точки роста и аномалии. И успешно работать с ними.
Деление культур опирается на 6 факторов: обмен информацией, сотрудничество, общая ответственность, отношение к ошибкам, анализ причин, улучшения, и для определения генеративной культуры они по каждому фактору сформулировали гипотезы-вопросы, которые предлагают оценить по 5-бальной шкале Лигерта от полностью несогласен до полностью согласен. Гипотезы:
* В командах происходит активный обмен информацией.
* В командах происходит взаимодействие ролей.
* Есть общая ответственность за продукт и платформу
* В командах свободно делятся информацией об ошибках и неудачах, не опасаются осуждения
* В командах Проводятся анализы причин проблем, ошибок и неудач
* В командах приветствуются новые идеи по улучшению процессов
Кроме оценки к каждому фактору есть дополнительный вопрос: надо проиллюстрировать вашу оценку примерами, например, в чем проявляется или не проявляется общая ответственность. Для таких вопросов есть варианты ответов со множественным выбором и можно написать свое.
Что интересно, средний индекс культуры хорошо коррелирует с инженерными практиками и метриками производительности. В общем-то, так и должно быть, ведь не зря говорят, что devops - это культура. Однако, многие к этому относятся скептически. Метрики показывают ,что это - не так, и работа с культурой - важная составляющая. Результат работы с которой можно измерить. Ну, с точностью до того, что люди начнут подделывать ответы, но это - тоже часть культуры. Но корреляция - побочный результат. Опрос - не для этого, а чтобы увидеть картину в целом, выделить точки роста и аномалии. И успешно работать с ними.
👍1
В 16:50 в Зале «Шанхай» начнётся Fail-митап, приходите
Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе! В своих коротких, но зажигательных выступлениях спикеры поделятся настоящими историями фейлов. Без записи, без трансляции, без комплексов.
Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе! В своих коротких, но зажигательных выступлениях спикеры поделятся настоящими историями фейлов. Без записи, без трансляции, без комплексов.
🔥2
🖐 Друзья, в 17:00 ждём вас на последних докладах первого дня DevOpsConf 2024:
🔸 Зал «Конгресс-холл». Анна Атрошкина (Index) «Что ты сделал для DevOps'а в свои годы... по мнению рекрутера»
В докладе будут подробно освещены методы работы рекрутеров: как происходит поиск кандидата, его «верификация» на предмет правдивости профиля. У вас сформируется картина построения своего профиля для максимального совпадения предложений со стороны рекрутеров со своими потребностями.
🔹 Зал «Кейптаун». Павел Сушин (Яндекс) «Динозавр в магазине: опыт публикации YTsaurus в YC.Marketplace»
Если вы думаете, как опубликовать свое приложение в YC.Marketplace и что для этого потребуется сделать со своим непростым приложением, то этот доклад для вас.
🔸 Зал «Сингапур». Дмитрий Анисов (GS Labs) «История отказа ceph. Как была потеряна часть данных»
Интересная история про то, как докладчик чинил ceph, с выводами о том, как можно было избежать аварии.
🔹 Зал «Уфа». Варвара Подольская (Независимый эксперт) «ChatGPT: декларативная автоматизация»
Как генерировать не пару кусочков Terraform из ChatGPT и потом переписывать половину предложенного чатом, а сгенерировать всю инфраструктуру проекта. Про переменные и ресурсы при генерации, а также что еще нужно будет поменять в своем мышлении и подходах. Плюс best practices.
🔸 Зал «Дели+Калькутта». Владимир Романов (Райффайзен Банк) «K8s as a Self Service — как штамповать кластеры»
Доклад предлагает погружение в стратегии эффективного масштабирования кластеров Kubernetes при необходимости создания множества экземпляров. Спикер расскажет про эволюцию от ручной конфигурации с помощью Kubespray к более автоматизированному подходу через Cluster API.
🔹 Зал «Пекин». Роман Володин (Ozon) «REpublic — управляй релизами в едином окне»
На примере опыта Романа вы узнаете, с какими проблемами можно столкнуться при выстраивании системы автоматизации релизов, как именно можно упростить доставку изменений в продакшн, что такое сущность релиза, зачем её определять и как ими удобнее всего управлять.
🔸 Зал «Конгресс-холл». Анна Атрошкина (Index) «Что ты сделал для DevOps'а в свои годы... по мнению рекрутера»
В докладе будут подробно освещены методы работы рекрутеров: как происходит поиск кандидата, его «верификация» на предмет правдивости профиля. У вас сформируется картина построения своего профиля для максимального совпадения предложений со стороны рекрутеров со своими потребностями.
🔹 Зал «Кейптаун». Павел Сушин (Яндекс) «Динозавр в магазине: опыт публикации YTsaurus в YC.Marketplace»
Если вы думаете, как опубликовать свое приложение в YC.Marketplace и что для этого потребуется сделать со своим непростым приложением, то этот доклад для вас.
🔸 Зал «Сингапур». Дмитрий Анисов (GS Labs) «История отказа ceph. Как была потеряна часть данных»
Интересная история про то, как докладчик чинил ceph, с выводами о том, как можно было избежать аварии.
🔹 Зал «Уфа». Варвара Подольская (Независимый эксперт) «ChatGPT: декларативная автоматизация»
Как генерировать не пару кусочков Terraform из ChatGPT и потом переписывать половину предложенного чатом, а сгенерировать всю инфраструктуру проекта. Про переменные и ресурсы при генерации, а также что еще нужно будет поменять в своем мышлении и подходах. Плюс best practices.
🔸 Зал «Дели+Калькутта». Владимир Романов (Райффайзен Банк) «K8s as a Self Service — как штамповать кластеры»
Доклад предлагает погружение в стратегии эффективного масштабирования кластеров Kubernetes при необходимости создания множества экземпляров. Спикер расскажет про эволюцию от ручной конфигурации с помощью Kubespray к более автоматизированному подходу через Cluster API.
🔹 Зал «Пекин». Роман Володин (Ozon) «REpublic — управляй релизами в едином окне»
На примере опыта Романа вы узнаете, с какими проблемами можно столкнуться при выстраивании системы автоматизации релизов, как именно можно упростить доставку изменений в продакшн, что такое сущность релиза, зачем её определять и как ими удобнее всего управлять.