Пастушьи кошки — уроки, извлеченные при разработке для среды WordPress

Когда Elementor 3.0 был выпущен более года назад, в 2020 году, мы увидели в этом значительный шаг к более быстрому и значительно более мощному редактору. Хотя это правда, эта версия также имела важные, неожиданные последствия — она привела к прекращению работы значительного количества сайтов и, откровенно говоря, нанесла ущерб нашей репутации. После этого релиза нам пришлось внести ряд исправлений, чтобы эти сайты снова заработали. Более того, весь опыт показал нам, что нам нужно пересмотреть всю нашу процедуру тестирования и выпуска. Несмотря на то, что этот процесс болезненный, сегодня он окупается, о чем свидетельствует чрезвычайное снижение проблем, особенно критических, между выпуском наших версий v3.0 и v3.4:

Теперь, когда мы приближаемся к годовщине Elementor 3.0, самое время оглянуться назад и изучить процедуры, которые мы внедрили, чтобы гарантировать, что проблемы, связанные с его выпуском, больше не возникнут. Чтобы быть максимально прозрачным с нашим сообществом, я хотел бы изучить предысторию проблем, связанных с выпуском 3.0, шаги, которые мы предприняли за последний год, как мы смогли обеспечить стабильные выпуски и что нас ждет в будущем. Но сначала важно немного понять историю Elementor и проблемы, с которыми мы сталкиваемся при разработке сложного, сложного плагина в среде WordPress.

Elementor и вызов WordPress

В июне 2016 года, когда мы выпустили первую версию Elementor, мы были всего лишь несколькими «малышами», которым нравилось разрабатывать плагины и помогать людям создавать веб-сайты. Это был не первый наш продукт, мы уже разработали несколько плагинов, используемых сообществом WordPress. Однако, работая над Elementor, мы убедились, что разрабатываем что-то особенное. Как оказалось, мы были правы — всего через несколько месяцев после нашего первого релиза десятки тысяч пользователей уже установили Elementor и использовали его для создания веб-сайтов по всему миру.

С тех пор наша компания выросла во всех отношениях, появилось больше разработчиков, больше пользователей и больше возможностей. С этим ростом появилось множество новых проблем, в том числе растущий дефицит технологий, поскольку мы сосредоточились на неотложных проблемах, отложив в сторону важные, но более приземленные проблемы.

Решение этих проблем стало еще более сложным из-за общей проблемы, связанной с природой среды WordPress.

Как открытая платформа, WordPress предлагает ряд больших преимуществ для разработчиков. Есть несколько контрольно-пропускных пунктов, которые отслеживают и замедляют выпуски. Концепции придумываются, разрабатываются и добавляются в репозиторий. Пользователи пробуют, тестируют и оценивают эти продукты, а рынок решает, какие из них будут процветать, а какие нет. Однако за эту скорость и простоту приходится платить.

В среде WordPress мало единообразия и нет упорядоченного рабочего процесса. Создатели веб-сайтов могут свободно определять среду своих сайтов, используя широкий набор плагинов, тем и т. д. Это означает, что сайты WordPress содержат бесчисленное количество комбинаций плагинов, тем и конфигураций сервера.

Кроме того, простота процесса выпуска и отсутствие надежных инструментов развертывания означает, что разработчики WordPress не могут использовать современные концепции выпуска, такие как CI/CD, Canary Deployment и Feature Flags.

В то время как открытость является частью красоты WordPress, неотъемлемое множество конфигураций сайта и сервера ставит перед разработчиками настоящую проблему, когда дело доходит до учета конфликтов плагинов и конкретных проблем с сервером.

В нашем случае, поскольку Elementor использовался для все большего количества веб-сайтов, необходимость поддержки всех этих различных комбинаций замедляла наш график выпуска и даже заставляла нас колебаться в разработке новых функций. Излишне говорить, что такая ситуация была неприемлемой, и нам нужно было встряхнуться.

Разработка новых функций, не ломая старые

Все вышеперечисленные факторы поставили нас перед дилеммой: как мы можем продолжать развиваться и совершенствоваться, не оказывая негативного влияния на работу тех, кто уже полагался на Elementor?

Мы начали с внесения небольших изменений в наш процесс выпуска. В Elementor 1.5 мы начали предлагать разработчикам доступ к бета-версиям. Мы сделали это через Github и другие сообщества, которые позволили нам получить отзывы перед выпуском, указав, как эта версия взаимодействовала с широким спектром комбинаций плагинов/тем/окружения, и предупредив нас о любых несовместимостях на раннем этапе. Этот подход некоторое время работал хорошо, но по мере роста Elementor мы обнаружили, что этого недостаточно.

