Поэтапное развертывание для разработчиков плагинов и тем WordPress: предотвращение «выпуска кластерной ошибки»
Опубликовано: 2020-12-23Вы помните, когда в последний раз вы выпускали новую версию своего плагина или темы WordPress, чтобы быстро обнаружить, что вы по ошибке добавили новую серьезную ошибку, которая ускользнула из вашей последовательности тестирования?
Yoast SEO 3.0 сломал многие сайты еще в 2015 году. Elementor 3.0 сделал то же самое в этом году. И это всего лишь два примера фантастических компаний в нашей сфере с более чем 100 сотрудниками и преданным персоналом по контролю качества (и нет, это не связано с версией 3.0, но, возможно, это знак, чтобы пропустить эту версию в вашем программном обеспечении; )).
Независимо от того, являетесь ли вы кодером-самоучкой или инженером-программистом, независимым разработчиком или сотрудником крупного магазина плагинов/тем, нам всем приходится сталкиваться с ошибками. Это неизбежная часть разработки программного обеспечения.
Неважно, какие причудливые средства автоматизации CI/CD/тестирования вы внедрите – вы никогда не сможете протестировать все это. Количество конфигураций сервера (PHP, MySql, кеширование, веб-сервер), версий WP, комбинаций плагинов и тем… бесконечно.
И это нелогично. Чем популярнее и стабильнее становятся ваши продукты, тем выше шансы на страшный выпуск «Clusterbug», который истощит вашу поддержку, может значительно повлиять на доверие и лояльность ваших клиентов и потенциально нанести ущерб репутации бренда в целом.
Хотя вы не можете избежать ошибок, вы можете и, безусловно, должны максимально снизить риск.
Если у вас есть смартфон, вы, вероятно, заметили, что некоторые из ваших друзей получают обновления Android/iOS за несколько дней, недель, а иногда даже месяцев до того, как вы их получите. Это не совпадение, и нет, ничего личного против вас. Это преднамеренный процесс поэтапного развертывания, называемый поэтапным развертыванием, который помогает таким компаниям, как Apple, поставлять основные обновления программного обеспечения на более чем миллиард устройств.
Да миллиард!
Можете ли вы хотя бы представить себе, какую ответственность возложили бы на плечи руководителя версии Apple, если бы им пришлось выпускать живое обновление на 1,5 миллиарда мобильных устройств одновременно? Я не могу. Держу пари, что ни один здравомыслящий человек не согласился бы нести такую ответственность.
Итак, как же работает механизм поэтапных развертываний? Как вы можете это реализовать? А чего ждет WordPress.org? Это темы, которые я собираюсь осветить ниже.
Что такое поэтапное внедрение плагинов и тем WordPress?
Поэтапные развертывания позволяют указать количество (или процент) веб-сайтов, на которые вы хотите развернуть новую версию. Механизм поэтапных развертываний позволяет вам начать цикл выпуска с ограниченной экспозицией, а затем постепенно увеличивать его, отслеживая поддержку и отзывы, тем самым укрепляя доверие к вашему выпуску для вас и ваших пользователей.
Каковы преимущества поэтапного развертывания?
Вместо того, чтобы рисковать всей своей установочной базой из-за выпуска потенциальных ошибок, конфликтов со сторонними плагинами/темами или даже проблем с UI/UX, вы можете выпускать версии постепенно, сводя к минимуму количество людей и веб-сайтов, которые могут столкнуться с неожиданными проблемами. Как только вы устраните все проблемы и ошибки, обнаруженные в процессе развертывания, подавляющее большинство ваших пользователей получат доступ к «зрелой» и гораздо более стабильной версии.
Мы используем последовательные обновления, чтобы обеспечить качество наших новых выпусков. Если есть проблема с новой версией, мы можем быстро определить ее, и затронута будет только небольшая часть пользователей.
Джон Тернер, основатель SeedProd
Использование поэтапных развертываний — это САМАЯ лучшая практика для ответственного выпуска программного обеспечения — процесс, которому следуют многие компании (независимо от размера), не входящие в круг WP.
У сообщества WordPress есть отличная возможность воспользоваться поэтапными развертываниями, о которых я расскажу чуть позже.
Похожи ли бета-программы на поэтапные развертывания?
Настройка бета-программы для вашего продукта WordPress — отличное начало, но она далеко не так эффективна, как поэтапное развертывание, и имеет принципиально другую цель и динамику.
Если ваш плагин или тема не очень популярны и не имеют большого сообщества, довольно сложно набрать статистически достаточную бета-группу, поскольку лишь небольшая часть пользователей будет заинтересована в присоединении. Даже если вам удастся набрать приличную группу бета-тестеров, вы должны полагаться на их доступность и добрую волю для тестирования продукта, а затем надеяться, что они приложат дополнительные усилия, чтобы сообщить о найденных проблемах.
Как вы думаете, сколько людей увидит весь этот процесс? Не так много.
Бета-тестирование — это предварительный процесс, в ходе которого ваши усилия по поддержке полностью контролируются, и тестировщики ожидают возникновения проблем с бета-версиями. Таким образом, ожидания тестировщиков относительно качества не отражают общего настроения вашей пользовательской базы.
Более того, ответственная бета-программа предупредит своих тестировщиков, чтобы они избегали использования бета-версий в производственных средах, поэтому бета-тестирование на самом деле не имитирует живые рабочие веб-сайты.
Как управлять поэтапным выпуском вашего плагина или темы WordPress?
В рамках моего исследования поэтапных развертываний у меня была возможность пообщаться по электронной почте с Амиром Хельзером и узнать об их более чем двухлетнем опыте использования поэтапных развертываний с WPML и набором инструментов, плагинов, работающих на более чем 1 000 000 веб-сайтов WordPress.
Вот что Амир рассказал об их внедрении поэтапных развертываний:
Когда веб-сайт устанавливает любой из наших плагинов, мы выбираем случайное число от 1 до 100 и сохраняем его в базе данных сайта для запоминания. Этот метод по существу разбивает веб-сайты на 100 ячеек случайным образом.
Когда выпуск готов к запуску, он становится постепенно доступным только для одной выбранной корзины. Каждый день мы увеличиваем доступность релиза к дополнительным 5% веб-сайтов в указанной корзине. И исправить и исправить предстоящие проблемы, как мы идем.
Чтобы разнообразить среды, использующие обновленную версию, и избежать повторного появления одних и тех же «жертв» ранних выпусков, Амир подтвердил, что каждый новый выпуск сначала попадает в другую корзину пользователей.
Этот подход также означает, что в среднем цикл выпуска для каждого пользователя занимает около месяца.
Требуется время, чтобы люди увидели новую версию, доступную в WP Admin, и обновили свою версию. И даже после того, как они это сделают, может пройти несколько дней, прежде чем они обнаружат проблему.
Учитывая размер нашей аудитории, у каждого релиза неизбежно возникают проблемы. Наша главная цель — убедиться, что мы избегаем появления новых проблем, и если мы это делаем, у нас есть надежный процесс для их решения.
Цикл релиза действительно долгий, но даже если в худшем случае будет какая-то сумасшедшая ошибка, которую мы пропустили при тестировании, 95% наших пользователей даже не осознают всей драмы, так как они не подвергаются релизу. пока не станет стабильно.
Амир также подчеркнул важность синхронизации со всей командой перед выпуском, особенно со службой поддержки и разработкой. Таким образом, члены команды могут уделять больше внимания заявкам, инициированным из-за проблем, связанных с текущим выпуском, с целью проверки, подтверждения и исправления действительных проблем и выпуска исправлений как можно быстрее.
В нашей команде есть три уровня поддержки. Уровень 1 рассмотрит проблему, подтвердит, что это действительно проблема, связанная с выпуском плагина, воспроизведя ее. Когда кажется, что дело связано с новым выпуском, оно переходит на уровень 2, который отлаживает проблему, чтобы убедиться, что она действительно связана с выпуском, и находит соответствующие части в коде, которые вызывают проблему. В случае проверки разработчик, ответственный за этот код, немедленно получит уведомление, чтобы определить приоритет исправления.
OnTheGoSystems — крупная компания, в которой работает почти 100 сотрудников, поэтому вполне логично, что они усовершенствовали процесс поэтапного развертывания. Но даже будучи разработчиком одного продукта с одним уровнем поддержки (вы и вы сами), понимание Амира может научить нас тому, как важно выделять выделенные ресурсы для выпусков. Хорошей практикой является отдавать приоритет обращениям в службу поддержки, которые даже «пахнут», чтобы быть связанными с вашим новым выпуском, и максимально уменьшить воздействие новых проблем.
Почему (почти) нет плагинов или тем, поддерживающих поэтапное развертывание?
Готовясь к написанию этой статьи, я попытался попросить сообщество узнать, кто использует поэтапное развертывание, чтобы получить отзывы об их опыте, о том, чему они научились и т. д.
Неудивительно, что я нашел только две компании WordPress в своей сети, которые настроили поэтапное развертывание как часть своего цикла выпуска. Многие разработчики даже не знали об этой концепции, а остальные не используют ее, поскольку их дистрибутив не поддерживает ее (или, возможно, они думали о ее разработке, но у них нет времени).
Большинство разработчиков плагинов и тем, которые не продают через Freemius, продают со своего веб-сайта через EDD или WooCommerce, которые не поддерживают поэтапное развертывание. Те, кто продает через такие торговые площадки, как CodeCanyon и ThemeForest, также не имеют готовых решений и, скорее всего, никогда их не получат.
Даже у разработчиков, знакомых с этой концепцией, нет иного выбора, кроме как разработать собственный механизм для поддержки поэтапных развертываний. Такое развитие инфраструктуры, как правило, очень трудно расставить по приоритетам в рамках продуктовой компании.
Подпишитесь и получите бесплатную копию нашего
Бизнес-книга плагинов WordPress
Как создать процветающий бизнес плагинов WordPress в экономике подписки.
Поделитесь с другом
Введите адрес электронной почты вашего друга. Мы отправим им только эту книгу по электронной почте, честь скаута.
Спасибо, что поделились
Потрясающе — копия «Бизнес-книги плагинов WordPress» была только что отправлена на . Хотите помочь нам распространить информацию еще больше? Продолжайте, поделитесь книгой с друзьями и коллегами.
Спасибо за подписку!
- мы только что отправили вашу копию «Бизнес-книги плагинов WordPress» на .
В письме есть опечатка? нажмите здесь, чтобы изменить адрес электронной почты и отправить снова.
Как поэтапное развертывание дает вам коммерческое преимущество?
Поскольку в настоящее время почти никто не использует преимущества поэтапных развертываний, если вы начнете использовать поэтапные развертывания и правильно рекламировать их на своем веб-сайте, чтобы посетители знали, что у вас есть ответственные циклы выпуска, это определенно даст вам конкурентное преимущество и повысит доверие к вашему продукту. /бренд!
Если вы проанализируете рынок с точки зрения разработчика, вы заметите, что многие разработчики внимательно следят за своими конкурентами и обычно устанавливают свои цены в пределах рыночного ценового диапазона по своей вертикали, что приводит к тому, что конкурирующие продукты WordPress предлагают аналогичные функции в том же ценовом диапазоне.
С точки зрения покупателя это означает, что часто возникает вопрос, какой продукт купить, потому что все они имеют сопоставимые характеристики и цены. Но когда вы оцениваете несколько плагинов, которые стоят одинаково и, плюс-минус, имеют одинаковые функции, разве вы не склонны выбрать продукт, который предлагает поэтапное развертывание, зная, что его производственные версии должны быть более стабильными, чем у конкурентов?
Поэтапное развертывание повышает доверие к вашему продукту и бизнесу. Это преимущество, которым вы можете воспользоваться до того, как поэтапные развертывания станут стандартной практикой (на что я искренне надеюсь).
Freemius теперь поддерживает поэтапное развертывание платных плагинов и тем
Мы рады стать пионером поэтапного развертывания в премиум-экосистеме плагинов и тем WordPress. Наши партнеры по продажам теперь могут безопасно, уверенно и надежно выпускать обновления с минимальными последствиями для своих пользователей или ресурсов поддержки/разработки.
Мы знаем, насколько сложными и нервными могут быть крупные релизы, тем более что всегда есть потенциальный риск негативного влияния на ваш бренд после релиза «Clusterbug».
Поэтапное развертывание обеспечивает безопасность и защищенность бренда наших партнеров, а также снимает ненужный стресс, связанный с выпуском обновлений для большой пользовательской базы.
Это неразрывно связано с выгодой для клиентов наших партнеров. Когда пользователи покупают продукты, продаваемые через Freemius, они теперь могут быть уверены, что выбирают решение на основе поэтапных развертываний, и могут ожидать гораздо более стабильных выпусков плагинов премиум-класса и тем, использующих этот механизм.
Если вы продаете с помощью Freemius, вот как правильно использовать наш механизм поэтапного развертывания.
Как Freemius реализует поэтапное развертывание?
Каждый веб-сайт, который активирует лицензию для разблокировки премиум-плагина или темы, получает запись в нашей базе данных. Первое, что мы сделали, — это ввели новое свойство last_served_update_version для хранения последней версии продукта, доступной для веб-сайта.
Затем мы обогатили таблицу, отвечающую за хранение данных о выпуске, двумя новыми свойствами: limit , uniques .
Когда разработчик помечает версию как выпущенную, ему будет предложено следующее диалоговое окно, позволяющее настроить процент (или количество) веб-сайтов с активной лицензией, на которые он хочет развернуть платную версию:
Если они устанавливают ограниченное развертывание выпуска, система подсчитает общее количество активных веб-сайтов с активной лицензией, а затем соответствующим образом установит новое свойство limit выпуска.
Наконец, мы обновили конечную точку API, вызываемую веб-сайтами для проверки наличия новой версии, и ввели следующую логику (в псевдокоде):
latest_version = load latest version of product X
If (website is on latest_version)
return “no new version”
If (last_served_update_version of website same as latest_version)
return “no new version”
If (latest_version is limited)
If (latest_version is limited AND uniques >= limit)
return “no new version”
previous_version = load the previous version of product X
If (previous_version is limited too AND uniques <= previous_version.uniques)
If (website not using previous_version AND
last_served_update_version different from previous_version)
return “no new version”
else If (random({true, false}) )
return “no new version”
Set last_served_update_version of website to latest_version
Increment uniques by 1
return latest_version
Этот алгоритм гарантирует, что:
- Экспозиция релиза ограничена в соответствии с установленным процентом выкатывания.
- Если предыдущая версия все еще находится на стадии промежуточного хранения, т. е. она никогда не была доступна для всей установочной базы, веб-сайты, получившие предыдущую промежуточную версию, сначала будут доступны для последней промежуточной версии.
В отличие от архитектуры поэтапных развертываний WPML, которая гарантирует, что каждый выпуск попадет в различное подмножество их установочной базы с использованием логических ячеек, наша реализация полагается на случайность. Таким образом, веб-сайт может получить два ранних выпуска за два последовательных цикла выпуска. Однако преимущество этого подхода заключается в том, что мы смогли поставлять поэтапные развертывания всем клиентам наших партнеров без необходимости запускать обновление SDK, распространение которого среди клиентов может занять многие месяцы и даже годы.
Почему поэтапные развертывания необходимы для будущего WordPress?
Когда я спросил Амира, что послужило для них толчком к разработке поэтапных развертываний для циклов выпуска WPML, он сказал мне следующее:
3 года назад, на WordCamp Europe, я провел время в чате с клиентами WPML, чтобы собрать всевозможные отзывы об их общем опыте. Разочарование № 1, которое я обнаружил, заключалось в том, что наши клиенты боялись обновлять плагин, поскольку он может неожиданно сломать их сайт.
Амир Хельцер,
Основатель OnTheGoSystems (WPML, набор инструментов)
Я абсолютно согласен с этим.
Наша внутренняя политика Freemius в отношении обновления плагинов и тем такова: просто не делайте этого! С двумя исключениями: если есть известная проблема безопасности или функция, доступная в более новой версии, которая нам нужна для нашего сайта.
Наша политика обновлений была «написана кровью» после нескольких случаев, когда обновления пошли не так и вызвали неожиданные головные боли и трату времени, нарушив нашу работу и сроки. И да, мы могли бы избежать некоторого стресса с промежуточной средой, но это не сэкономило бы нам время и нервы, если бы мы все еще хотели продолжить обновление до рабочей среды.
С тех пор WordPress немного изменился, и теперь у нас есть автоматическая деактивация при сбоях плагинов. Однако это не относится к темам, и деактивация критически важного плагина для нашего веб-сайта по-прежнему остается большой проблемой.
Суть в том, что если я, как разработчик плагинов и генеральный директор компании, которая помогает тысячам разработчиков плагинов и тем развивать свой бизнес, беспокоюсь о том, что наш сайт может сломаться каждый раз, когда мы обновляем плагины или темы на нашем сайте, то это, безусловно, означает у большинства пользователей нет уверенности в обновлении программного обеспечения в нашем пространстве.
Отсутствие поэтапных развертываний сдерживает нас и всю экосистему WP и дает конкурентным решениям на основе SaaS значительное преимущество. Пользователям WiX и Shopify вообще не нужно думать об обновлениях! Обновления просто происходят для них в фоновом режиме, и их программное обеспечение всегда актуально, безопасно и функционально.
Отсутствие поэтапных развертываний сдерживает всю экосистему WP и дает решениям на основе SaaS значительное преимущество. Пользователям WiX и Shopify не нужно думать об обновлениях программного обеспечения — они просто происходят в фоновом режиме. Твитнуть
Если вы смотрели выпуск State of the Word на прошлой неделе, соучредитель WordPress Мэтт Малленвег ясно понимает важность современного программного обеспечения. Вот видение Мэтта обновлений WP:
… позволяя вам подписаться на автоматические обновления для Core. Это первый шаг к нашей цели, позволяющий вашему WordPress поддерживать себя, когда вы можете установить его и забыть, и он будет получать автоматические, фоновые и беспроблемные обновления для всех ваших плагинов, тем и ядра. Твитнуть
Единственный способ, которым я могу представить, что WordPress станет «установил и забыл», — это если обновления программного обеспечения могут быть более надежными и заслуживающими доверия, а это может произойти только с поэтапными развертываниями.
WordPress.org: вот как вы можете внедрить поэтапные развертывания для плагинов и репозитория тем
Как и в нашей реализации, в каждый выпуск плагина и темы в базе данных WordPress.org необходимо добавить две новые мета-опции: limit и uniques .
Редактирование мета-параметра limit может быть представлено в расширенном представлении для вошедшего в систему владельца (и, возможно, для других коммиттеров):
У разработчика будет возможность контролировать экспозицию каждого выпуска, а также возможность установить ограничение для следующего выпуска.
Поскольку WordPress.org не хранит структурированные данные для каждого веб-сайта, получающего обновления от WordPress.org, вместо того, чтобы хранить последнюю версию, «увиденную» веб-сайтом, в базе данных WordPress.org, хранение данных может быть делегировано веб-сайтам. . Это означает, что переходный процесс 'update_plugins' и данные, отправляемые в WordPress.org API при проверке обновлений, должны быть last_served_update_version .
Наконец, конечные точки API обновлений WordPress.org могут быть обогащены той же логикой, которую мы использовали для реализации поэтапных развертываний Freemius. Просто вместо того, чтобы полагаться на last_served_update_version из базы данных wp.org, механизм будет зависеть от значения, отправленного ядром с веб-сайта.
Полегче, нет?
нанимает 
Давайте вернем пользователям уверенность в том, что они нажимают кнопку «Обновить»
Мы все хотим, чтобы WordPress преуспевал и постоянно рос и становился лучше!
С таким большим количеством ресурсов, вложенных в Gutenberg, ясно, что руководство WordPress признает, что мы должны сделать платформу более доступной для обычного человека, не разбирающегося в технологиях. Дело в том, что пока обновлениям программного обеспечения нельзя доверять, даже с Гутенбергом и всеми доступными нам замечательными конструкторами страниц, нетехнический человек убежит к Wix при их первом сломанном обновлении, и я не могу винить их.
Я обращаюсь к основателю EDD Пиппину Уильямсону, генеральному директору WooCommerce Полу Майоране и команде WordPress.org: у нас есть возможность сделать экосистему плагинов и тем намного более стабильной для большего сообщества WordPress. Давайте позволим пользователям поддерживать безопасность и актуальность своего программного обеспечения с меньшим страхом и разочарованием. Хотя в краткосрочной перспективе это может показаться не очень важным, я уверен, что в долгосрочной перспективе мы все выиграем от этого.