猫番 — WordPress 環境向けの開発中に学んだ教訓

公開: 2021-12-02

1 年以上前の 2020 年に Elementor 3.0 がリリースされたとき、私たちはそれを、より高速で大幅に強力なエディターに向けた重要な一歩と見なしました。 それは事実ですが、このバージョンは重要で予期しない結果ももたらしました。かなりの数のサイトが機能しなくなり、率直に言って、私たちの評判を傷つけました。 このリリースに続いて、これらのサイトを再び機能させるために、一連の修正を行う必要がありました。 さらに、全体的な経験から、テストとリリースの手順全体をオーバーホールする必要があることがわかりました。 v3.0 バージョンと v3.4 バージョンのリリースの間に問題、特に重大な問題が大幅に減少したことに反映されているように、このプロセスは苦痛ではありますが、今日成果を上げています。

Elementor 3.0 の 1 周年を迎える今、リリースに伴う問題が再び発生しないようにするために導入した手順を振り返り、検討する良い機会です。 私たちのコミュニティに対して可能な限り透明性を保つために、3.0 リリースにまつわる問題の背景、過去 1 年間に行った手順、安定したリリースを確保する方法、および将来の展望について検討したいと思います。 ただし、最初に、Elementor の歴史と、WordPress 環境内で複雑で洗練されたプラグインを開発する際に直面する課題について理解することが重要です。

目次

  • Elementor と WordPress チャレンジ
  • 古いものを壊さずに新しい機能を開発する
  • フィードバック ループ
  • 「実験的」機能の紹介
  • 互換性タグ
  • より良い未来へ

Elementor と WordPress チャレンジ

2016 年 6 月に Elementor の最初のバージョンをリリースしたとき、私たちはプラグインを開発し、人々が Web サイトを構築するのを手伝うのが好きな、ほんの数人の「子供」でした。 これは私たちの最初の製品ではなく、WordPress コミュニティで使用されているいくつかのプラグインをすでに開発していました。 しかし、Elementor に取り組んでいくうちに、何か特別なものを開発していると確信するようになりました。 結局のところ、私たちは正しかった - 最初のリリースからわずか数か月後、何万人ものユーザーがすでに Elementor をインストールし、それを使用して世界中の Web サイトを構築していました。

それ以来、私たちの会社はあらゆる面で成長し、開発者、ユーザー、機能が増えました。 この成長に伴い、多くの新しい問題が発生しました。これには、重要ではあるがより平凡な問題を脇に置いて、緊急の問題に焦点を合わせたため、テクノロジーの不足が拡大したことが含まれます。

これらの問題への対処は、WordPress 環境の性質によってもたらされる全体的な課題によってさらに困難になりました。

オープン プラットフォームとして、WordPress は開発者に多くの大きな利点を提供します。 リリースの監視とスローダウンには、いくつかの障害があります。 概念が想像され、開発され、リポジトリに追加されます。 ユーザーはこれらの製品を試し、テストし、判断し、市場が成功する製品と失敗する製品を決定します。 ただし、この速度とシンプルさには代償が伴います。

WordPress 環境には統一性がほとんどなく、整然としたワークフローはありません。 Web 作成者は、膨大な数のプラグイン、テーマなどを使用しながら、サイトの環境を自由に定義できます。つまり、WordPress サイトには、プラグイン、テーマ、およびサーバー構成の無数の組み合わせが含まれています。

さらに、リリース プロセスがシンプルで、堅牢なデプロイ ツールがないということは、WordPress 開発者が CI/CD、カナリア デプロイ、フィーチャー フラグなどの最新のリリース コンセプトを活用できないことを意味します。

オープン性は WordPress の優れた点の 1 つですが、固有の多数のサイトおよびサーバー構成により、開発者はプラグインの競合や特定のサーバーの問題を考慮する際に真の課題に直面します。

私たちの場合、Elementor がますます多くの Web サイトで使用されるようになると、これらのさまざまな組み合わせをすべてサポートする必要があるため、リリース スケジュールが遅くなり、新機能の開発を躊躇することさえありました。 言うまでもなく、このような状況は容認できず、状況を一新する必要がありました。

古いものを壊さずに新しい機能を開発する

上記のすべての要因により、すでに Elementor に依存している人々の作業に悪影響を与えることなく、開発と改善を継続するにはどうすればよいかというジレンマが残りました。

