Seis boas práticas para projetos de website no Adobe Experience Manager

Mas tal como acontece com cada produto de uma escala tão elevada, também é muito fácil tomar as decisões erradas. O AEM é um produto muito flexível que permite várias personalizações. Isto significa que qualquer requisito pode traduzir-se em diferentes tipos de implementações, variando desde uma solução feita por medida até uma solução que esteja estreitamente alinhada com os princípios fundamentais do produto.

Dado que temos uma vasta experiência na implementação do AEM e de sistemas de gestão de conteúdos Web empresariais em geral, conhecemos os desafios de escolher uma das várias direções de solução. Além da arquitetura da solução e do eventual aprofundamento técnico, é importante pensar também em termos de rentabilidade, sustentabilidade e garantia de que o seu sistema está preparado para o futuro.

Nesta publicação, destacaremos alguns dos principais fatores que deve ter sempre em mente quando implementar o AEM.

#1 Design e arquitetura

No que respeita ao design e à arquitetura do website, o seu primeiro passo deve ser a análise exaustiva de cada requisito e a harmonização com capacidades prontas a utilizar o mais cedo possível. Podem ser utilizados protótipos para comunicar soluções alternativas aos utilizadores empresariais e para demonstrar certas capacidades originais. Na maioria dos casos, é possível alcançar um volume substancial de eficiência através de uma ligeira adaptação dos requisitos iniciais.

Alguns exemplos:

• Potenciar o quadro de configuração consciente do contexto para que as subpartes do website fiquem diferentes e se comportem de forma diferente;
• Restituir listas de documentos provenientes de sistemas externos através do quadro de Sling Dynamic Include para que as páginas que as contêm continuem a ser cacheáveis;
• Utilizar o Sling Resource Merger para evitar a duplicação de componentes originais;
• Remover o CSS responsivo e potenciar funcionalidade dentro do AEM para o mesmo;
• Implementar certos requisitos fora do AEM, por exemplo, integrando-os em (micro)serviços externos. Tal é fundamental para evitar a utilização inadequada do AEM como um WCMS;
• Tornar mais de 95% dos pedidos cacheáveis, garantindo um elevado desempenho.

#2 Componentes essenciais

Há alguns anos, a Adobe iniciou uma iniciativa chamada WCM Core Components. A ideia era afastar-se dos antigos "Foundation Components" que estavam desatualizados e fornecer em vez disso uma biblioteca sólida de componentes com base nos quais cada projeto poderia estender-se.

Esta biblioteca de Core Components (componentes essenciais) fornece aos utilizadores empresariais um conjunto de blocos de construção de elevada qualidade para criar páginas Web avançadas. Com base nos mesmos princípios, também desenvolvemos o nosso próprio conjunto de componentes (específicos do projeto). Tal também significa que contribuímos ativamente para os Core Components para os ajudar a melhorar ao longo do tempo.

Ao utilizar estes componentes e fortalecer as ideias por detrás dos mesmos, conseguimos criar bases de códigos extremamente flexíveis e obter a possibilidade de atualizar os componente um a um, sem quebrar a compatibilidade com versões anteriores.

#3 Editable Templates

Anteriormente, disponibilizar um conjunto de modelos de página aos utilizadores empresariais era uma tarefa do programador: antes de um autor de conteúdos poder utilizar um modelo específico, um programador teria primeiro de implementar esse modelo e implantá-lo no AEM. Isto resultou muitas vezes no aumento do time-to-market.

Contudo, nos últimos anos, uma funcionalidade chamada "Editable Templates" foi disponibilizada no AEM para reduzir a dependência das TI durante a criação de páginas. A "Editable Templates" permite que os autores de conteúdos elaborem eles mesmos os modelos, utilizando a interface Touch UI do AEM.

#4 Grelha Responsiva e Sistema de Estilos

