Introdução
Durante a Sprint 5, o foco principal do Grupo 2 foi a execução do deploy da aplicação mobile desenvolvida de forma colaborativa entre diversos grupos, cada um responsável por uma feature. O Grupo 2, responsável pela feature Estações, teve um papel importante na unificação e publicação do app em ambiente de produção.
A aplicação foi inicialmente dividida em cinco partes, com cada grupo mantendo sua própria estrutura de navegação e projeto em React Native utilizando o Expo Router.
O primeiro passo foi tentar rodar os cinco apps de maneira integrada por meio da Expo Shell. Para isso, foram realizadas as seguintes ações:
- Cinco instâncias EC2 foram criadas na AWS, cada uma representando um grupo;
- Cada instância hospedou o backend do respectivo grupo;
- Os frontends foram testados individualmente através da Shell;
- As portas das aplicações foram ajustadas para evitar conflitos.
Apesar dos ajustes, a integração falhou no ambiente da Expo Shell. Foi observado que o Expo Router não se comportava adequadamente ao tentar unificar múltiplos apps com rotas e navegadores distintos nesse contexto.
Solução Adotada: Monorepo
Diante do problema, duas alternativas foram consideradas: refatorar completamente o sistema de navegação de todos os apps ou adotar um monorepo e integrar tudo em um único aplicativo. A segunda opção foi escolhida por ser mais viável e por manter a coesão das rotas, além de evitar retrabalho em todas as features.
Com isso, todos os frontends foram unificados em um único repositório, organizado por features. Cada grupo adicionou sua funcionalidade respeitando a estrutura do Expo Router. Foram realizados ajustes na navegação para que todas as features coexistissem dentro de um único app, incluindo a refatoração dos caminhos de rota e a padronização dos componentes de navegação.
Backend Unificado na AWS
Enquanto os frontends foram integrados em um monorepo, os backends de todos os grupos permaneceram independentes, porém foram hospedados em uma única instância EC2 na AWS.
Cada backend foi configurado para rodar em uma porta diferente dentro da mesma instância, permitindo que o frontend se comunicasse com todos os serviços via HTTP, acessando os endpoints conforme a necessidade de cada feature. Essa configuração garantiu o funcionamento simultâneo de todos os serviços, sem conflitos de portas ou processos.
Conclusão
A adoção de um unico repositório foi essencial para transformar o projeto em uma aplicação única, funcional e coesa, integrando todas as features desenvolvidas pelos diferentes grupos. Essa estrutura permitiu que a navegação com Expo Router funcionasse corretamente, além de facilitar a padronização de rotas, componentes e contextos. O modelo modular adotado também contribuiu para uma integração mais fluida e um processo de deploy mais organizado e sustentável.
A centralização dos backends em uma única instância EC2 também se mostrou uma estratégia eficaz, permitindo o acesso estável e simultâneo a todos os serviços. Essa decisão reduziu custos e facilitou o gerenciamento da infraestrutura, embora tenha exigido atenção redobrada na configuração de portas e no controle dos serviços ativos. De forma geral, a solução implementada aproximou o projeto de um ambiente de produção real, com uma arquitetura robusta, escalável e eficiente.