Olá! Meu nome é Mikhail Bulgakov (não, não sou parente), trabalho como engenheiro de lançamento no Badoo. Há cinco anos, comecei a automatizar o lançamento de aplicativos iOS, que abordamos em detalhes neste artigo . E então ele pegou aplicativos Android.
Hoje vou resumir alguns resultados: contarei a que chegamos durante esse período. Para encurtar a história: qualquer funcionário envolvido no processo pode liberar pelo menos todos os nossos aplicativos nas duas plataformas em apenas alguns cliques - sem dores de cabeça, demorado, registro e SMS. Assim, nosso departamento de engenheiros de lançamento em 2019 economizou cerca de 830 horas.
Para detalhes - bem-vindo sob o corte!
O que há por trás do lançamento móvel
Uma versão do aplicativo no Badoo tem três fases:
- Desenvolvimento.
- : , — , App Store Google Play.
- , -.
Quando o aplicativo estiver completamente pronto e o primeiro estágio estiver concluído, é importante não consertá-lo no estágio de liberação e levar o produto ao “balcão”. Esse último estágio parece ser o mais fácil, mas na verdade leva muito tempo e seu sucesso depende de poucas pessoas.
A maior parte do tempo é gasta na preparação da vitrine do aplicativo na App Store ou no Google Play: você precisa fazer upload de capturas de tela bonitas, fazer uma descrição atraente, otimizada para uma melhor indexação, escolher palavras-chave para pesquisa. A popularidade do aplicativo depende diretamente da qualidade desse trabalho, que é, de fato, o resultado das atividades de desenvolvedores, testadores, designers, gerentes de produto, profissionais de marketing - todos envolvidos na criação do produto.
Se o aplicativo precisar existir em vários idiomas, é necessário pelo menos uma pessoa separada para preparar a vitrine ou até vários funcionários: um gerente de produto que escreverá textos para a descrição, organizará a tradução em todos os idiomas e preparará um ToR para a criação de capturas de tela, um designer que desenhará capturas de tela com texto sobreposto, contornos do dispositivo etc. e, é claro, tradutores que traduzem todas as capturas de tela e textos para diferentes idiomas.
A parte final do trabalho é o próprio processo de liberação. Leva uma quantidade significativa de tempo de uma pequena equipe de engenharia de lançamento. Nesse estágio crucial, mas de rotina, procuramos minimizar o número de erros e a influência do fator humano. Para fazer isso, antes de tudo, era necessário automatizar o carregamento de metadados (design de texto e gráfico da vitrine do aplicativo): isso permite reduzir significativamente os custos de tempo e implementar rapidamente lançamentos de negócios (por exemplo, estilizando o aplicativo para o Dia dos Namorados).
Como a decisão sobre a prontidão do aplicativo para lançamento no Badoo é tomada pela equipe de engenheiros de controle de qualidade, decidimos dar a eles o direito de pressionar o "botão vermelho" do lançamento do lançamento. Ao mesmo tempo, queríamos que fosse acessível mesmo a partir de dispositivos móveis (com uma exibição visual do andamento do script).
Primeiros passos em direção à automação: carregando metadados
Como funcionou desde o início: para cada versão, foi criada uma tabela no Google Sheets, na qual o gerente de produto preenchia o texto mestre verificado em inglês, após o qual os tradutores a adaptavam para um país, dialeto e público específicos e, em seguida, o engenheiro de liberação transferia todas as informações desta tabela na App Store ou no Google Play.
O primeiro passo que damos para a automação foi integrar a tradução de textos em nosso processo geral de tradução. Não vou me debruçar sobre isso - este é um sistema grande e separado, sobre o qual você pode ler em nosso recente artigo. O ponto principal é que os tradutores não perdem tempo com tablets e trabalham com a interface para carregamento conveniente manualmente (leia-se: ctrl + c ctrl + v) das opções traduzidas na página. Além disso, existem os ingredientes do versionamento e a base da infraestrutura como código.
Ao mesmo tempo, adicionamos o descarregamento de traduções prontas do banco de dados e as incorporamos no arquivo IPA coletado (extensão de arquivo do aplicativo iOS). Criamos o aplicativo no TeamCity. Assim, cada versão do aplicativo sempre teve uma nova tradução sem intervenção manual no processo de montagem.
Por algum tempo, vivemos assim e, em geral, tudo nos convinha. Mas o número de aplicativos aumentou e, com ele, o tempo para preparar cada versão.
Nossa realidade a partir de 2015
Em média, o lançamento de um aplicativo na presença da versão atual das capturas de tela levou cerca de uma hora e meia a duas horas de trabalho pelo engenheiro de lançamento no caso do iOS e cerca de meia hora no caso do Android. A diferença se deve ao fato de que os aplicativos iOS precisam passar pelo chamado Processamento, que leva algum tempo (é impossível enviar o aplicativo para Revisão até que o Processamento seja concluído com êxito). Além disso, a própria App Store, pela maioria das operações da época, era muito mais lenta que o Google Play.
Tornou-se óbvio que precisávamos de uma ferramenta adicional para entregar aplicativos às lojas. E justamente naquele momento, um produto chamado Fastlane começou a ganhar popularidade no mercado de código aberto. Apesar de ainda estar úmido na época, ele já podia resolver uma enorme camada de nossos problemas ...
Vou dizer algumas palavras sobre ele para deixar mais claro o que será discutido mais adiante.
Fastlane em resumo
Hoje, o Fastlane é um produto capaz de automatizar quase completamente todas as ações desde o momento do desenvolvimento até o lançamento do aplicativo na App Store e no Google Play. E não se trata apenas de baixar textos, capturas de tela e o próprio aplicativo - aqui estão gerenciamento de certificados, testes beta, assinatura de código e muito mais.
Conhecemos Fastlane durante sua "juventude" e instabilidade. Agora, porém, é um componente integral e de trabalho confiante de muitas equipes de desenvolvimento de aplicativos móveis que enfrentam o enorme problema demorado de entregar seus produtos aos usuários. O mais interessante é a capacidade de escrever seus próprios plug-ins para o componente principal e usar plug-ins escritos pela comunidade. Para um produto tão específico, essa é uma boa solução, que (o que é importante) ajuda a não produzir tecnologias "extras" no DevTools.
A confiança também é inspirada no fato de o fundador e desenvolvedor chefe do Fastlane ter sido contratado pelo Google: agora o componente suporta não apenas a comunidade, mas também Sam.
Com o tempo, implementamos a maioria dos recursos do Fastlane nos sistemas de compilação, assinatura, preenchimento e mais de nossos aplicativos. E eles estão incrivelmente felizes com isso. Por que reinventar a roda e até manter sua forma correta, quando você pode escrever um script unificado uma vez, que girará no próprio sistema de CI / CD?
Automatize versões do iOS
Devido ao fato de o Google Play ser mais amigável com os desenvolvedores, demorou muito pouco tempo para lançar um aplicativo Android: alguns minutos sem atualizar textos, vídeos e capturas de tela. Portanto, não há necessidade de automação. Mas com a App Store, o problema era muito tangível: demorou muito tempo para enviar os pedidos para a Review. Portanto, foi decidido iniciar a automação com o iOS.
Pensamos na semelhança de nosso sistema para automatizar a interação com a App Store (e até criamos protótipos), mas não tínhamos os recursos para concluir e atualizar. Também não havia API mais ou menos adequada da Apple. Bem, o último prego no caixão de nossa solução personalizada foi impulsionado por atualizações regulares na App Store e seus mecanismos. Por isso, decidimos experimentar o Fastlane - ainda a versão de 2015.
O primeiro passo foi escrever um mecanismo para descarregar textos traduzidos para aplicativos na estrutura desejada como um componente do nosso sistema interno comum AIDA (Assistente de Implantação Interativa Automatizada). Este sistema é um tipo de hub, um link entre todos os sistemas, tecnologias e componentes usados no Badoo. Ele funciona em um sistema de filas auto-escrito implementado no Golang e MySQL. Principalmente, o departamento de Engenharia de Liberação mantém e aprimora. Falamos sobre isso com mais detalhes em um artigo de 2013, desde então muita coisa mudou. Prometemos falar sobre isso novamente - AIDA é incrível!
Na próxima etapa, os textos enviados foram alimentados no Fastlane, que os enviou para a App Store. Depois disso, você tinha que acessar a interface da App Store, selecionar manualmente a versão baixada desejada e enviar o aplicativo para verificação, se o Processamento já tivesse sido concluído naquele momento.
Isso reduziu o tempo de preparação do lançamento de duas horas para cerca de 30 minutos, dos quais apenas um minuto e meio tiveram que fazer algo com as mãos! O resto do tempo é esperar. Aguarde o final do processamento. O mecanismo foi um avanço naquela época, precisamente porque nos salvou quase completamente do trabalho manual ao preparar a AppStore para lançamento. Criamos um repositório para o script, ao qual demos acesso a pessoas diretamente relacionadas a lançamentos (gerentes de projeto, engenheiros de lançamento).
Vivemos nesse modo por algum tempo. Mas, em algum momento, esse esquema levou ao acúmulo de muitos "conhecimentos sagrados", cujo proprietário e, como resultado, a imagem geral dos eventos, se tornaram uma única pessoa, e isso não é bom. Especialmente para essa pessoa: você não pode nem sair de férias sem um laptop.
Além disso, havia muitos componentes de infraestrutura espalhados em torno desse mecanismo, praticamente sem relação entre si.
- Você tinha que ir para o TeamCity para uma nova versão, baixar o arquivo IPA de lá, enviá-lo para a App Store através do Application Manager.
- Em seguida, vá para a interface com traduções no AIDA, veja se todas as traduções estão prontas, execute o script, verifique se funcionou corretamente (afinal, naquela época o Fastlane ainda estava úmido).
- App Store , Processing.
- Review.
E assim com cada aplicativo. Deixe-me lembrá-lo que naquela época tínhamos oito.
O próximo passo foi transferir o script para o nosso AIDA, combinando e automatizando todas as etapas até o envio do aplicativo: verificação da prontidão das traduções, coleta de dados do TeamCity, notificação, registro e todos os outros benefícios do século XXI. Paralelamente, começamos a carregar todas as versões montadas no TestFlight no estágio de construção.
O TestFlight é um aplicativo de terceiros, uma vez adquirido pela Apple para testar o aplicativo finalizado por testadores externos em um ambiente praticamente de produção, ou seja, com notificações por push e tudo mais.
AIDA bem feito, seja como AIDA!
Tudo isso levou a uma redução no tempo de meia hora para um minuto e meio para tudo: tudo: o arquivo IPA conseguiu passar pelo processamento antes do momento em que a equipe de engenheiros de controle de qualidade aprovou o lançamento do lançamento. No entanto, ainda tínhamos que ir à App Store, selecionar a versão que desejamos e enviá-la para Revisão.
Além disso, foi desenhada uma interface simples: todos gostamos de clicar e clicar.
Assim, tab por tab, Ctrl + C Ctrl + V ...
Automação de versão do Android
Em seguida, surgiu a questão sobre a automação de lançamentos de aplicativos Android. Embora esse processo tenha sido muito mais rápido, era necessário fazer bastante manualmente:
- Acesse o console do Google Play para garantir que a versão anterior seja lançada para 100% dos usuários ou congelada.
- Crie uma nova versão do release com textos e capturas de tela atualizados (se houver).
- Carregar arquivo APK (Pacote Android), carregar arquivo Mapeamento.
- Acesse o HockeyApp (usado para registrar falhas no momento), faça o upload do arquivo APK e do arquivo de mapeamento lá.
- Vá para o bate-papo e cancele a inscrição sobre o status do lançamento.
E assim com todas as aplicações.
Sim, o Google Play tem sua própria API. Mas por que criar um invólucro, monitorar alterações no protocolo, mantê-lo e gerar entidades desnecessariamente se já estamos usando as versões do Fastlane para iOS? Além disso, ele existe confortavelmente em nosso servidor, é fabricado em seu próprio suco e geralmente é atualizado. E nessa época, ele também havia aprendido a liberar adequadamente aplicativos Android. As estrelas se uniram!
Primeiro, cortamos tudo o que era antigo de todos os lugares: scripts individuais, esboços de automação, invólucros antigos para a API - isso foi criado uma vez como um experimento e não tinha um valor particular. Imediatamente depois disso, adicionamos uma equipe ao AIDA, que já sabia como capturar o que era necessário no TeamCity, fazer upload do necessário no HockeyApp, enviar notificações, atividades de log e, em geral, ela era membro da equipe.
A Fastlane foi responsável pelo upload de arquivos APK e Mapeamento para o Google Play. Devo dizer que é muito mais fácil seguir o caminho batido: foi implementado com rapidez suficiente, com um mínimo de esforço.
Em um certo estágio da implementação da automação, houve uma transição dos arquivos APK para o AAB (Android App Bundle). Mais uma vez, tivemos a sorte de ter conseguido consertar tudo rapidamente, mas "entretenimento" foi adicionado em conexão com essa transição. Por exemplo, ele estragou o HockeyApp, que não sabia como usar os arquivos da AAB em conexão com a preparação para a serra automática. Portanto, para continuar a usá-lo confortavelmente, após a montagem do AAB, era necessário desmontar o arquivo montado, obter o arquivo de Mapeamento de lá, que voará para o HockeyApp, e do AAB era necessário coletar o arquivo APK separadamente e depois enviá-lo para o mesmo HockeyApp. Parece divertido. Ao mesmo tempo, o próprio Google Play decompõe perfeitamente o AAB, retira o arquivo de mapeamento e o insere quando necessário. Então, nos livramos de um passo e adicionamos alguns, mas não havia como evitar isso.
Uma interface foi gravada (novamente, por analogia com o iOS), capaz de baixar uma nova versão, verificar a versão ao longo e transversalmente, gerenciar a versão ativa atual (por exemplo, aumentar a porcentagem de distribuição). Nesse formulário, demos aos membros da equipe de controle de qualidade da equipe de controle de qualidade do Android, começamos a coletar feedback, corrigir bugs, concluir a lógica (e o que mais acontece após o lançamento 1.0?).
A propósito, no futuro, a automação nos deu a oportunidade de fazer upload de versões beta de aplicativos para o Google Play automaticamente em uma programação, o que, por sua vez, acelerou bastante o processo de testes automáticos e de regressão.
Unificação do fluxo de lançamentos móveis
Quando as versões do Android foram automatizadas, a Fastlane finalmente aprendeu como enviar versões dos aplicativos iOS para revisão. E melhoramos um pouco o sistema de verificação de versão no AIDA.
Chegou a hora de lançar versões do iOS à mercê de uma equipe de engenheiros de controle de qualidade. Para fazer isso, decidimos desenhar um formulário bonito que cubrasse totalmente as necessidades surgidas durante o lançamento dos aplicativos iOS: permitiria selecionar a compilação desejada no TeamCity de acordo com parâmetros predefinidos, selecionar a opção de textos carregados, atualizar ou não campos opcionais (por exemplo, Texto promocional) ...
Não antes de dizer que acabou. O cortador de biscoitos acabou por ser muito bonito e satisfaz plenamente todos os pedidos. Além disso, com sua implementação, tornou-se possível selecionar todas as aplicações necessárias de uma só vez com todos os parâmetros necessários, para minimizar a interação com a interface. O comando AIDA on envia um link para o log de compilação, pelo qual você pode rastrear os erros que ocorrem, garantir que tudo correu bem, obter algum tipo de informação de depuração, como a versão do arquivo IPA baixado, a versão de lançamento, etc. É assim que são lindas as versões do iOS. e foram transferidos para a equipe de controle de qualidade do iOS.
Bem, é fofo?
Gostamos tanto da ideia do molde que decidimos fazer o mesmo nos lançamentos do Android. Considerando que temos um aplicativo totalmente escrito em React Native e que a equipe de controle de qualidade desse aplicativo é responsável pelas versões para iOS e Android.
A interface já usada pela equipe de controle de qualidade do Android foi integrada às mudanças de forma semelhante, o processo foi adaptado a novas realidades - tudo era o mais próximo possível dos processos da equipe do iOS. Isso incentivou finalmente esboçar uma versão mais ou menos final da documentação para ambas as plataformas (no processo de constantes mudanças, nós categoricamente não queríamos fazer isso) e também desacoplar o processo de liberação de todas as restrições artificiais que se desenvolveram historicamente e levaram a gestos desnecessários em situações fora do padrão, exigindo equipe de ação de engenheiros de lançamento.
Resultado
De uma maneira divertida por cerca de cinco anos (desde o momento em que começamos a desenvolver o negócio móvel até os dias de hoje), automatizamos completamente os processos de montagem, teste e liberação, os tornamos o mais eficientes possível e transferimos a responsabilidade pelas liberações para os membros da equipe de controle de qualidade que aceitam decisão sobre o grau de prontidão do aplicativo.
Além das vantagens óbvias, nos livramos completamente de scripts dispersos, todo tipo de "conhecimento secreto" vinculado a uma única pessoa, integramos um novo componente ao nosso ecossistema, que é suportado por uma pequena equipe de engenheiros de lançamento.
É ótimo que agora haja uma oportunidade de automatizar a maioria das ações rotineiras, que os engenheiros possam escrever código sempre que quiserem, e desenvolvedores terceirizados possam dar suporte a qualquer código sem perder tempo precioso procurando interfaces complexas. É especialmente difícil descobrir coisas como "Onde devo marcar?". Quando o relógio é meia-noite, ninguém está no escritório, e o hotfix precisa ser carregado aqui e agora.
Cinco anos. Por que tão demorado? Primeiro, os lançamentos para dispositivos móveis estão longe de ser a única área de responsabilidade de nossa pequena equipe. Em segundo lugar, é claro, levou tempo para desenvolver o novo projeto de código aberto Fastlane; nosso sistema de lançamento evoluiu com ele.
Percorremos um longo caminho nesta área. Talvez não seja o mais eficaz, talvez algum rake possa ser previsto e contornado. Mas era como era. Quando começamos, não havia artigos semelhantes - nós mesmos subimos. E se você estiver enfrentando uma tarefa semelhante agora e este artigo o ajudar com algo, ficarei incrivelmente feliz. Mas mesmo se você não aprendeu informações fundamentalmente novas, espero que pelo menos tenha sido interessante ler à vontade. E, talvez, compare com sua experiência. E se você tem algo a dizer sobre este assunto, bem-vindo ao comentar!