Herding Cats — Lições aprendidas durante o desenvolvimento para o ambiente WordPress

Quando o Elementor 3.0 foi lançado há mais de um ano, em 2020, vimos isso como um passo significativo em direção a um editor mais rápido e significativamente mais poderoso. Embora isso seja verdade, essa versão também teve consequências importantes e inesperadas – fez com que um número significativo de sites parasse de funcionar e, francamente, prejudicou nossa reputação. Após este lançamento, precisávamos de uma série de correções para que esses sites funcionassem novamente. Além disso, toda a experiência nos mostrou que precisávamos revisar todo o nosso procedimento de teste e liberação. Embora doloroso, esse processo está valendo a pena hoje, conforme refletido na queda extraordinária de problemas, especialmente os críticos, entre o lançamento de nossas versões v3.0 e v3.4:

Agora, à medida que nos aproximamos do aniversário de um ano do Elementor 3.0, é um bom momento para olhar para trás e examinar os procedimentos que implementamos para garantir que os problemas que acompanham seu lançamento não ocorram novamente. Para ser o mais transparente possível com nossa comunidade, gostaria de examinar o histórico dos problemas em torno da versão 3.0, as etapas que tomamos no ano passado, como conseguimos garantir versões estáveis ​​e o que o futuro reserva. Mas primeiro, é importante entender um pouco da história da Elementor e os desafios que enfrentamos ao desenvolver um plugin complicado e sofisticado dentro do ambiente WordPress.

Elementor e o desafio do WordPress

Em junho de 2016, quando lançamos a primeira versão do Elementor, éramos apenas alguns “crianças”, que gostavam de desenvolver plugins e ajudar as pessoas a construir sites. Este não foi nosso primeiro produto, já havíamos desenvolvido alguns plugins sendo usados ​​pela comunidade WordPress. No entanto, enquanto trabalhávamos no Elementor, ficamos convencidos de que estávamos desenvolvendo algo especial. Como se viu, estávamos certos - apenas alguns meses após nosso primeiro lançamento, dezenas de milhares de usuários já haviam instalado o Elementor e o estavam usando para criar sites em todo o mundo.

Desde então, nossa empresa cresceu em todos os sentidos, com mais desenvolvedores, mais usuários e mais recursos. Com esse crescimento veio uma série de novos problemas, incluindo um déficit tecnológico crescente, pois nos concentramos em questões urgentes, deixando de lado problemas importantes, mas mais mundanos.

Lidar com esses problemas ficou ainda mais difícil pelo desafio geral imposto pela natureza do ambiente WordPress.

Como uma plataforma aberta, o WordPress oferece uma série de grandes vantagens para os desenvolvedores. Existem alguns bloqueios no monitoramento e na desaceleração dos lançamentos. Os conceitos são imaginados, desenvolvidos e adicionados ao repositório. Os usuários experimentam, testam e julgam esses produtos, com o mercado decidindo quais irão prosperar e quais irão falhar. No entanto, essa velocidade e simplicidade têm um preço.

Há pouca uniformidade no ambiente WordPress e nenhum fluxo de trabalho ordenado. Os criadores da Web são livres para definir o ambiente de seus sites enquanto usam uma vasta gama de plugins, temas, etc. Isso significa que os sites WordPress contêm inúmeras combinações de plugins, temas e configurações de servidor.

Além disso, a simplicidade do processo de lançamento e a falta de ferramentas de implantação robustas significam que os desenvolvedores do WordPress não podem aproveitar os conceitos de lançamento modernos, como CI/CD, implantação canário e sinalizadores de recursos.

Embora a abertura seja parte da beleza do WordPress, a multiplicidade inerente de configurações de sites e servidores apresenta aos desenvolvedores um verdadeiro desafio quando se trata de contabilizar conflitos de plugins e problemas específicos do servidor.

No nosso caso, como o Elementor foi usado para mais e mais sites, a necessidade de suportar todas essas combinações diferentes estava diminuindo nosso cronograma de lançamento e até nos fez hesitar em desenvolver novos recursos. Escusado será dizer que esta situação era inaceitável e precisávamos agitar as coisas.

Desenvolvendo novos recursos sem quebrar o antigo

Todos os fatores acima nos deixaram com o dilema de como poderíamos continuar desenvolvendo e melhorando sem impactar negativamente o trabalho daqueles que já contavam com a Elementor?

Começamos implementando algumas pequenas mudanças em nosso processo de lançamento. No Elementor 1.5, começamos a oferecer aos desenvolvedores acesso às versões Beta. Fizemos isso através do Github e de outras comunidades que nos permitiram receber feedback antes de um lançamento, indicando como esta versão interagia com uma ampla variedade de combinações de plugin/tema/ambiente e nos alertando sobre quaisquer incompatibilidades desde o início. Essa abordagem funcionou bem por um tempo, mas à medida que o Elementor crescia ainda mais, descobrimos que isso não era suficiente.

