Не бойтесь деплоить в пятницу
Если вы придерживаетесь правила никогда не деплоить по пятницам, вы транслируете неправильный месседж о качестве вашей команде и компании.
Представьте — утро пятницы в офисе. Вы с командой усердно трудились над завершением последнего спринта, и все почти готово к работе. Команда QA провела проверки. Последняя проверка выявила, что в приложении нет ошибок, сдерживающих работу команды. Продуктовая команда долго ждала выпуска новых фич и исправления раздражающих багов, и они не могут дождаться момента, когда смогут увидеть конечный результат. Осталось только запустить процесс развертывания, и можно начинать праздновать.
Однако никто не хочет этот процесс начинать. Кажется, что никто даже не решается поднять эту тему, в надежде, что следующие несколько часов пролетят быстро, и наконец начнутся выходные. Но вот новый член команды задает вопрос, который никто не хотел слышать:
«. так. мы будем деплоить в продакшн?»
В большинстве компаний, если вы зададите этот вопрос в пятницу, некоторые из членов команды ответят раздраженным взглядом, а другие усомнятся в вашем здравомыслии. Если вы работали в сфере разработки программного обеспечения, скорее всего, вы не раз слышали фразу «Мы никогда не деплоим в пятницу». Ее повторяют так часто, что она уже стала мемом:
Я полностью понимаю эти настроения. Никто не хочет рисковать и жертвовать своим свободным временем в выходные дни, если придется срываться на работу и исправлять неудачный деплой. За исключением по-настоящему срочных багфиксов любой деплой может подождать несколько дней, чтобы команда пришла отдохнувшей после выходных и имела больше времени для решения любых потенциальных проблем.
Однако я твердо убежден, что такое отношение большинства команд разработчиков и тестировщиков к развертыванию в пятницу — это не то отношение, которое нужно развивать в компании, если вы хотите создать высококачественное приложение.
Почему избегание пятничного деплоя является вредной привычкой для качества
Когда команда избегает пятничного деплоя как чумы, это обычно сводится к недостатку уверенности в своем приложении, процессах или и том, и другом. Нежелание обычно проистекает из того, что компании необходимо знать или верить, что их приложения готовы к использованию клиентами. Каждый раз, когда кто-то говорит: «Мы не будем развертывать приложение в пятницу», на самом деле он имеет в виду: «Мы не настолько доверяем нашему приложению или процессам, чтобы деплоить в пятницу».
В долгосрочной перспективе такое мышление не приводит к созданию высококачественных систем. Команды не часто используют это чувство неуверенности как сигнал о том, что им нужно сосредоточиться на улучшении. Независимо от того, является ли неуверенность реальной проблемой или мнимой, большинство команд выбирают легкий путь, игнорируя проблемы и предпочитая маскировать их. Вместо того, чтобы тратить время на поиск улучшений, они придумывают правила вроде «пятницы без деплоя».
Вместо того, чтобы избегать деплоя в конце недели, как насчет того, чтобы решить проблемы и усовершенствовать существующие процессы, чтобы дать командам свободу деплоя в любое удобное для них время? Наверняка разработчикам или тестировщикам понравится не беспокоиться о том, что их выходные под угрозой их-за пятничного деплоя?
Любая организация, серьезно настроенная на обеспечение качества продукта в своих командах, должна развивать такую уверенность. Хотя для того, чтобы почувствовать полную уверенность в своих системах, требуется время, хорошая новость заключается в том, что это под силу каждому, независимо от того, насколько далекими от идеала являются приложения и процессы в его компании. Следующий трехэтапный план поможет вам добиться этого быстрее, чем вы думаете.
Шаг 1: Внедрите стабильный набор автоматизированных тестов
Наличие набора автоматизированных тестов — обязательное условие для любой команды разработчиков, которая хочет быстро создавать и внедрять приложения без постоянного беспокойства о них. Без него вы сильно подрываете способность команды уверенно работать и деплоить. Если вы еще не предоставили себе или своей команде пространство для работы над расширением покрытия автотестами, вы намеренно ставите себя в невыгодное положение.
Чтобы повысить уровень качества, первым делом необходимо сфокусироваться на обеспечении достаточного тестового покрытия критических путей приложения, поэтому, если вы начинаете с нуля, сосредоточьтесь на этом шаге. Однако еще более важным, чем покрытие, является стабильность. Даже при полном покрытии автоматизация тестирования не принесет пользы, если она постоянно сбоит. Если у вас нестабильные тесты, вы не сможете чувствовать себя комфортно при развертывании в любое время, а тем более по пятницам. Работая над тестовым покрытием, сосредоточьтесь на создании надежного и поддерживаемого тест-сьюта, чтобы сохранить уверенность команды надолго.
Еще одна область, на которой следует сосредоточиться, — это тип тестирования. В зависимости от потребностей приложения, вам понадобится сочетание различных автоматизированных тестов. Некоторые команды пишут несколько юнит-тестов и на этом все заканчивается, но у современных приложений множество изменяющихся частей, которые необходимо проверять. End-to-end тесты, проверка производительности, обеспечение безопасности и доступности — это лишь верхушка айсберга. Заранее спланируйте, какие типы автотестов могут принести пользу.
Помните, какие виды тестов вам нужны и какие области вы хотите охватить. Наличие стабильного набора автоматизированных тестов с правильным сочетанием тестов укрепит уверенность вашей команды в приложении и деплоях.
Шаг 2: Не забывайте о ручном исследовательском тестировании
Когда команды приобретают привычку создавать стабильные автоматизированные тесты для своих приложений, может появиться риск стать излишне самоуверенными в способности тест-сьюта отлавливать ошибки до развертывания. Часто ложное чувство уверенности приводит к тому, что команда начинает думать, будто им не нужно проводить дополнительное тестирование с помощью методов автоматизации тестирования. Это ложная мысль. Независимо от того, насколько хороши ваши навыки автоматизации тестирования или насколько большое покрытие обеспечивают написанные тесты, нельзя игнорировать важность ручного исследовательского тестирования.
Автоматизированные тесты могут делать только то, что им сказано делать, и хорошо подходят для выявления регрессий во время быстрых циклов разработки. Ручное и исследовательское тестирование позволяет заглянуть в «слепые зоны» автоматизированных тестов и обнаружить проблемы в тех областях, на которые никто и не думал обращать внимание — так называемые «неизвестные неизвестные». Пренебрежение этой важной частью тестирования, когда вы полагаетесь на автоматизацию, неизбежно приводит к низкому качеству продукта.
Ручное тестирование требует времени и усилий для качественного выполнения. Некоторые команды, особенно небольшие, не имеющие выделенной команды QA, склонны проводить такие тесты в последний момент. Большинство стартапов, с которыми я работаю, проводят исследовательское тестирование только за несколько дней или даже часов до значительного развертывания. Иногда это срабатывает, но они рискуют поторопиться и упустить баги.
В идеале ручное исследовательское тестирование должно проводиться последовательно в течение всего цикла разработки, когда новые сборки выкладываются в промежуточную среду. Дайте своей команде время для проведения такого тестирования, и вы обнаружите, что мысль о том, что развертывание можно провести в любое время, стала беспокоить вас меньше.
Шаг 3: Внедрение автоматизированного процесса сборки и развертывания
Процесс сборки и развертывания — это те части цикла разработки, о которой часто забывают в компаниях, создающих программное обеспечение. В некоторых компаниях, в которых я работал, сборка и развертывание кажется почти мистическим процессом, который могут выполнить только несколько избранных. Развертывание у них обычно представляет собой длинный процесс из шагов, выполняемых в точном порядке и в идеальном тайминге. Если человек, выполняющий это ритуальное действие, поскользнется на этом пути, хрупкость процесса может в одно мгновение обрушить все приложение.
Возможно, я описываю этот процесс несколько преувеличено, но это очень близко к истине. Многие компании, с которыми я работал, имеют неоправданно сложные процедуры развертывания. Когда их спрашивают, почему, некоторые команды пытаются объяснить, почему все должно быть именно так, как есть, но подтекст считывается следующий «Мы всегда делали это так, поэтому никогда не меняли». Причина просто заключается в том, что кто-то давным-давно создал этот сложный процесс. И поскольку он работает — независимо от того, насколько хрупким или запутанным он стал — они никогда не думали о том, чтобы улучшить статус-кво.
Если вашей команде приходится выполнять множество шагов для сборки и развертывания новой версии приложения, вы оказываете медвежью услугу своей организации. Независимо от того, сколько меняющихся частей содержит вся система, автоматизировать можно практически любой процесс релиза — даже свести его к одной команде. Сегодня есть масса отличных инструментов, позволяющих автоматизировать процесс сборки и развертывания: Jenkins, AWS CodePipeline, CircleCI и многие другие. У вашей компании нет оправданий, чтобы не автоматизировать развертывание.
Не менее важной и забытой частью процесса развертывания является откат неудачного развертывания. Несмотря на хорошо протестированный автоматизированный процесс, он все равно может потерпеть неудачу по разным причинам, от плохого кода до сбоев в инфраструктуре приложения. Большинство команд обнаруживают, что у них нет никаких стратегий отката, когда развертывание не удается и приложение не работает. Прежде чем это произойдет, разработайте стратегию отката, подходящую для вашей ситуации, и часто тестируйте ее, чтобы закон Мерфи не застал вас врасплох.
Заключение
Просить разработчика или тестировщика сделать деплой в пятницу обычно считается смертным грехом. Большинство команд отказываются развертывать что-либо в пятницу, опасаясь, что что-то сломается и придется работать в выходные. Хотя это вполне разумно, такое отношение обычно вызвано отсутствием уверенности в процессах развертывания в компании. В большинстве случаев страх того, что новый релиз сломает систему, относится не только к пятничным деплоям, но и к деплоям, которые проходят в любое время. Такие настроения не способствуют повышению качества продукта в организации.
Если ваша команда относится к развертыванию как к хрупкой процедуре, которая может все разрушить, вы можете предпринять несколько шагов, чтобы укрепить доверие к этому процессу:
- Иметь стабильный набор автоматизированных тестов, который обеспечивает правильное сочетание тестирования и покрытия для выявления проблем до выхода в продакшн.
- Выработать привычку проводить ручное исследовательское тестирование, чтобы обнаружить баги, которые не могут обнаружить автотесты.
- Наконец, автоматизировать этапы развертывания и убедиться, что вы можете откатить любой релиз. Ни один процесс не совершенен, и, скорее всего, будут случаи, когда вам придется откатить деплой.
Благодаря этим шагам ваша команда будет готова быстро решить проблему в тех редких случаях, когда что-то пойдет не так. Как только вы внедрите некоторые или все из этих предложений, вы заметите, что качество приложений повысится. Что еще более важно, это повысит уверенность команды в своих силах.
Цель этой статьи состоит не в том, чтобы убедить вас, что можно деплоить в пятницу, а в том, чтобы дать команде возможность делать это при необходимости без каких-либо опасений. Возможность деплоя без опасений избавляет каждого разработчика и тестировщика от одной из головных болей во время проектного цикла. И если нам повезет, возможно, количество мемов в ленте в LinkedIn уменьшится.
А в завершение приглашаем всех тестировщиков на открытый урок, посвященный основам Java. На этом занятии узнаем первые операторы и создадим первую программу. Записаться на урок можно на странице курса QA Automation Engineer.
- основы java
- деплой
- деплой в пятницу
- автоматизация тестирования
- качество продукта
ПЯТНИЧНЫЙ ДЕПЛОЙ (ITKOLON)
Банка
Earned the Brewery Pioneer (Level 59) badge!
Банка
Earned the Cheers To You! badge!
Банка
Earned the Riding Steady (Level 69) badge!
Ровный темный сорт, горечь и сладость на балансе
Банка
Банка
Ненавязчивая сладость, на балансе. Предпочитаю более плотные стауты, Деплой хорошо пойдёт под еду
Развертывание этого пива прошло на ура!
Earned the Wheel of Styles badge!
Взяли с девушкой на пробу она себе малиновое, я решил взять себе темное, в целом горечь и сладость на балансе
Earned the Newbie badge!
Банка
Earned the Brewery Pioneer (Level 9) badge!
Tagged Friends
Fri, 10 Feb 2023 18:27:01 +0000 Report
Неплохо,но прям пустовато! Больше не на стаут ,а на козел темный похоже! Спорный вариант!)
Банка
Earned the Riding Steady (Level 29) badge! 
Earned the Heavy Weight (Level 24) badge!
Банка
Earned the Brewery Pioneer (Level 70) badge! Earned the Heavy Weight (Level 12) badge! 
Earned the Oat of this World! badge!
Пятничный деплой что это
Шутеечки на тему IT и всего, что связано с компьютерами. Подписывайтесь 🙂
0. Никому не говори, что у тебя есть принтер.
1. Никогда не говори, что умеешь переустанавливать Windows.
3. Придя в гости — не чини компьютер.
4. Делай комментарии в коде.
5. Не давай компьютеру понять, что спешишь.
7. Проверяй сделанные бэкапы!
Показать полностью
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору
Deploy
Деплой (deploy) — это развертывание и запуск веб-приложения или сайта в его рабочей среде, то есть на сервере или хостинге. Разработчик загружает приложение, написанное на локальном компьютере, в специальное пространство, из которого оно доступно в интернете.
«IT-специалист с нуля» наш лучший курс для старта в IT
Когда сайт загружают на сервер или хостинг, говорят, что его деплоят или «выкатывают». Также процесс называют деплоингом (deploying). Еще есть выражение «отправка в продакшн» или «на прод» — оно описывает этот же процесс.
Продакшн (production) — запущенная версия сайта, та, которую видят пользователи. Так что отправка в продакшн — тоже деплой. Точнее, одна из его разновидностей, потому что разворачивать приложение могут не только для конечных пользователей, но и, например, на тестовом сервере.
Само английское слово deploy в переводе означает «развертывать».
Профессия / 8 месяцев
IT-специалист с нуля
Попробуйте 9 профессий за 2 месяца и выберите подходящую вам
Для чего нужен деплой
Сайты не пишут непосредственно на серверах: всю работу программисты делают на собственных или рабочих компьютерах. Соответственно, когда приложение написано и протестировано, нужно доставить его на сервер, настроить и запустить там. Так его смогут увидеть пользователи интернета.
Без деплоя код не дойдет до сервера и так и останется на рабочей машине программиста. А писать прямо на сервере — очень плохая идея даже в теории: это сложно, неудобно и может его «уронить». Тем более часто рабочая среда — не один сервер, а сотни разных устройств, и процесс развертывания и запуска в продакшн довольно сложный.
Читайте также Востребованные IT-профессии 2023 года: на кого учиться онлайн
Что именно деплоят
Все, что работает в сети: веб-приложения, сайты, разные сервисы, в том числе те, которые не предназначены для внешнего использования. Даже если речь идет о каком-то локальном сервисе, работающем только во внутренней сети компании, его тоже нужно задеплоить, чтобы он стал доступен в этой сети.
Деплоят не обязательно приложение целиком. Чаще, если речь идет о процессах в коммерческой разработке, различные новые функции и доработки пишут разные программисты. По мере готовности отдельные завершенные части деплоятся. Это удобнее. А разработка распределенных приложений со множеством отдельных частей вообще выглядит как множество независимых деплоев.
Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить
Как выглядит жизненный цикл кода
Чтобы лучше понимать, как все происходит и какую роль играет деплой, простыми словами расскажем о процессе разработки в IT-компаниях.
1. Разработчик пишет код. Это может быть принципиально новый сервис или доработка к уже существующему, обновление сайта или что-то еще. Он делает это на локальном компьютере.
2. Когда код готов, разработчик коммитит его: загружает в репозиторий, специальную «общую папку» команды, например на сервисе GitHub. Там его смогут увидеть и прокомментировать другие разработчики — это называется код-ревью.
3. В определенный момент — по расписанию или после успешного коммита, который одобрили другие, — команда решает, что код нужно отправить в продакшн.
4. Создается релиз, публикуется своеобразное сообщение о будущем деплое: код в репозитории маркируется специальным тегом. Это нужно, чтобы избежать случайной отправки в продакшн каких-то изменений, которые внесли в репозиторий уже после сообщения о будущем деплое.
5. В нужное время происходит деплой. Код уходит в продакшн, появляется на серверах, его видят пользователи.
Что входит в деплой
Это зависит от того, что именно развертывают и какими инструментами при этом пользуются. Если речь о простом статическом сайте, где нет сложного бэкенда, достаточно загрузить новые файлы на сервер, обновить старые файлы, подключить зависимости и «собрать» проект. То же самое касается изменений, которые затрагивают только фронтенд — внешнюю часть, которую видит пользователь.
Если же обновляется бэкенд, или серверная часть сайта, все куда сложнее. Нужно как минимум подключить к коду базу данных и соединить составные части приложения друг с другом. Иногда этот процесс бывает довольно долгим.
Когда все готово, новую версию запускают, а старую останавливают. Тут есть свои хитрости, которые позволяют избегать простоев сайта в этот период, но ими пользуются не все. Мы поговорим о них позже.
Деплоймент пошагово: как это выглядит
Вот как примерно выглядит процесс:
- отправка кода на сервер — файлы «приходят» в рабочую среду, чаще всего через Git;
- настройка зависимостей — старые файлы обновляются, в них прописываются связи с новыми частями кода, нововведения интегрируются в структуру;
- сборка — все файлы «собираются» в единый проект, в систему, которая может функционировать;
- миграции — выполнение специальных скриптов для базы данных, которые «готовят» ее к нововведениям, обновляют и настраивают структуру;
- запуск — старая версия останавливается, задеплоенная запускается. После этого приложение начинает работать с новыми функциями.
Автоматизация деплоя
Делать все перечисленное вручную — долгий процесс, который отнимает у программиста время и силы, увеличивает риск ошибки и уровень стресса в команде. В перспективе ручной деплой еще и ухудшает продуктивность: увеличивается срок до выхода в продакшн, сервис развивается медленнее, нововведения выкатывают реже.
Поэтому деплоймент обычно автоматизируют. Сделать это можно несколькими способами, какой выбрать — зависит от стека технологий, бюджета и масштаба проекта:
- с помощью надстроек и утилит, написанных для конкретных языков или библиотек;
- через системы автоматизации и управления, такие как Ansible, или через облачные сервисы для веб-приложений вроде Heroku;
- с помощью оркестраторов, платформ, которые управляют контейнерами, — самым известным примером считается Kubernetes.
Сборка и запуск тоже автоматизируются, уже с помощью других инструментов.
Уровень автоматизации может быть очень разным, вплоть до систем непрерывной доставки, при которой деплой полностью автоматический и не требует участия разработчика.
Избежание простоя: что такое подход Zero Downtime
Выше мы говорили, что в классическом варианте старая версия отключается, а новая запускается и, пока это происходит, сайт простаивает. Посетители не могут им пользоваться. Для крупных проектов деплой занимает много времени, и такой простой критичен, особенно если сайт коммерческий. Поэтому есть способы, позволяющие его не допустить.
При использовании подхода Zero Downtime Deployment сайт не останавливается. Это происходит, потому что в таком случае сначала запускается новая версия, а потом отключается старая.
Звучит просто, но на деле намного сложнее: во избежание ошибок и конфликтов нужно, чтобы старая и новая версия были единообразно написаны, а база данных была совместима с обеими одновременно. Кроме того, понадобятся автоматические системы, которые будут проверять запуск новой версии и переключать трафик на нее. Сам процесс усложняется.
Из-за высоких требований к инфраструктуре таким подходом обычно пользуются большие проекты, у которых есть ресурсы для его реализации.
Как начать деплоить
Проще всего пользоваться сервисами вроде Heroku: бесплатный план ограничен, но поможет разобраться. Если вы хотите потренироваться, можете воспользоваться хостингами: они обычно предлагают решения для настройки окружения, но за них придется платить.
В коммерческих проектах новички обычно не занимаются деплоем — это довольно ответственная задача. В больших компаниях за развертывание отвечает DevOps-инженер, но если проект маленький, эта задача может лечь на бэкендера, тимлида или другого специалиста.
Узнайте больше о процессе разработки на курсах — мы поможем разобраться с нужными технологиями и начать работать по новой специальности.
IT-специалист с нуля
Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.
Статьи по теме:
- «Ты совсем о нас не вспоминаешь» или 20 строчек на Python, чтобы порадовать родителей
- Чем занимается DevOps-инженер в международной IT-компании?