2010 2011 2012 2013 2014 2015 2016 2017 2018

Сколько «ой» в слове «деплой», когда один продукт делает 17 команд

Тема CI\CD давно не нова, и наверняка многие уже внедрили у себя в проектах эти практики хотя бы частично. Ежедневные или даже более частые деплои дают продукту большую маневренность и экономят время разработки, т.к. интегрироваться небольшими инкрементами проще. Никого уже не удивляет, что на смену продолжительным ручным регрессиям и редким релизам пришли интенсивная автоматизация тестирования и различные механики интеграции кода.
  • Но что делать, если деплоить хочется каждый день, а у вас монолитный продукт и над ним работает одновременно 17 команд?
  • Как быстро интерпретировать результаты прогона тысяч автотестов на разных уровнях пирамиды тестирования из разных зон технической и продуктовой ответственности?
  • Как понять, кто виноват и какие задачи необходимо исключить из релиза?
  • Как устроить процесс так, чтобы даже тестировщик-новичок в компании мог задеплоить свою фичу без группы поддержки, не боясь положить прод?
Я расскажу, как мы ответили на эти вопросы для себя. Какие проблемы решили, из каких кирпичиков, которые можно переиспользовать независимо друг от друга по необходимости, состоит наше решение, и какое участие во всем этом принимает отдел тестирования.

Партнёры