A essa altura, havíamos ultrapassado o limite de cinco milhões de instalações. Embora fosse uma conquista incrível, também significava que agora éramos responsáveis ​​por todos esses sites funcionarem sem problemas.

As coisas finalmente vieram à tona com o lançamento do Elementor 3.0. Nesta versão, decidimos descartar algumas funções antigas e aparentemente obsoletas, removendo elementos DOM para aumentar a velocidade de carregamento. Isso ocorreu, pelo menos parcialmente, em resposta a reclamações justificáveis ​​de que estávamos sobrecarregando desnecessariamente o sistema.

Infelizmente, essa mudança fez com que vários sites, que dependiam do código que excluímos, quebrassem durante a atualização. Apesar de nossos esforços para trazer desenvolvedores de terceiros para o processo, esses bugs permaneceram desconhecidos e tivemos que agir rapidamente para corrigir a situação. No final, conseguimos fazer isso tornando parte da atualização opcional, mas não antes de alguns membros de nossa comunidade terem sua confiança abalada na estabilidade do nosso plugin.

Essa experiência nos obrigou a dar uma olhada longa e cuidadosa em nosso processo de desenvolvimento, com o objetivo de fazer uma série de mudanças importantes. Nossos processos simplesmente não eram adequados para uma empresa do nosso porte e base instalada. A primeira, e talvez a mais óbvia, foi aumentar o tamanho e o escopo de nossa equipe de controle de qualidade, mas isso ainda nos deixou com vários problemas pendentes:

• Verificando a compatibilidade de uma versão com inúmeras configurações de site
• Garantir a compatibilidade com versões anteriores com mais de cinco milhões de sites existentes
• Verificando a compatibilidade de centenas de extensões Elementor de terceiros

Para lidar com todos esses problemas, precisávamos trazer métodos de desenvolvimento de software mais atualizados para o mundo WordPress.

O Ciclo de Feedback

Um dos grandes problemas do desenvolvimento, em geral, é que os usuários só experimentam as atualizações depois de lançadas. Isso significa que um recurso já foi projetado, desenvolvido e lançado no momento em que recebemos qualquer feedback dos usuários. No nosso caso, lidando com centenas de centenas de extensões e plugins de terceiros, o problema desse ciclo de feedback é ainda mais importante.

Ao procurar maneiras de encurtar esse ciclo de feedback, analisamos como os desenvolvedores de navegadores lidam com problemas bastante semelhantes aos nossos – eles também precisam garantir a compatibilidade com inúmeras páginas da Web, aplicativos, extensões e muito mais de terceiros.

Por exemplo, examinamos o sistema desenvolvido pelo Google para o navegador Chrome. A qualquer momento, os desenvolvedores têm acesso a três versões do navegador – uma versão beta, uma versão dev e uma versão noturna. Isso significa que os desenvolvedores têm uma visão antecipada dos novos recursos do Chrome e podem começar a dar feedback ao Google muito antes de a versão ser lançada oficialmente.

Aplicando essas lições ao nosso plugin, a Elementor começou a lançar sua própria edição para desenvolvedores – Elementor Beta (Developer Edition), disponível no repositório do WordPress e voltada para desenvolvedores interessados ​​em conferir nossos novos recursos “quentes das impressoras”, por assim dizer.

Para nós, é claro, nos beneficiamos ao receber avisos antecipados de problemas de compatibilidade. A edição do desenvolvedor não apenas permite que os usuários acessem todos esses novos recursos, mas também há um link direto para o Github para relatar bugs. Isso significa que podemos implantar continuamente novos recursos e receber feedback sobre eles, sem colocar em risco os sites existentes. Para os desenvolvedores, isso permite que eles se preparem para os próximos lançamentos oficiais com bastante antecedência, ajudando a evitar seus próprios problemas de compatibilidade e também dando a eles a oportunidade de fornecer feedback técnico e do produto enquanto o recurso ainda está sendo trabalhado.

Deve-se notar que as versões da edição do desenvolvedor são executadas em paralelo ao normal - alfa, beta, RC e produção - um processo usado para desenvolver versões do Elementor. Quando desenvolvemos um novo recurso, assim que ele estiver estável o suficiente para ser usado, mas enquanto ainda estiver em alfa, o adicionamos à edição do desenvolvedor. Dessa forma, nossos desenvolvedores podem nos dar feedback, mesmo antes do recurso chegar à versão beta. Isso também significa que a edição do desenvolvedor inclui recursos que não atingiram o estágio beta.

Essencialmente, o estágio beta é reservado para um processo de depuração deliberado, enquanto a edição do desenvolvedor é atualizada com mais frequência, incorporando recursos em seus estágios iniciais.