リリース プロセスに小さな変更を加えることから始めました。 Elementor 1.5 では、ベータ版へのアクセスを開発者に提供し始めました。 これは Github やその他のコミュニティを通じて行い、リリース前にフィードバックを受け取ることができました。これにより、このバージョンがさまざまなプラグイン/テーマ/環境の組み合わせとどのように相互作用したかを示し、早い段階で非互換性を警告してくれました。 このアプローチはしばらくの間うまくいきましたが、Elementor がさらに成長するにつれて、これでは不十分であることがわかりました。

この時点で、500 万のインストールしきい値を超えていました。 信じられないほどの成果であると同時に、これらすべての Web サイトがスムーズに機能するようになったことも意味します。

Elementor 3.0のリリースにより、事態はついに頭角を現しました。 このバージョンでは、古い、一見時代遅れの機能を削除し、読み込み速度を上げるために DOM 要素を削除することにしました。 これは、少なくとも部分的には、システムに不必要に負荷をかけているという正当な苦情への対応でした。

残念ながら、この変更により、削除したコードに依存していた多くのサイトがアップグレード中に機能しなくなりました。 サードパーティの開発者をプロセスに参加させる努力にもかかわらず、これらのバグは発見されず、状況を修正するために迅速に動く必要がありました。 最終的に、アップグレードの一部をオプションにすることでこれを行うことができましたが、コミュニティの一部のメンバーがプラグインの安定性に自信を持って動揺する前ではありませんでした.

この経験により、多くの大きな変更を行うことを視野に入れて、開発プロセスをじっくりと検討する必要がありました。 私たちのプロセスは、私たちの規模と設置ベースの会社にはまったく適していませんでした。 最初の、そしておそらく最も明白な動きは、QA チームの規模と範囲を拡大することでしたが、それでもまだ未解決の問題がいくつか残っていました。

  • 無数のサイト設定とバージョンの互換性を確認する
  • 500 万を超える既存サイトとの下位互換性を確保
  • 何百ものサードパーティ Elementor 拡張機能の互換性を確認する

これらすべての問題に対処するために、WordPress の世界に最新のソフトウェア開発方法を導入する必要がありました。

フィードバック ループ

一般的に、開発が直面する大きな問題の 1 つは、ユーザーが更新プログラムをリリースしてからしか体験できないことです。 これは、ユーザーからフィードバックを受け取るまでに、機能がすでに設計、開発、リリースされていることを意味します。 私たちの場合、何百ものサードパーティの拡張機能とプラグインを扱っているため、このフィードバック ループの問題はさらに重要です。

このフィードバック ループを短縮する方法を模索する中で、ブラウザー開発者が私たち自身の問題と非常によく似た問題にどのように対処しているかを調べました。また、無数のサードパーティの Web ページ、アプリ、拡張機能などとの互換性を確保する必要があります。

たとえば、Google が Chrome ブラウザ用に開発したシステムを調べました。 開発者はいつでも、ベータ版、開発版、夜間版の 3 つのバージョンのブラウザーにアクセスできます。 これは、開発者が新しい Chrome 機能をいち早く見て、バージョンが正式にリリースされるずっと前に Google にフィードバックを提供し始めることができることを意味します。

これらの教訓をプラグインに適用して、Elementor は独自の開発者版のリリースを開始しました – Elementor Beta (開発者版) は、WordPress リポジトリから入手でき、いわば「プレスからすぐに」新機能をチェックすることに関心のある開発者を対象としています。

もちろん、私たちにとっても、互換性の問題について早期に警告を受けることは有益です。 開発者版では、ユーザーがこれらすべての新機能にアクセスできるだけでなく、バ​​グを報告するための Github への直接リンクもあります。 これは、既存の Web サイトを危険にさらすことなく、新しい機能を継続的に展開し、それらに関するフィードバックを受け取ることができることを意味します。 開発者は、これにより、今後の公式リリースに向けて事前に準備を整えることができ、互換性の問題を防ぐことができ、機能の開発中に製品および技術的なフィードバックを提供する機会を得ることができます。

開発者版のリリースは、Elementor リリースの開発に使用される通常のプロセス (アルファ、ベータ、RC、および製品) と並行して実行されることに注意してください。 新しい機能を開発するときは、それが十分に安定して使用できるようになったらすぐに、まだアルファ版である間に、開発者版に追加します。 このようにして、機能がベータ版に達する前であっても、開発者はフィードバックを提供できます。 また、開発者版にはベータ段階に達していない機能が含まれていることも意味します。

基本的に、ベータ段階は意図的なデバッグ プロセスのために予約されていますが、開発者版はより頻繁に更新され、最も初期の段階で機能が組み込まれています。

