StartSe - Modernizar a base de um app que não pode parar
Evolução e migração técnica do aplicativo de eventos da StartSe, já publicado e em uso, sem interromper o calendário de conferências.
Um app que já estava no ar, e precisava continuar
Quando a X-Apps entrou no projeto, em 2019, o aplicativo da StartSe já existia, já estava publicado nas duas lojas e já era usado pelos participantes das conferências da empresa. Não era um projeto para começar do zero, e essa era exatamente a dificuldade.
O aplicativo estava em React Native 0.55, uma versão que não subia sozinha. A análise técnica foi direta: atualizar até a 0.60 significava refazer a estrutura do projeto, e não aplicar um comando de atualização.
Ao mesmo tempo, o calendário da StartSe não esperava. Havia dez eventos mapeados como marcos no cronograma, com data fixa, cada um deles precisando do aplicativo funcionando no dia.
O desafio
- Modernizar a base técnica de um aplicativo em produção, sem quebrar quem já o tinha instalado. Conviver com o time técnico do próprio cliente, que trabalhava no mesmo repositório ao mesmo tempo. Desenvolver contra APIs que estavam sendo construídas em paralelo e às vezes respondiam erro ou vinham incompletas. * Caber num contrato de banco de horas com uma liberação de versão por mês, contra um calendário de eventos que não era mensal.
A nota nas lojas, antes e depois
O ponto de partida está registrado: em fevereiro de 2019, no começo do trabalho, o aplicativo tinha 3,5 no iOS e 2,4 no Android.
Hoje o mesmo aplicativo, publicado como StartSe: Conhecimento do Agora, está em 4,8 na App Store brasileira, com milhares de avaliações e versões novas saindo com regularidade.
Vale a honestidade sobre o que esse número significa. São sete anos entre uma coisa e outra, e o produto seguiu com o time da própria StartSe, que é quem o mantém desde então. O que a X-Apps fez foi a parte de baixo: deixar a base em uma versão sustentável, com navegação, build e estilos em ordem, para que essa continuidade fosse possível.
Aplicativo que trava em uma versão antiga de framework não recebe funcionalidade nova, recebe remendo. Sair da 0.55 foi o que destravou os anos seguintes.
A migração, feita como projeto e não como comando
A passagem do React Native 0.55 para o 0.60 foi tratada como o que era: uma reconstrução da estrutura, com migração de componentes e assets para um projeto novo.
Ela arrastou junto um conjunto de mudanças que não eram opcionais:
- Troca do esquema de navegação. O react-native-navigation não era compatível com o destino, e a aplicação inteira passou para o react-navigation. Correção dos dois builds. Todas as dependências nativas precisaram ser religadas, com os erros de execução corrigidos no iOS e no Android, e um leia-me explicando como montar cada ambiente. Compatibilidade com o iOS 13, que chegou no meio do caminho, e correção da tipografia customizada no Android. Refatoração dos estilos. Um arquivo de constantes reaproveitado pela aplicação e os estilos separados em folhas, componente por componente. Eliminação dos erros de ESLint acumulados no projeto.
Antes disso havia um problema mais urgente: quem tinha a versão da loja instalada e atualizava por fora tinha travamento na abertura. Corrigir esse caminho foi condição para atualizar a base inteira com segurança.
O que foi construído pelo caminho
Enquanto a base era arrumada, o aplicativo continuou ganhando funcionalidade para os eventos.
Networking entre participantes. Quem opta por participar aparece para os outros inscritos, pode solicitar contato e conversar, com notificação por push avisando o outro lado. Tudo por opt-in.
Perfil do participante. Bio, interesses, foto e dados, com o participante escolhendo se libera LinkedIn e WhatsApp.
Programação por trilhas. A área de programação foi redesenhada em trilhas, com blocos e subblocos e a possibilidade de favoritar palestras.
Conteúdos e notícias. Listagem com paginação e leitura dentro do próprio aplicativo.
Push que leva a algum lugar. As notificações passaram a ser interceptadas mesmo com o aplicativo fechado e roteadas por deep link para a ação certa.
Identidade visual. Ícones convertidos para fonte de ícones e a tipografia da marca aplicada no aplicativo inteiro, incluindo o acerto do carregamento no Android.
Stack e práticas
- React Native, da versão 0.55 para a 0.60, com react-navigation e Redux. OneSignal para notificação push, com deep link para roteamento. Câmera e recorte de imagem nativos para a foto de perfil, com o conflito de versões de SDK e Gradle resolvido para o Android voltar a compilar. Login por e-mail, Facebook e LinkedIn. API REST do cliente com autenticação por token. Builds de homologação distribuídas a cada ciclo, com QA de cadastro e login nos três provedores antes de liberar. Backlog priorizado pelo cliente, com formulário próprio para ele registrar tarefas e defeitos.
Trabalhar dentro do time do cliente
A StartSe tinha desenvolvedores próprios no mesmo repositório. Isso muda o modo de trabalhar: foi preciso combinar áreas de atuação para reduzir conflito, e houve implementação pronta que voltou atrás por sobreposição.
A X-Apps também apoiou o outro lado. Quando o ambiente do time do cliente não rodava o projeto, entrou uma call para configurar Android e iOS, e a documentação de ambiente ficou escrita no repositório.
Tem um aplicativo preso em uma versão antiga?
Aplicativo em produção que não sobe de versão vira dívida composta: cada mês sem migrar encarece a migração seguinte e fecha portas de funcionalidade. Dá para fazer essa passagem sem tirar o produto do ar, e com o time do cliente junto.