Desde a sua introdução, a edição dos desenvolvedores provou ser um grande sucesso, acumulando mais de 40 mil instalações em menos de um ano.

Apresentando recursos “experimentais”

Ao longo dos anos, outro conceito que os desenvolvedores adotaram são os sinalizadores de recursos, que são especialmente predominantes no mundo do SaaS. A ideia geral é que esses sinalizadores de recursos permitem que os desenvolvedores testem novos recursos, ativando-os e desativando-os para diferentes segmentos de usuários para testá-los e ver como eles funcionam.

Como mencionado acima, muitos dos problemas decorrentes do lançamento do 3.0 foram devidos a novos recursos eliminando códigos antigos. Para evitar esses tipos de problemas, decidimos adotar uma abordagem semelhante à dos sinalizadores de recursos.

A partir do Elementor 3.1, começamos a lançar novos recursos com mais cuidado, sinalizando-os como “experimentais”. Isso inclui um sistema de introdução de novos recursos em etapas. Neste sistema, um recurso recém-desenvolvido será sinalizado como “Alpha”. Isso significa que está desativado, por padrão, em todos os sites. À medida que se mostra mais estável, torna-se um “Beta”, o que significa que agora está ativado, por padrão, para novos sites e desativado para sites existentes. Quando temos certeza de que está estável, ele é ativado, por padrão, para todos os sites. Mesmo assim, haverá uma opção para os usuários desativarem o recurso, por tempo limitado.

Esse sistema nos permite continuar desenvolvendo o Elementor, adicionando tanto ao seu conjunto de recursos quanto à sua velocidade, enquanto permite que os criadores ativem ou desativem essas novas atualizações de acordo com as necessidades de seu site. Isso também ajuda os criadores a atualizar seus sites, permitindo que adotem novos recursos com mais cuidado.

Etiquetas de compatibilidade

O crescimento da comunidade de desenvolvedores muito ativa da Elementor tem sido uma grande fonte de orgulho, mas também apresentou seus próprios desafios. Desenvolvedores de terceiros criaram centenas de extensões, temas, kits e widgets, todos baseados em nossa tecnologia existente.

Para oferecer suporte aos desenvolvedores desses complementos de terceiros, usamos o blog de nossos desenvolvedores e nossa lista de e-mails para notificá-los antecipadamente sobre as alterações que estávamos fazendo na API, bem como sobre as descontinuações. No entanto, como mencionado acima, descobrimos que isso não era suficiente. Muitos dos problemas que estávamos enfrentando com novos lançamentos estavam enfrentando problemas de compatibilidade devido a esses complementos de terceiros. Nosso plugin foi visto como instável, não por causa de nossa tecnologia, mas por causa dessas incompatibilidades de terceiros.

Mais uma vez, procuramos inspiração no que os outros estavam fazendo. Neste caso, WooCommerce e sua abordagem para trabalhar com desenvolvedores de terceiros. A partir de nossa versão 3.1, iniciamos um sistema em que desenvolvedores terceirizados certificam que suas extensões são compatíveis com a nova versão (Saiba mais). Em seguida, quando os usuários têm a opção de atualizar o Elementor, eles recebem uma lista de extensões de terceiros que estão usando e se foram ou não certificados como compatíveis com a nova versão do Elementor. Desta forma, os usuários podem tomar uma decisão informada sobre a atualização.

Rumo a um futuro ainda melhor

Ao descrever esses desafios e as mudanças que implementamos, espero ter dado a você um vislumbre de como é desenvolver um produto para uso mundial, em um ambiente de código aberto e em constante mudança. Como parte dessa cultura de código aberto, é fundamental que sejamos transparentes com nossa comunidade de usuários e desenvolvedores – ainda mais à medida que a empresa cresce e fica mais difícil manter um “toque pessoal”. Não apenas porque a dor de nossos usuários é a nossa dor, mas porque é a melhor maneira de o Elementor permanecer uma ferramenta estável, aberta ao maior número possível de usuários.

Acreditamos firmemente que as mudanças que implementamos contribuíram e continuarão a contribuir para o crescimento e sucesso da Elementor. No entanto, também estamos cientes de que ainda há trabalho a ser feito e que a comunicação entre a Elementor e a comunidade Elementor deve permanecer aberta e até melhorada. Por exemplo, estamos atualizando nosso site de recursos para desenvolvedores, fornecendo documentação fácil de usar para ajudar os desenvolvedores a personalizar e desenvolver o Elementor.
Mas talvez o passo mais importante que demos para melhorar a comunicação seja estabelecer o Elementor Community Hub. Aqui, criadores da web em todo o mundo podem se reunir para trocar ideias entre si e conosco - colaborando juntos para tornar o Elementor o melhor que pode ser. Afinal, como sugere o velho ditado, pastorear gatos pode ser quase impossível, mas quando eles trabalham juntos, isso se chama Orgulho.