К этому времени мы преодолели порог в пять миллионов установок. Хотя это было невероятное достижение, это также означало, что теперь мы несем ответственность за бесперебойную работу всех этих веб-сайтов.

Все наконец достигло апогея с выпуском Elementor 3.0. В этой версии мы решили отказаться от некоторых старых, казалось бы, устаревших функций, удалив элементы DOM для увеличения скорости загрузки. Это было, по крайней мере частично, в ответ на обоснованные жалобы на то, что мы излишне нагружаем систему.

К сожалению, это изменение привело к тому, что ряд сайтов, которые полагались на код, который мы удалили, перестал работать во время обновления. Несмотря на наши попытки привлечь к процессу сторонних разработчиков, эти ошибки так и не были обнаружены, и нам пришлось действовать быстро, чтобы исправить ситуацию. В конце концов, мы смогли сделать это, сделав части обновления необязательными, но не раньше, чем некоторые члены нашего сообщества пошатнулись в своей уверенности в стабильности нашего плагина.

Этот опыт заставил нас долго и пристально смотреть на процесс разработки с прицелом на ряд серьезных изменений. Наши процессы просто не подходили для компании нашего размера и установленной базы. Первым и, возможно, самым очевидным шагом было увеличение размера и сферы деятельности нашей команды контроля качества, но это все равно заставило нас решить ряд нерешенных проблем:

• Проверка совместимости версии с бесчисленными настройками сайта
• Обеспечение обратной совместимости с более чем пятью миллионами существующих сайтов
• Проверка совместимости сотен сторонних расширений Elementor

Чтобы решить все эти проблемы, нам нужно было внедрить в мир WordPress более современные методы разработки программного обеспечения.

Цикл обратной связи

Одна из больших проблем, с которыми сталкиваются разработчики, заключается в том, что пользователи получают обновления только после их выпуска. Это означает, что функция уже спроектирована, разработана и выпущена к тому времени, когда мы получаем какие-либо отзывы от пользователей. В нашем случае, имея дело с сотнями сотен сторонних расширений и плагинов, проблема этой петли обратной связи еще более важна.

В поисках способов сократить этот цикл обратной связи мы посмотрели, как разработчики браузеров справляются с проблемами, очень похожими на наши собственные — они также должны обеспечивать совместимость с бесчисленным количеством сторонних веб-страниц, приложений, расширений и многого другого.

Например, мы рассмотрели систему, разработанную Google для своего браузера Chrome. В любой момент разработчики имеют доступ к трем версиям браузера — бета-версии, версии для разработчиков и ночной версии. Это означает, что разработчики получают ранний доступ к новым функциям Chrome и могут начать давать обратную связь Google задолго до официального выпуска версии.

Применяя эти уроки к нашему плагину, Elementor начал выпускать свою собственную версию для разработчиков — Elementor Beta (Developer Edition), доступную в репозитории WordPress и предназначенную для разработчиков, которые заинтересованы в проверке наших новых функций, так сказать, «горячих».

Для нас, конечно, мы выигрываем, получая ранние предупреждения о проблемах совместимости. Версия для разработчиков не только позволяет пользователям получить доступ ко всем этим новым функциям, но и имеет прямую ссылку на Github для сообщения об ошибках. Это означает, что мы можем постоянно внедрять новые функции и получать отзывы о них, не подвергая опасности существующие веб-сайты. Для разработчиков это позволяет заранее подготовиться к предстоящим официальным выпускам, помогая предотвратить их собственные проблемы с совместимостью, а также дает им возможность предоставлять отзывы о продуктах и ​​технических характеристиках, пока функция еще находится в разработке.

Следует отметить, что выпуски версии для разработчиков выполняются параллельно с обычными — альфа-, бета-, RC- и производственными — процессом, используемым для разработки выпусков Elementor. Когда мы разрабатываем новую функцию, как только она станет достаточно стабильной для использования, но пока она еще находится в альфа-версии, мы добавляем ее в версию для разработчиков. Таким образом, наши разработчики могут оставить нам отзыв еще до того, как функция станет бета-версией. Это также означает, что версия для разработчиков включает в себя функции, которые еще не достигли стадии бета-тестирования.

По сути, бета-стадия зарезервирована для преднамеренного процесса отладки, в то время как версия для разработчиков обновляется чаще, включая функции на самых ранних стадиях.

