As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Organização e formas de trabalhar
Como acontece com todas as estratégias de arquitetura, os microfrontends têm implicações muito além da tecnologia que uma organização escolhe implementar. A decisão de criar aplicativos de microfront-end deve estar alinhada aos negócios, produtos, organização, operações e até mesmo à cultura (por exemplo, capacitando equipes e descentralizando a tomada de decisões). Em troca, esse tipo de arquitetura de microfrontend oferece suporte ao desenvolvimento verdadeiramente ágil e orientado ao produto, pois reduz significativamente a sobrecarga de comunicação entre equipes independentes.
Desenvolvimento ágil
A ideia de desenvolvimento ágil de software se tornou tão universal nos últimos anos que praticamente todas as organizações afirmam trabalhar com agilidade. Embora uma definição conclusiva de ágil esteja além do escopo dessa estratégia, vale a pena revisar os principais elementos que são relevantes para o desenvolvimento de microfrontend.
A base do paradigma ágil é o Manifesto Ágil
No contexto da arquitetura de microfrontend, é importante adotar os seguintes princípios ágeis:
-
“Forneça software funcional com frequência, de algumas semanas a alguns meses, com preferência por prazos mais curtos.”
Esse princípio enfatiza a importância de trabalhar em incrementos e entregar software para produção com a maior regularidade e frequência possível. Do ponto de vista tecnológico, isso se refere à integração contínua e entrega contínua (CI/CD). Em CI/CD, as ferramentas e os processos para criação, teste e implantação são partes integrantes de cada projeto de software. O princípio também implica que a infraestrutura de tempo de execução e as responsabilidades operacionais devem pertencer à equipe. Essa propriedade é especialmente importante em sistemas distribuídos, nos quais subsistemas independentes podem ter requisitos significativamente diferentes de infraestrutura e operações.
-
“Crie projetos em torno de indivíduos motivados. Ofereça a eles o ambiente e o suporte de que precisam e confie neles para realizar o trabalho.”
“As melhores arquiteturas, requisitos e projetos surgem de equipes auto-organizadas.”
Ambos os princípios enfatizam os benefícios da propriedade, independência e end-to-end responsabilidade. Uma arquitetura de microfrontend será bem-sucedida quando (e somente quando) as equipes realmente possuírem seus microfront-ends. A nd-to-end responsabilidade desde a concepção, passando pelo design e implementação, até a entrega e operação, garante que a equipe possa realmente exercer a propriedade. Essa independência é necessária, tanto técnica quanto organizacionalmente, para que a equipe tenha autonomia sobre a direção estratégica. Não recomendamos o uso de uma plataforma de microfrontend em uma organização centralizada que usa um modelo de desenvolvimento em cascata.
Composição e tamanho da equipe
Para que uma equipe de software exerça a propriedade, ela deve governar a si mesma, incluindo como e o que a equipe entrega, dentro dos limites impostos pela organização.
Para serem eficazes, as equipes devem ser capazes de fornecer software de forma independente e ter autoridade para decidir a melhor maneira de entregá-lo. Uma equipe que recebe requisitos de recursos de um gerente de produto externo ou projetos de interface de usuário de um designer externo, sem estar envolvida no planejamento desses itens, não pode ser considerada autônoma. Os recursos podem violar contratos ou funcionalidades existentes. Essas violações exigirão mais discussões e negociações, com o risco de atrasar a entrega e introduzir conflitos desnecessários entre as equipes.
Ao mesmo tempo, as equipes não devem se tornar muito grandes. Embora uma equipe maior tenha mais recursos e possa acomodar ausências individuais, a complexidade da comunicação cresce exponencialmente com cada novo membro. Não é possível declarar um tamanho máximo de equipe universalmente válido. O número de pessoas necessárias para um projeto depende de fatores como maturidade da equipe, complexidade técnica, ritmo de inovação e infraestrutura. Por exemplo, a Amazon segue a regra das duas pizzas: uma equipe grande demais para ser alimentada com duas pizzas deve ser dividida em equipes menores. Isso pode ser um desafio. A divisão deve ocorrer de acordo com limites naturais e deve dar a cada equipe autonomia e propriedade sobre seu trabalho.
DevOps cultura
DevOps refere-se a uma prática de engenharia de software em que as etapas do ciclo de vida de desenvolvimento são fortemente integradas do ponto de vista organizacional e técnico. Ao contrário da crença popular, DevOps tem muito a ver com cultura e mentalidade, e muito pouco com papéis e ferramentas.
Tradicionalmente, uma organização de software teria equipes de especialistas, como para design, implementação, teste, implantação e operações. Sempre que uma equipe concluía seu trabalho, ela entregava o projeto para a próxima equipe. No entanto, a entrega de software por meio de silos de equipes especializadas causa atrito durante as entregas. Ao mesmo tempo, quando especialistas são forçados a trabalhar com um foco estreito, eles carecem de conhecimento em domínios vizinhos e não têm uma visão sistêmica do produto. Esses déficits podem levar à baixa coerência do produto de software.
Por exemplo, quando um arquiteto de software projeta uma solução que deve ser implementada por alguém de uma equipe diferente, ele pode ignorar aspectos inerentes da implementação (como uma incompatibilidade de dependências). Os desenvolvedores então usam atalhos (como um monkey patch) ou uma formalização back-and-forth é iniciada entre o arquiteto e a equipe de desenvolvimento. Devido à sobrecarga de gerenciar esses processos, o desenvolvimento não é mais ágil (no sentido de flexível, adaptativo, incremental e informal).
Embora o termo se refira DevOps principalmente à cultura, ele implica as tecnologias e processos que DevOps possibilitam na prática. DevOps está intimamente relacionado ao CI/CD. Quando um desenvolvedor termina de implementar um incremento de software, ele o submete a um sistema de controle de versão, como o Git. Tradicionalmente, um sistema de compilação criava e integrava o software, testando-o e lançando-o em um processo mais ou menos unificado e centralizado. Com o CI/CD, a criação, a integração, o teste e o lançamento do software são inerentes e automatizados. Idealmente, o processo faz parte do próprio projeto de software por meio de arquivos de configuração personalizados especificamente para o projeto em questão.
O maior número possível de etapas é automatizado. Por exemplo, as práticas de teste manual devem ser reduzidas, porque quase todos os tipos de testes podem ser automatizados. Quando o projeto é configurado dessa forma, as atualizações de um produto de software podem ser entregues várias vezes ao dia com alta confiança. Outra tecnologia que oferece suporte DevOps é a infraestrutura como código (IaC).
Tradicionalmente, configurar e manter a infraestrutura de TI exigiria o trabalho manual de instalação e manutenção de hardware (configuração de cabos e servidores em um data center) e software operacional. Isso era necessário, mas tinha inúmeras desvantagens. A configuração era demorada e propensa a erros. O hardware geralmente era superprovisionado ou subprovisionado, resultando em gastos excessivos ou diminuição do desempenho. Ao usar o IaC, você pode descrever os requisitos de infraestrutura de um sistema de TI por meio de um arquivo de configuração a partir do qual os serviços em nuvem podem ser implantados e atualizados automaticamente.
O que tudo isso tem a ver com microfront-ends? DevOps, CI/CD e IaC são complementos ideais para uma arquitetura de microfrontend. Os benefícios dos microfront-ends dependem de processos de entrega rápidos e sem atrito. Uma DevOps cultura só pode prosperar em ambientes em que as equipes possuem projetos de software com end-to-end responsabilidade.
Orquestrando o desenvolvimento de microfront-end em várias equipes
Ao escalar o desenvolvimento de microfront-end em várias equipes multifuncionais, surgem dois problemas: primeiro, as equipes começam a desenvolver sua própria interpretação do paradigma, fazer escolhas de estrutura e biblioteca e criar suas próprias ferramentas e bibliotecas auxiliares. Em segundo lugar, equipes totalmente autônomas devem assumir a responsabilidade por recursos genéricos, como gerenciamento de infraestrutura de baixo nível. Portanto, faz sentido introduzir duas equipes adicionais em uma organização de micro-frontend com várias equipes: uma equipe de capacitação e uma equipe de plataforma. Esses conceitos são amplamente adotados em organizações de TI modernas com sistemas distribuídos e estão bem documentados em Team Topologies
O diagrama a seguir mostra a equipe de capacitação fornecendo ferramentas, bibliotecas, padrões e testes para três equipes de microfrontend. A equipe da plataforma fornece infraestrutura, recursos de tempo de execução compartilhados e serviços de domínio para essas mesmas três equipes de microfront-end.
A equipe da plataforma apoia as equipes de microfrontend, libertando-as do trabalho pesado indiferenciado. Esse suporte pode incluir serviços de infraestrutura, como tempos de execução de contêineres, pipelines de CI/CD, ferramentas de colaboração e monitoramento. No entanto, a criação de uma equipe de plataforma não deve levar a uma organização na qual o desenvolvimento esteja separado das operações. O oposto é verdadeiro: a equipe da plataforma oferece um produto de engenharia, e as equipes de microfrontend têm a propriedade e a responsabilidade pelo tempo de execução de seus serviços na plataforma.
A equipe de capacitação fornece suporte concentrando-se na governança e garantindo a consistência entre as equipes de microfront-end. (A equipe da plataforma não deve se envolver com isso.) A equipe de capacitação mantém recursos compartilhados, como uma biblioteca de interface do usuário, e cria padrões como escolha de estrutura, orçamentos de desempenho e convenções de interoperabilidade. Ao mesmo tempo, fornece treinamento para novas equipes ou membros da equipe na aplicação de padrões e ferramentas, conforme definido pela governança.
Implantação
O norte da autonomia em equipes de microfront-end é ter um pipeline automatizado com um caminho de produção independente de outras equipes de microfrontend. As equipes que seguem o princípio de não compartilhar nada podem implementar pipelines independentes. As equipes que compartilham bibliotecas ou dependem de uma equipe de plataforma devem decidir como gerenciar dependências nos pipelines de implantação.
Normalmente, cada pipeline faz o seguinte:
-
Cria ativos de front-end
-
Implanta os ativos na hospedagem para consumo
-
Garante que os registros e caches sejam atualizados para que as novas versões possam ser entregues aos clientes
As etapas reais do pipeline variam dependendo da pilha de tecnologia e da abordagem de composição da página.
Para composição do lado do cliente, isso significa fazer upload de pacotes de aplicativos para buckets de hospedagem e liberá-los para consumo por meio de armazenamento em cache em uma CDN. Os aplicativos que usam o cache do navegador com os trabalhadores de serviços também devem implementar formas de atualizar os caches dos trabalhadores de serviços.
Para composição do lado do servidor, isso geralmente significa implantar a nova versão do componente do servidor e atualizar o registro do microfront-end para tornar a nova versão detectável. Você pode usar padrões de implantação azul/verde ou canário para lançar gradualmente novas versões.