Através da utilização de Grelhas Responsivas, os utilizadores empresariais podem lidar com os layouts de página e comportamentos dos componentes de forma flexível. Em combinação com o Sistema de Estilos do AEM, pode ser aplicado um estilo predefinido sem sacrificar a consistência entre páginas.

O fluxo de trabalho tradicional para tornar o conteúdo responsivo necessitava de um designer para criar maquetas para os diferentes pontos de interrupção, do programador para as implementar para um modelo específico e do autor para escolher esse modelo e preencher o conteúdo. Com Grelhas Responsivas, este fluxo de trabalho foi drasticamente simplificado: o autor preenche o conteúdo e pode adaptar o layout de forma autónoma, sem a necessidade de consultar um programador relativamente à responsividade ou de esperar por novas implantações. Esta funcionalidade, introduzida no AEM 6.3, proporciona flexibilidade para os utilizadores empresariais, não exigindo simultaneamente programadores para executar estas tarefas. Por fim, não é necessário qualquer esforço de desenvolvimento (e implantação) para alterar um modelo.

Contudo, esta flexibilidade tem um preço: os utilizadores empresariais têm agora de gerir as configurações de layout dos componentes nas páginas, o que pode exigir grandes esforços. Muitas vezes é melhor encontrar um meio termo, em que algumas configurações de layout sejam fixas e outras tenham flexibilidade. Podemos ajudá-lo a encontrar o equilíbrio certo.

#5 Boas práticas de desenvolvimento Web

Existem igualmente boas práticas de desenvolvimento geral e normas técnicas específicas do AEM que aplicamos em todos os projetos AEM. Resumindo algumas delas:

• Quem estraga a construção; arranja a construção;
• São necessários testes de unidade e testes de integração para cada nova funcionalidade;
• Quando uma funcionalidade está concluída, têm de ser enviados pedidos de fusão;
• Um responsável técnico tem de realizar uma revisão pelos pares;
• Têm de ser utilizados Modelos Sling para o desenvolvimento de componentes, mesmo que o componente seja muito simples;
• Utilize o Padrão do Componente Proxy;
• A documentação técnica e do utilizador tem de estar sempre atualizada;
• O código tem de ser testado no AEM, bem como através do Dispatcher;
• Duplicação de códigos não autorizada, configuração de regras SonarQube, cada construção aciona uma análise SonarQube, etc.

#6 Automatização total

Para aumentar a qualidade do nosso trabalho, procuramos maximizar a automatização. Para instalações locais do AEM 6.5, utilizamos a infraestrutura como código para automatizar a criação de servidores, bem como os nossos ambientes locais. Isto significa que qualquer programador pode estar criado e a funcionar em alguns minutos e a trabalhar num ambiente local o mais próximo possível da produção. Esta criação até inclui uma instância de Dispatcher local, para garantir que também apanhamos de imediato as armadilhas de cache.

Para instalações de AEM como serviço na nuvem, recebemos uma grande ajuda do Cloud Manager da Adobe, que automatiza totalmente, atualiza, faz correções de segurança e lançamentos, em combinação com portas de qualidade predefinidas e personalizadas.

Sempre que uma mudança de código seja verificada num controlo de versão, é executada uma construção e os programadores são notificados instantaneamente quando algo corre mal. Dependendo da sucursal específica, será efetuada uma implantação no ambiente aplicável, para que as alterações estejam presentes de imediato no sistema correto.

Na sequência destes princípios, somos flexíveis na realização dos nossos lançamentos de forma totalmente automatizada. Uma implantação para a produção é apenas o pressionar de um botão.

Conclusão

É essencial conhecer as boas práticas mais recentes específicas do desenvolvimento de websites no WCMS em que trabalha. Mas talvez mais importante, ter um parceiro que as conheça e também as aplique no seio da equipa do projeto é essencial para o sucesso do seu projeto de experiência digital. Estas orientações não são valiosas apenas quando cria novos websites, mas também quando planeia atualizações ou uma expansão da sua plataforma Adobe existente.