Vamos conversar um pouco sobre o processo de release de um aplicativo e porque as companhias estão usando cada vez mais a prática de Release Train.
Tipicamente, as releases em um aplicativo são feitas quando uma feature termina de ser desenvolvida e testada. Nesse momento, ela está pronta para o lançamento, não é mesmo?
Mas, e quando temos vários times trabalhando simultaneamente em diversos produtos desse app, por exemplo, 20 squads ou mais? Como controlar e orquestrar esse lançamento sem perder a qualidade?
Quando se chega ao ponto em que o gerenciamento de uma release se torna complexo, adotar a prática de mobile Release Train pode ajudar a dar mais visibilidade, velocidade e confiança a todo o time nos lançamentos.
O que é Release Train?
O conceito de Release Train vem do SAFe (Scaled Agile Framework). Ele faz uma analogia com um trem que vai sair para viagem em uma hora específica, e somente os passageiros que chegarem a tempo vão embarcar na viagem.
Ou seja, se a feature ficou pronta e está testada, ela pode fazer parte desta release. Caso contrário, seu time pode esperar a próxima partida do trem.
Como funciona o Release Train?
Confira as características, funcionamento e benefícios desse conceito.
Definindo o timebox
Aplicar o Release Train traz várias vantagens. A primeira delas é que é definido um calendário para a release: a cada 1 ou 2 semanas, ou mesmo em 1 mês. O timebox é indiferente e vai depender das características e necessidades do projeto, embora exista uma tendência no mundo dos apps de termos releases cada vez mais frequentes.
Ter um calendário bem definido traz visibilidade para o time (equipe técnica, área de Produtos, Marketing etc.). Todos os envolvidos sabem exatamente quando será a próxima release; os times que não conseguiram pegar o trem sabem que a próxima viagem está a caminho.
Uma vez definido o timebox (1, 2, 4 semanas) de partida do trem, é necessário estabelecer qual será a data de corte, frequentemente chamado de Code Cut ou Code Freeze. A data de corte é o dia/hora limite para entregar o código pronto, testado e devidamente aprovado pelo time da squad.
Para exemplificar: no caso de uma release semanal, a data de corte pode ser toda segunda ou sexta-feira até o horário estipulado. Depois disso, nada mais entra na release.
Atuação das equipes
Antes da data de corte, todos os times podem trabalhar em suas features e seguir todo o processo do desenvolvimento. Geralmente, consiste em fazer um PR (Pull Request) para aprovação com Code Review pelos líderes técnicos, confirmar uma boa cobertura de testes unitários e disponibilizar um build para o time de QA da squad validar as funcionalidades da nova feature. Somente quando ela for aprovada pelo time da squad, pode ser candidata para pegar o próximo trem.
Terminada esta data de corte, a squad já está livre para trabalhar no desenvolvimento da próxima feature. Enquanto isso, em paralelo, são iniciados os testes de integração da feature e regressivos em todo o app para garantir a estabilidade da release.
Este time que já está atuando em uma próxima feature também pode atuar em eventuais bugs que por ventura sejam encontrados pelo time de qualidade nos testes regressivos.
Outro aspecto importante do Release Train é definir os tempos necessários para cada uma das fases de testes. Por exemplo, podem ser 2 dias de integração e 3 dias para testes regressivos. Tudo isso, porém, vai depender do tamanho do projeto e quantidade de QAs disponíveis.
É importante ressaltar que o time de QA precisa ser bem dimensionado, para que não se torne um gargalo, atrasando as entregas.
Pode ser que a equipe de QA focada nos testes regressivos não consiga dar vazão à quantidade de features que estão sendo disponibilizadas. Por esse motivo, algumas empresas adotam um limite para a quantidade de features que podem subir em uma release. Aqui, fazemos uma analogia com uma quantidade fixa de vagões do trem.
O momento da release
Quando chega o momento da release, temos pequenas alterações no processo que costumam variar conforme a realidade de cada empresa. Algumas por exemplo, fazem todos os testes apenas com o time interno. Outras disponibilizam uma versão beta dos apps nas lojas antes de enviar uma versão definitiva em produção. Muitas, ainda, podem se beneficiar de dogfooding, ou seja, usam o seu próprio produto.
Independentemente dos ambientes e do workflow de release, ao submeter os apps para as lojas do Google e Apple, são boas práticas fazer uma release gradual (Staged Rollout) e utilizar feature flags para controlar a disponibilidade das novas features. Ambas as técnicas são utilizadas para aumentar a confiança da release e ter um plano de contingência em caso de qualquer falha ser encontrada.
Release gradual
A release gradual é utilizada para liberar gradativamente a versão para os usuários, por exemplo, começando por 10% da base até chegar em 100%. A vantagem desta técnica, é que ao liberar gradualmente uma atualização para um pequeno grupo, é possível identificar e corrigir problemas antes que eles afetem a maioria dos usuários.
Feature flags
Já feature flags é uma técnica que permite ligar e desligar as features do app remotamente. Dentre muitas aplicações que valem um artigo separado, podem ser utilizadas para fazer o rollback de um possível problema na release. Justamente por isso, feature flags costuma passar mais confiança ao time no momento da release.
Quem organiza a release? Conheça o RTE
Para orquestrar toda a entrega, a prática do Release Train recomenda a criação de um papel chamado de Release Train Engineer (RTE). Trata-se da pessoa responsável por organizar todo o processo de release, trabalhando perto dos Product Owners/Managers, engenheiros e toda liderança. O objetivo é garantir que todos os processos fluam corretamente para realizar uma entrega de qualidade.
De fato, para apps grandes o RTE pode contar com toda uma equipe, que muitas vezes é chamada de time do Release Manager. Pode ser esse mesmo time ou pessoa a ser responsável por atualizar os artefatos das lojas como textos de release notes, imagens etc.
É de responsabilidade do RTE aprovar todas as features testadas para entrar na release, acionar os times responsáveis em caso de falhas no processo de testes integrados, e até decidir não aprovar uma feature devido a alguma falha que ainda não foi solucionada em tempo dos testes regressivos.
Em conjunto com todo o time de qualidade, o RTE é responsável por garantir a confiabilidade e a qualidade da entrega. Também por acionar todos os times para fazer os alinhamentos necessários, dando a devida clareza das próximas releases.
Pensamentos finais sobre o Release Train
O conceito de Release Train é simples, mas implementá-lo e mantê-lo vivo é um desafio. Por isso, é importante a atuação do RTE para tirar possíveis impedimentos e garantir que todo o processo esteja fluindo corretamente.
No início do artigo, foi feita uma breve citação ao modelo tradicional de release que consiste em apenas publicar os apps quando tivermos uma feature concluída ou uma atualização importante. Essa abordagem não é errada; o que foi mostrado aqui é uma diferente visão. O tipo de abordagem depende muito do contexto e momento do projeto, e pode ser que funcione para o seu app.
Se refletirmos sobre os principais aplicativos que temos instalados em nossos celulares, veremos que todos estão indo para um caminho de releases mais curtas, levando valor constante aos seus usuários. É uma mudança de mindset: para releases constantes em vez de poucas releases carregadas de novidades.
Essa técnica permite os times experimentarem rapidamente, utilizar testes A/B e coletar dados para validar o que está agradando os usuários. Ela foi primeiramente apresentada pelo time do Dropbox na palestra Fast Data Driven Growth on Native Mobile. O conceito é sair de releases longas, suscetíveis a falhas, para releases curtas, e migrar para uma cultura de experimentação e um processo ágil.
Alguns lembretes e lições aprendidas:
- Defina o período para cada release. Começando por algo que é factível para o seu time, e vá diminuindo o tempo à medida em que forem ganhando maturidade no processo. Cada caso é um caso; encontre um timebox que faça sentido para sua empresa.
- Divulgue o calendário dentro da empresa. Isso ajuda todas as áreas de Produtos e o Marketing a estarem alinhados com o lançamento.
- Defina o tempo para cada fase: desenvolvimento, data/hora de corte, tempo de testes integrados e regressivos e, por fim, o tempo da release gradual nas lojas.
- Defina os critérios para entrar no trem e os siga à risca. Por exemplo, não permita que features não testadas tentem entrar no trem em cima da hora.
- Sempre mantenha o processo funcionando. O trem precisa partir mesmo que só existam pequenas melhorias.
- Automatize tudo o que puder. Ter uma pipeline CI/CD integrada é fundamental para gerar releases rapidamente, seja para o time de qualidade da squad testar uma feature, ou para gerar o build final do app. A pipeline também ajuda a evitar erros causados por processos manuais.
- Utilize testes automatizados e2e (end-to-end) para desafogar o time de QA. Além de acelerar o processo dos testes regressivos, vai aumentar a confiabilidade e qualidade da entrega.
Como a BRQ pode ajudar?
A BRQ Digital Solutions acelera a Transformação Digital do seu negócio atuando de ponta a ponta, desde o processo consultivo até a implementação da aplicação.
Criamos as mais diversas soluções mobile personalizadas para os seus desafios, por meio de inovação contínua com nossos times de engenharia, design e marketing. Contamos ainda com um pool de parceiros excepcionais, os maiores provedores de tecnologia do mercado.
Unimos tecnologia, design e negócios, focados nas necessidades do consumidor final e conectados aos objetivos dos nossos clientes, com alto nível de qualidade e governança.
Seu negócio tem um desafio? Venha conversar conosco!
Ricardo Lecheta, especialista em mobile e Chief Technology Officer na BRQ.