導入以来、開発者向けエディションは大きな成功を収めており、1 年足らずで 4 万回以上のインストールを獲得しています。

「実験的」機能の紹介

長年にわたり、開発者が採用してきたもう 1 つの概念は、SaaS の世界で特に普及している機能フラグです。 一般的な考え方は、これらの機能フラグを使用すると、開発者はさまざまなユーザー セグメントに対して新しい機能をオンまたはオフにしてテストし、それらがどのように機能するかを確認できるようになるというものです。

前述のように、3.0 のリリースに起因する問題の多くは、古いコードを削除する新しい機能が原因でした。 この種の問題を回避するために、機能フラグと同様のアプローチを採用することにしました。

Elementor 3.1 から、新機能のリリースをより慎重に開始し、「実験的」としてフラグを立てました。 これには、新機能を段階的に導入するシステムが含まれます。 このシステムでは、新しく開発された機能は「アルファ」としてフラグが立てられます。 これは、すべてのサイトでデフォルトでオフになっていることを意味します。 より安定していることが証明されると、「ベータ」になります。つまり、新しいサイトではデフォルトで有効になり、既存のサイトでは無効になります。 安定していることを確認したら、デフォルトですべてのサイトでオンにします。 その場合でも、期間限定で、ユーザーが機能を無効にするオプションがあります。

このシステムにより、Elementor の開発を継続し、機能セットと速度の両方を追加しながら、クリエイターはサイトのニーズに応じてこれらの新しいアップグレードをオプトインまたはオプトアウトできます。 これは、クリエイターが新しい機能をより慎重に採用できるようにすることで、サイトを更新するのにも役立ちます。

互換性タグ

Elementor の非常に活発な開発者コミュニティの成長は大きな誇りですが、独自の課題ももたらしました。 サードパーティの開発者は、既存のテクノロジーに基づいて、何百もの拡張機能、テーマ、キット、およびウィジェットを作成しました。

これらのサードパーティ アドオンの開発者をサポートするために、開発者のブログとメーリング リストを使用して、API に加えた変更と非推奨について早期に通知しました。 しかし、前述のとおり、これでは不十分であることがわかりました。 新しいリリースで発生した問題の多くは、これらのサードパーティ アドオンが原因で互換性の問題が発生していました。 私たちのプラグインは、私たちの技術のためではなく、これらのサードパーティの非互換性のために不安定であると見なされていました.

繰り返しになりますが、私たちは他の人がインスピレーションを得るために何をしているかに注目しました。 この場合、WooCommerce と、サードパーティの開発者と協力するアプローチです。 3.1 リリースから、サードパーティの開発者が拡張機能が新しいバージョンと互換性があることを証明するシステムを開始しました (詳細)。 次に、Elementor をアップグレードするオプションがユーザーに与えられると、使用しているサードパーティの拡張機能のリストと、Elementor の新しいバージョンとの互換性が認定されているかどうかが表示されます。 このようにして、ユーザーはアップグレードについて情報に基づいた決定を下すことができます。

より良い未来へ

これらの課題と私たちが実装した変更の概要を説明することで、オープンソースの絶え間なく変化する環境で、世界中で使用される製品を開発することがどのようなものかを垣間見ることができたと思います. このオープンソース文化の一環として、ユーザーと開発者のコ​​ミュニティに対して透明性を保つことが重要です。会社が成長し、「個人的な関係」を維持することがより困難になるにつれて、その透明性はさらに高まります。 ユーザーの痛みが私たちの痛みであるという理由だけでなく、Elementor が安定したツールであり続け、可能な限り幅広いユーザーに開かれているためです。

私たちが実施した変更は、Elementor の成長と成功に貢献し、今後も貢献し続けると強く信じています。 ただし、まだやるべきことがあり、Elementor と Elementor コミュニティの間のコミュニケーションはオープンであり、さらには改善されなければならないことも認識しています。 たとえば、開発者リソース サイトをアップグレードし、使いやすいドキュメントを提供して、開発者が Elementor をカスタマイズおよび構築するのに役立つようにしています。
しかし、コミュニケーションを改善する上でおそらく最も重要なステップは、Elementor コミュニティ ハブを確立したことです。 ここでは、世界中の Web クリエイターが集まり、互いにアイデアを交換したり、私たちと協力して Elementor を最高のものにすることができます。 結局のところ、古いことわざが示唆するように、猫を放牧することはほとんど不可能かもしれませんが、彼らが一緒に働くとき、それはプライドと呼ばれます.