- В пятницу никто не релизит
- И это неправильно
- Решение: стабильный набор автотестов
- И исследовательское
- Автоматизация сборки и деплоя
В пятницу никто не релизит
Если у вас есть правило «никогда не релизить ничего в пятницу», это сигнализирует о качестве всей вашей команды и организации тестирования.
Представьте себе утро пятницы. Ваша команда усердно трудились над завершением последнего спринта, почти все готово к работе. Команда QA протестировала приложение. После последней проверки выяснилось, что в приложении нет багов, блокирующих релиз. Команде разработчиков очень хочется как можно скорее выпустить новый функционал, они не могут дождаться момента, когда их код попадет на продакшен. Осталось только запустить процесс деплоя, и можно праздновать.
Однако никто не хочет начинать этот процесс. Кажется, никто не хочет поднимать эту тему — все надеются, что остаток рабочей пятницы пройдет быстро и спокойно, и все смогут уйти наконец на выходные. Наконец, джун задает вопрос, который никто не хотел услышать:
«… так… давайте, наверное, релизить?».
В большинстве команд, задав этот вопрос в пятницу, вы заставите своих коллег усомниться в вашем психическом здоровье. Если вы работали в сфере разработки программного обеспечения, скорее всего, вы слышали фразу «Мы никогда не релизимся в пятницу». Ее повторяют так часто, что на данный момент она стала широко распространенным мемом:
Я понимаю эти настроения. Никто не хочет рисковать, тушить пожары в субботу или воскресенье — вполне вероятно, что придется вскакивать и исправлять поломанный релиз. Любой деплой может подождать несколько дней (если это, конечно, не фикс блокера), чтобы команда могла прийти после выходных и иметь больше времени для решения любых потенциальных проблем.
Однако я твердо убежден, что отношение большинства команд разработчиков и тестировщиков «ради бога, не деплойте по пятницам» — это неправильное отношение, от которого нужно избавляться, если вы хотите создавать качественный продукт.
Почему избегать пятничных релизов — вредная привычка для качества
Причина, из-за которой команда избегает пятничных релизов как чумы, обычно сводится к недостатку уверенности в своем приложении, процессах или и том, и другом. Нежелание обычно проистекает из того, что команда должна быть на 100% уверена, что ее приложение готово к использованию клиентами. Каждый раз, когда кто-то говорит: «Мы не будем релизиться в пятницу», он имеет в виду: «Мы не доверяем нашему приложению или процессам».
В долгосрочной перспективе такая мысль не приведет к созданию качественной системы. Команды редко трактуют это чувство неуверенности как сигнал о том, что им нужно сосредоточиться на улучшении качества. Независимо от того, является ли отсутствие доверия и уверенности реальной проблемой или мнимой, большинство команд выбирают легкий путь, игнорируя проблемы и предпочитая их маскировать. Вместо того чтобы тратить время на поиск улучшений, они придумывают правила вроде «пятниц без деплоя».
Вместо того чтобы избегать деплоев в конце недели, лучше решать проблему неуверенности и совершенствовать процессы, чтобы дать командам возможность релизить в любое вермя. В таком случае, разработчики и тестировщики не будут беспокоиться о том, что их выходные будут прерваны из-за потенциальных проблем с релизом.
Любая организация, серьезно настроенная на обеспечение качества в своих командах и продуктах, должна иметь такую уверенность в своей компании. Хотя для того, чтобы почувствовать полную уверенность в своих системах, требуется время, хорошая новость заключается в том, что это под силу каждому, независимо от того, насколько сложными, по его мнению, являются приложения и процессы в его организации. Следующий план поможет вам добиться этого быстрее, чем вы думаете.
Шаг 1: Внедрите стабильный набор автотестов.
Набор автоматизированных тестов — обязательное условие для любой команды, желающей быстро создавать и релизить свои приложения без постоянного чувства беспокойства. Без автотестов вы сильно подрываете способность вашей команды уверенно работать и релизить приложения. Если вы не выделяете себе или своей команде достаточно времени для расширения покрытия приложения автотествами, вы намеренно ставите себя в невыгодное положение.
Первый шаг для любой организации по улучшению уровня качества — это сосредоточиться на достаточном тестовом покрытии критического функционала вашего приложения, поэтому если вы начинаете с нуля, сосредоточьтесь на этом шаге. Однако еще более важным фактором, чем покрытие, является стабильность. Даже при полном покрытии автоматизация тестирования не принесет пользы, если она постоянно сбоит. Если у вас нестабильные тесты, вы не сможете чувствовать себя комфортно при релизе в любое время, а тем более по пятницам. Работая над покрытием тестов, сконцентрируйтесь на создании надежного, поддерживаемого набора тестов — это позволит команде чувствовать себя увереннее при релизах.
Еще одна область, на которой следует сосредоточиться, — это тип тестирования. В зависимости от потребностей вашего приложения, вам, скорее всего, понадобится сочетание различных автоматизированных тестов. Некоторые команды пишут небольшой набор unit-тестов и на этом все заканчивается, но современные приложения имеют множество модулей, которые необходимо проверять. End-to-end тесты, тестирование производительности, обеспечение безопасности и доступности — это лишь верхушка айсберга. Заранее спланируйте, какие виды автоматизированных тестов могут принести пользу вашей организации.
Разберитесь, какие виды тестов вам нужны и какие области вы хотите охватить. Наличие стабильного набора автоматизированных тестов укрепит уверенность вашей команды в ваших приложениях и деплоях.
Шаг 2: Не забывайте об исследовательском тестировании
Когда команды приобретают привычку создавать стабильные автоматизированные тесты для своих приложений, они могут стать слишком самоуверенными в способности своих тестов отлавливать проблемы до деплоя. Часто ложное чувство уверенности приводит к тому, что люди начинают думать, что им не нужно дополнительно тестировать релиз вручную. Это ощущение ложно. Независимо от того, насколько хороши ваши навыки автоматизации тестирования или насколько большое покрытие обеспечивают ваши письменные тесты, вы не можете игнорировать важность ручного, исследовательского тестирования.
Автоматизированные тесты могут делать только то, что им говорят делать, и хорошо подходят для выявления регрессий во время быстрых циклов разработки. С другой стороны, ручное и исследовательское тестирование позволит вам заглянуть в «слепые зоны» ваших автотестов и обнаружить проблемы в тех областях, на которые никто и не думал обращать внимание. Пренебрежение этой важной частью тестирования в ситуациях, когда вы полагаетесь исключительно на автоматизацию, неизбежно приводит к получению продукта низкого качества.
Ручное тестирование требует времени и усилий для качественного выполнения. Некоторые команды, особенно небольшие, не имеющие выделенной команды QA, склонны проводить такие тесты в последний момент. Большинство стартапов, в которых я работал, проводят разведочное тестирование только за несколько дней или даже часов до деплоя. Иногда это срабатывает, но это рискованно — вы будете спешить и можете упустить проблемы.
В идеале ручное исследовательское тестирование должно проводиться последовательно в течение всего цикла разработки команды, когда новые сборки выкладываются на стейджинг1. Дайте вашей организации время для проведения такого тестирования, и вы обнаружите, что меньше беспокоитесь о деплоях в любое время.
Шаг 3: Внедрение автоматизированного процесса сборки и деплоя
Одной из частей цикла разработки и выпуска релизов, о которой часто забывают в командах, создающих программное обеспечение, является процесс сборки и развертывания. В некоторых местах, где я работал, создание и деплой нового релиза кажется почти мистическим процессом, который могут выполнить только несколько избранных. Деплой в таких командах обычно состоит из длинного процесса шагов, выполняемых в точном порядке с почти идеальным таймингом. Если человек, выполняющий это ритуальное действие, поскользнется на этом пути, хрупкость процесса может в одно мгновение обвалить все приложение.
То, как я описываю этот процесс, возможно, несколько преувеличено, но очень близко к истине. Многие компании, с которыми я работал, имеют неоправданно сложные процедуры деплоя. Когда их спрашивают, почему, некоторые команды пытаются обосновать, почему все должно быть именно так, как есть, но подтекст их ответа на самом деле означает «Мы всегда делали это так, поэтому никогда не меняли». Общая причина заключается в том, что кто-то давным-давно создал этот сложный процесс. Поскольку он работает — независимо от того, насколько запутанным стал процесс — они никогда не думали о том, чтобы его улучшить.
Независимо от того, сколько движущихся частей содержит вся ваша система, вы можете автоматизировать практически любой процесс деплоя. Сегодня у нас есть масса отличных инструментов, позволяющих автоматизировать процесс сборки и развертывания: Jenkins, AWS CodePipeline, CircleCI и многие другие. У вашей организации нет оправданий, чтобы не автоматизировать деплои.
Не менее важной частью процесса развертывания является откат неудачного релиза. Несмотря на хорошо поставленный процесс тестирования, релиз все равно может оказаться неудачным. Большинство команд обнаруживают, что у них нет никаких стратегий отката, когда релиз не удается и приложение не работает. Прежде чем это произойдет, разработайте стратегию отката, подходящую для вашего приложения, и часто тестируйте ее, чтобы закон Мерфи не застал вас врасплох.
Итоги
Просить разработчика или тестировщика программного обеспечения деплоить по пятницам принято считать серьезным грехом. Большинство команд отказываются развертывать что-либо в пятницу, опасаясь, что что-то сломается и придется работать в выходные. Хотя это вполне разумный поступок, такое отношение обычно вызвано отсутствием уверенности в процессах деплоя в организации. В большинстве случаев страх перед тем, что новый релиз сломает систему, относится не только к пятничным, но и к любым другим релизам. Такие настроения не способствуют повышению качества.
Если ваша команда относится к деплою как к очень хрупкой и нестабильной процедуре, которая может все поломать, вы можете сделать несколько шагов, чтобы укрепить доверие к этому процессу:
- Иметь стабильный набор автоматизированных тестов, который обеспечивает правильное сочетание типов тестирования и покрытия для выявления проблем до выхода в продакшен.
- Выработайте постоянную привычку проводить ручное исследовательское тестирование, чтобы обнаружить ошибки, которые не находит автоматизация.
- Наконец, автоматизируйте этапы деплоя и убедитесь, что вы можете откатить любой релиз. Ни один процесс не совершенен, и, скорее всего, будут случаи, когда вам придется откатывать изменения.
Благодаря этим шагам ваша команда будет готова быстро решить проблему в тех редких случаях, когда что-то пойдет не так. Как только вы внедрите некоторые из этих предложений (или все), вы заметите, что качество ваших приложений повысится. Что еще более важно, это повысит уверенность команды в своих силах.
Цель этой статьи не в том, чтобы ваша команда деплоила каждую пятницу, а в том, чтобы дать им возможность делать это при необходимости без каких-либо опасений. Возможность деплоя без опасений, что что-то, образно говоря, взорвется, позволяет каждому разработчику и тестировщику иметь на одну заботу меньше во время цикла разработки. И, возможно, нам будет попадаться меньше мемов о пятничных релизах.
—
1стейджинг — это такая среда, в которой происходит проверка перед боем. Её особенностью является максимальное приближение к условиям боевой среды, что дает возможность полнее протестировать то, что происходит. Обычно это то место, куда идут менеджеры, тестировщики, заказчики