С момента своего появления версия для разработчиков добилась большого успеха, собрав более 40 тысяч установок менее чем за год.

Представляем «экспериментальные» функции

На протяжении многих лет разработчики использовали еще одну концепцию — флаги функций, которые особенно распространены в мире SaaS. Общая идея заключается в том, что эти флаги функций позволяют разработчикам тестировать новые функции, включая и выключая их для разных сегментов пользователей, чтобы протестировать их и посмотреть, как они работают.

Как упоминалось выше, многие проблемы, связанные с выпуском 3.0, были связаны с новыми функциями, устраняющими старый код. Чтобы избежать подобных проблем, мы решили применить подход, аналогичный подходу с флагами функций.

Начиная с Elementor 3.1, мы стали более осторожно выпускать новые функции, помечая их как «экспериментальные». Это включает в себя систему поэтапного внедрения новых функций. В этой системе новая разработанная функция будет помечена как «Альфа». Это означает, что по умолчанию он отключен на всех сайтах. По мере того, как он оказывается более стабильным, он становится «бета-версией», то есть теперь он включен по умолчанию для новых сайтов и выключен для существующих сайтов. Как только мы убедимся, что он стабилен, он включен по умолчанию для всех сайтов. Даже в этом случае у пользователей будет возможность деактивировать эту функцию на ограниченное время.

Эта система позволяет нам продолжать разработку Elementor, добавляя как его набор функций, так и его скорость, а также позволяя создателям включать или отключать эти новые обновления в соответствии с потребностями их сайта. Это также помогает авторам обновлять свои сайты, позволяя им более тщательно внедрять новые функции.

Теги совместимости

Рост очень активного сообщества разработчиков Elementor был большим источником гордости, но также поставил свои проблемы. Сторонние разработчики создали сотни расширений, тем, комплектов и виджетов, основанных на наших существующих технологиях.

Чтобы поддержать разработчиков этих сторонних надстроек, мы использовали блог наших разработчиков и наш список рассылки, чтобы заблаговременно уведомлять их об изменениях, которые мы вносим в API, а также об устаревании. Однако, как упоминалось выше, мы обнаружили, что этого недостаточно. Многие из проблем, с которыми мы сталкивались в новых выпусках, были связаны с проблемами совместимости из-за этих сторонних надстроек. Наш плагин считался нестабильным не из-за нашей технологии, а из-за этих сторонних несовместимостей.

Опять же, мы искали вдохновения в том, что делали другие. В данном случае WooCommerce и их подход к работе со сторонними разработчиками. Начиная с нашего выпуска 3.1, мы запустили систему, в которой сторонние разработчики удостоверяют, что их расширения совместимы с новой версией (Подробнее). Затем, когда пользователям предоставляется возможность обновить Elementor, им предоставляется список сторонних расширений, которые они используют, и независимо от того, сертифицированы ли они как совместимые с новой версией Elementor. Таким образом, пользователи могут принять обоснованное решение об обновлении.

К еще лучшему будущему

Описывая эти проблемы и внесенные нами изменения, я надеюсь, что дал вам представление о том, что значит разрабатывать продукт для использования во всем мире в постоянно меняющейся среде с открытым исходным кодом. В рамках этой культуры с открытым исходным кодом очень важно, чтобы мы были прозрачными с нашим сообществом пользователей и разработчиков — тем более, что компания растет, и становится все труднее поддерживать «личный контакт». Не только потому, что боль наших пользователей — это наша боль, но и потому, что это лучший способ для Elementor оставаться стабильным инструментом, открытым для максимально широкого круга пользователей.

Мы твердо верим, что внесенные нами изменения способствовали и будут способствовать росту и успеху Elementor. Тем не менее, мы также понимаем, что еще многое предстоит сделать, и что общение между Elementor и сообществом Elementor должно оставаться открытым и даже улучшаться. Например, мы обновляем наш ресурсный сайт для разработчиков, предоставляя простую в использовании документацию, чтобы помочь разработчикам настраивать и развивать Elementor.
Но, пожалуй, самый важный шаг, который мы предприняли для улучшения коммуникации, — это создание центра сообщества Elementor. Здесь создатели веб-сайтов со всего мира могут собраться, чтобы обменяться идеями друг с другом и с нами, чтобы вместе сделать Elementor лучшим, чем он может быть. В конце концов, как подсказывает старая поговорка, пасти кошек почти невозможно, но когда они работают вместе, это называется гордостью.