Трансформация DevOps — прошибая стены / Константин Пакулин (Odin)
•Transferir como PPTX, PDF•
0 gostou•409 visualizações
HighLoad++ 2017 Зал «Пекин+Шанхай», 7 ноября, 12:00 Тезисы: http://www.highload.ru/2017/abstracts/2915.html Многие знают про continuous delivery, про скорость доставки фич, и как с нуля строить проекты с мгновенной доставкой до продакшна, используя современный инструментарий. Но что делать, когда у вас успешный продукт с 15-летней историей, с миллионами строчек кода, со множеством крупных партнеров, и вдруг вы обнаруживаете, что в среднем путь фичи от идеи до установки на инсталляцию партнера занимает 2 года? А бизнес хочет быстрее. ...
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Ontico
Mais de Ontico (20)
Трансформация DevOps — прошибая стены / Константин Пакулин (Odin)
- 2. 2 Года
- 3. Что за продукт ? OSS BSS User management Hardware inventory Service management Product catalogue Customers management Order management Online store 200+ 20М+ BSSOSS Платформа S PA BSSOSS Платформа BSSOSS Платформа 150+
- 4. OSS BSS История 2 Года User management Hardware inventory Service management Product catalogue Customers management Order management Online store 1 неделя1 месяц4 месяца1 год вася данила петя коля равшан и джамшут
- 7. данила вася end-2-end тесты красные тесты хрупкие регулярный запуск зеленые тестыдолгий разбор нечитаемые тесты рост долга BDD запуск тестов до мержапробная команда новые фичи с тестами UNIT тесты-ы тесты часть продукта контроль покрытия контроль деградации разработчик автотесты адаптация тестов вместе с кодом вводить с новых фич следить за деградацией Нет! отдельной команды контроль деградации тесты часть продукта новые фичи с тестами
- 8. да, это - петя петя вася KPI – быстро закомитить код элементарные проблемы долгий фидбэк Initial Quality Rating Тестирование в бранчах PM смотрит до QA Test design c QA экспертом Первичное тестирование разработчик QA test design Нет! Отдельной команде Test design с QA экспертом
- 9. вася коля дуплицирование систем непереиспользуемо нет фокуса на стабильность единый статус репортинг единый деплоймент пишем костяк процесса помогаем внедрять компоненту ответственность за продакт специфичный код в команде разработки участие в дизайне фич DEV PS дать удочку, а не рыбу Нет! Отдельной команде Да! Правильной команде команда команда пишем костяк процесса помогаем внедрять компоненту DEV PS
- 10. Что в итоге? вася & коля данила петя
- 11. Что в итоге? фича готова фича старт 8 месяцев 2 месяца DEV PS
- 13. Что дальше? 6 месяцев DEV PS релиз тестирование деплой HL++ 2018 1 месяц ??? недель, дней, часов continuous deployment feature toggling release per feature
Notas do Editor
- ? Нужно ли объяснять про два года ? –> если бы это было 20 лет назад то нет Почему 2 года – это проблема … убивает ответсвенность -> не видят результаты труда Невозможно эксперементировать –> цена ошибки очень большая
- Наше отличие от большинства современных клауд проектов .. .много платформ
- Вначале: девелопер получал прямой фидбэк от заказчика .. Хорошо он сделал или нет Затем стало больно и дорого ломать,
- Расскажим про сжатие dev И получение готовых фич чаще <Cжимаем картинку> … показать сжатие опса – но про это в следующий раз
- Детали проблемы Выпадание из контекста Долгая доработка фичи в багофикс режиме Не могут переключится на другой релиз Не гибкость ресурсов …
- Вася = Dev, Петя = AQA, Коля? Настя? = QA, Данила = DevOps История про появление тестов … быстро и много QA -> тесткейзы … автоматизация в прямую Тесты на 200 шагов Быстрое покрытие ё Рост долга -> отдельная команда -> 30% на новые тесты 33 человеко года 3. Стена … Почему стена между автотестами и дев -> ??? … потому что KPI и это не моя работа 4. Запуск до мержа -> спор двух подходов .. Починка в транке .. Починка в бранче … история про двух заключенных 5. команда с тестами 130 блокеров в месяц (6 в день) … (3 в день) 6. Натянули на все команды … изменение фрэймворков – 7. Контроль деградации … как вы глядит ?
- Вначале прекрасно Разработчики расслабляются когда появляется кто то кто тестирует… Стена -> Долгий фидбэк –> история про 5ть багов Тестирование в бранчах Баги рождающие еще баги … Что такое тестабельная фича? Как разработчику надо правильно думать о том, как сделать фичу тестабельной? истории эволюции разработчика и решений, которые он принимал по этому вопросу.
- Стена – не могу использовать инструмент -> протестируй за меня … меняю свое игнорирую чужое Стена DevOps -> стали сгружать процессы и поддержку своих компонент Баг, который сто раз переназначали туда-сюда … что за баг ? Windows templates -> update-ы фасадим разность команд в одном инструменте…