Обеспечение качества и процессы доставки программного обеспечения во фронтенд-инжиниринге
Как мы улучшили SDLC веб-приложений в Azimo
Это первая статья из серии сообщений в блоге, в которых мы описываем наши процессы обеспечения качества и разработки программного обеспечения для разработки интерфейса в Azimo.
Вторая запись в блоге уже опубликована здесь.
Существует большая разница между контролем качества и обеспечением качества. QC фокусируется в основном на выполнении требований к качеству. Он гарантирует, что конечный продукт работает должным образом и не содержит ошибок.
Гарантия качества — это гораздо больше. Сосредоточив внимание на всем процессе, он укрепляет уверенность инженеров в качестве, повышает эффективность тестирования и разработки и тем самым позволяет нам быстрее поставлять продукцию небольшими партиями. Конечными целями QA являются улучшение процессов SDLC, масштабируемость команды и гибкость. Качественные и безглючные продукты являются (только) производными от этого.
Как сказано в книге Accelerate: The Science of Lean Software and DevOps и связанных с ней отчетах State of DevOps:
«Скорость и стабильность — это результаты, которые дополняют друг друга».
Помня обо всем этом, мы уделяем много времени развитию культуры контроля качества в команде Frontend Engineering в Azimo. В этой серии сообщений в блоге подводятся итоги наших достижений и ключевых изменений в процессе, которые мы внесли за последние годы.
Отправная точка
Несколько лет назад наши веб-приложения разрабатывались по следующим принципам:
- Еженедельный цикл выпуска — каждое наше приложение выпускалось раз в неделю,
- Перед выпуском все функции были объединены в ветку разработки, которую затем мы протестировали, исправили и отправили в производство.
- Каждый выпуск был полностью протестирован нашим QA-инженером, который дал команде зеленый свет 🚦 для запуска,
- Мы не освобождались по пятницам, чтобы хорошо выспаться на выходных.
Сегодня этот процесс кажется далеким от совершенства. Но после нескольких лет в хаотической среде, похожей на стартап, это сослужило нам хорошую службу. У нас был регулярный цикл релизов, что повысило предсказуемость инженерной работы. Еженедельный цикл релизов вынуждал нас выпускать вещи небольшими порциями, которые было легче тестировать и генерировать меньше ошибок. И хотя со временем мы столкнулись с некоторыми ошибками, мы смогли выявить и исправить их гораздо быстрее. Быстрый и стабильный цикл выпуска также помог нам распараллелить нашу работу, поэтому наши фронтенд-инженеры могли одновременно работать над другой частью нашего продукта.
Но этот процесс имел ряд серьезных ограничений. Согласно правилу «в пятницу выпусков не будет», разработка должна была быть завершена в среду, а тестирование и выпуск запланированы на четверг. Если мы находили какие-либо ошибки, то либо исправления делались в спешке, либо релизы переносились на следующую неделю.
Автоматизация тестирования выпущенных функций осталась в бэклоге из-за нехватки времени. Наш процесс тестирования был в основном сосредоточен на ручных проверках. Да, это довольно противоречиво — мы не смогли построить автоматизацию, которая увеличила бы нашу скорость. Мы не успели сэкономить время 🤷♀️. Так почему это было?
С фиксированным циклом выпуска и одной веткой разработки наша очередь тестирования и выпуска начала расти. В часы пик мы объединяли многие функции в разработку (не говоря уже о других, ожидающих объединения). Несмотря на то, что еженедельный цикл релизов был удобен для разработчиков программного обеспечения и приводил к небольшим изменениям, вещи складывались в большие кандидаты на релизы. Нашей инженерной команде QA очень часто приходилось тестировать несколько функций, даже не связанных друг с другом.
Результаты?
- Наши ветки функций провели более 40 часов на этапе тестирования (медиана для статуса «в тестировании»). В худшем случае этот процесс может занять сотни часов.
- В нашей очереди тестирования и выпуска было несколько десятков функций, которые находились в ветках функций, иногда даже в течение нескольких недель.
- Количество изменений, не прошедших фазу «в тестировании», начало неконтролируемо расти (хотя многие из них были «изменениями в 1 строку», риск появления багов в продакшене рос)
Наш процесс контроля качества и выпуска сегодня
За последние годы мы улучшили наши процессы доставки и пришли к следующим принципам:
- Разработка и тестирование выполняются на ветках функций — наш подход близок к разработке на основе магистралей, с короткоживущими ветками функций, которые полностью тестируются, а затем развертываются непосредственно в рабочей среде.
- Мы можем выпускать функции практически сразу после завершения разработки — не больше недельного цикла выпуска, не больше нескольких десятков часов, потраченных на «тестирование».
- Большинство выпусков не нужно проверять QA-инженерам — вручную или с помощью автоматических тестов. Благодаря культуре QA каждый инженер в равной степени отвечает за качество нашего продукта.
Сегодня, несмотря на то, что численность команды не изменилась, мы можем выпускать наше приложение несколько раз в день. Нет больше очереди тестирования и выпуска. Больше никаких развертываний в рабочей среде без тестирования кода. Поскольку все инженеры брали на себя ответственность за качество нашего продукта, мы сталкивались с меньшим количеством ошибок. И всякий раз, когда мы обнаруживаем какую-либо проблему на этапе тестирования, это не мешает другим разработчикам выпускать свои изменения (поскольку у нас нет единой ветки develop, где все функции объединяются перед окончательным этапом тестирования и выпуска).
По нашим данным, мы выпускаем в 2–3 раза чаще, чем два года назад.
Наши веб-приложения также более стабильны: большую часть времени безотказность превышает 99,9%.
Все эти достижения позволяют нам быстрее перерабатывать наш продукт и разблокировать такие инициативы, как автоматические обновления зависимостей, описанные ранее в нашем блоге.
Что мы сделали
Изменения в процессе доставки и переход от контроля качества к обеспечению качества не происходят в одночасье. Вот список инициатив и внедрений, которые помогли нам перейти от запланированных еженедельных выпусков к непрерывной доставке:
- Сосредоточьтесь на пирамиде тестирования, улучшив покрытие модульными тестами.
- Лучшая автоматизация функционального и сквозного тестирования:
- — Кроссбраузерное тестирование,
- — Визуальное регрессионное тестирование,
- — Сквозные тесты для пограничных сценариев
- Сосредоточьтесь на уменьшении шелушения
- Автоматизация сложных потоков тестирования (например, потоки электронной почты, протестированные с помощью Mailosaur)
В следующем посте блога мы подробно рассмотрим каждый из них.
Следите за обновлениями!
Благодарности
Все наши достижения, описанные в этой серии статей, были бы невозможны без тяжелой работы всей команды веб-инженеров. Самые большие заслуги принадлежат Агне Баранаускайте, инженеру по обеспечению качества, и Артуру Кании, менеджеру по разработке программного обеспечения. Вместе с веб-командой они заложили основу для изменений, описанных в этой серии.
К финансовым услугам, доступным для всех
Мы работаем во всей компании, чтобы создавать более быстрые, дешевые и более доступные финансовые услуги по всему миру, и вот некоторые из методов, которые мы используем. Нам еще предстоит пройти долгий путь, и если вы хотите принять участие в этом путешествии, загляните на нашу страницу вакансий.
