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