Flutter: automatizando o projeto com entrega contínua (CD)

Entrega contínua (CD) no Flutter - Apresentação

Olá! Boas-vindas a mais um curso.

Sou William Bezerra, seu instrutor ao longo dessa jornada.

Audiodescrição: William se declara como um homem pardo de olhos castanhos. Usa um óculos de armação preta redonda. Tem uma barba média e um cabelo curto, ambos castanhos escuros. Está usando uma camisa branca e está sentado em uma cadeira de encosto alto e preto. Ao fundo, uma parede iluminada com luz LED azul.

Ao longo de todo esse processo, estaremos aplicando e estruturando alguns processos de Continuous Delivery (CD), que é a famosa Entrega Contínua. Para estruturar essa entrega contínua, utilizaremos o aplicativo "Sorteador de Amigos Secretos".

Nesse aplicativo, estruturamos para garantir que as pessoas consigam realizar aquele amigo secreto de final de ano. Tudo ficará muito estruturado, então todo mundo ficará feliz. Dentro do nosso curso, trouxemos essa plataforma para algo mais estrutural e específico, que você revisará e achará bem interessante.

Além de utilizar esse projeto, todas as implementações de estruturação serão feitas com Codemagic. No curso "Flutter: aplicando integração contínua (CI)", que é um pré-requisito para esse curso, nós estruturamos e aplicamos todos os processos (workflow) de CI. Recomendamos então que acesse o curso de aplicação de CI em Flutter antes de continuar.

O projeto

Nesse curso, daremos sequência à estruturação em CI, implementando todo esse processo. Ao final do curso, você terá implementado os workflows de desenvolvimento, de homologação e de produção. Cada etapa desse workflow é uma forma de garantir que tanto que haverá os testes, quanto que a pessoa responsável por cada etapa dessa receberá o aplicativo para fazer o teste.

Então o seu aplicativo estará sendo bem escrito e bem testado, resultando em um app satisfatório. E, além de receber esse aplicativo, você também entenderá como consegue configurar e assinar sua build, para garantir que o aplicativo que será gerado consiga subir diretamente na loja.

É muito importante adquirir conhecimentos de CI, do curso anterior, e de CD, desse curso, porque, no mercado atual, é algo essencial para qualquer pessoa desenvolvedora Flutter. Hoje quase não existe empresas que não atuam com esse processo de automatização, tanto do processo CI, quanto do processo de CD.

Portanto, é muito importante para você aprender e conseguir replicar isso dentro das suas empresas. E se você está sentindo bastante animação para começar esse curso, aproveite para compartilhe nas redes sociais e marcar a Alura.

Caso você queira também participar de uma comunidade, interagindo com outras pessoas, tirando dúvidas e trocando ideias, acesse o Discord da Alura.

Vejo você na próxima aula!

Entrega contínua (CD) no Flutter - Entrega contínua (CD) no Flutter

Vamos pegar o mesmo projeto que utilizamos no curso de Integração Contínua (CI), que é o sorteador de amigos secretos. No entanto, vamos elevar esse projeto para outro nível, trazendo um contexto um pouco mais real.

Entendendo o uso de entrega contínua

Imagine que uma grande rede varejista decide implementar uma nova política de marketing, totalmente diferente do mercado. Ela decide criar um sorteador de amigos secretos, onde seus clientes vão se sortear entre eles mesmos, fazendo uma campanha de marketing com os próprios prêmios.

Nesse cenário, o nosso time é alocado para desenvolver o aplicativo que será utilizado nessa campanha. Teremos aproximadamente 30 pessoas trabalhando nesse projeto e deixando tudo muito bem estruturado.

Todos os dias o time trabalha muito bem e o aplicativo já está lançado. As pessoas seguem fazendo o teste e montando conforme o Figma. Tudo está indo muito bem. No entanto, temos um problema. O tech lead do nosso projeto, que é a única pessoa que tem acesso para publicar os aplicativos, decide sair de férias por uma semana. Ele anunciou que, durante esse período, não haveria publicações.

No dia que ele saiu de férias, nosso time gerou uma nova versão e subiu essa versão para a loja. Testamos e verificamos tudo, mas, mesmo assim, passou um bug crucial para a operação. Nós corrigimos o bug, mas na hora de subir, lembramos que não conseguiríamos subir para a loja, porque era só o nosso tech lead que tinha acesso para fazer o upload.

Com isso, pensamos: "Se tivermos as credenciais de acesso, conseguimos resolver e está tudo bem". No entanto, isso não resolveria o problema, porque se temos 30 pessoas trabalhando no nosso time, se as pessoas que fazem o upload saem de férias, como que funcionaria esse processo? Seria um grande problema.

Porém, não podemos passar acesso para 30 pessoas. Ainda que nenhuma delas seja mal-intencionada, pode ser que alguém suba algo na loja que comprometa a operação. Precisamos ter um controle por meio de um processo melhor estruturado.

Essa questão de segurança e privacidade é resolvido com um processo de Entrega Contínua (CD), que é justamente o processo que vai estruturar toda a nossa empresa, como fizemos no CI, de rodar os testes automaticamente, de seguir a linha de entrega, que já estar dentro do nosso processo. Criaremos gatilhos e estruturações para garantir que, ao passar por um processo de qualidade definido pelo time de devs, podemos subir esse aplicativo de modo automático para a loja.

Uma vez que a avaliação de qualidade foi concluída e está tudo estruturado, podemos subir o app, porque ele está estável. Para isso que usamos o CD (Continuous Delivery ou Entrega Contínua). Muitas pessoas vão chamar esse processo apenas de CD, principalmente associado com o termo "CI". Uma vez que tivermos um fluxo de CI estruturado, resolvemos todo esse problema.

Aprendendo a estruturar um fluxo de CD

Por onde vamos começar? Precisamos estruturar o fluxo de CD, mas precisamos ter um nível de qualidade. O processo de CI é o processo anterior, porque se não temos um processo de CI, de nada adianta ter um processo de CD. Se vamos subir tudo automaticamente, precisamos de uma medida de qualidade.

A ideia é, juntamente com o processo de CI, implementar o processo de CD. Tanto que as pessoas chamam muito de fluxo de CI/CD. Portanto, para fazermos o processo de CD, primeiro precisamos ter configurado o processo de CI. Por isso, como um pré-requisito para esse curso, é muito importante que você tenha feito o curso de fluxo de CI.

Observação: Antes de continuar, você precisa fazer o curso "Flutter: aplicando integração contínua (CI)".

Uma vez que você configurou e seguiu todas as etapas do curso, vamos considerar que você já está com o CodeMagic estruturado e seus fluxos de CI estão prontos. Sendo assim, seguiremos o curso de CD a partir desse ponto.

A primeira etapa para configurar um fluxo de CD dentro do Flutter, é entender qual é a versão que estamos rodando o nosso aplicativo, seja de versão do Flutter, do Android ou do iOS. Para descobrir, acessaremos o projeto no VS Code.

Abriremos o Terminal do VS Code, na metade inferior da janela. Com o terminal aberto, digitaremos o comando flutter doctor. Esse comando vai rodar o script dentro do nosso projeto e retornará os dados que utilizamos. Por exemplo, estou utilizando a versão do Flutter Channel Stable, 3.19.0.

Mesmo que a versão do Flutter que você estiver usando seja diferente, não tem problema, mas é importante saber qual é a versão desse projeto para configurá-la no CodeMagic. Com o flutter doctor, também descobrimos as versões de outras informações que precisaremos, como o Android Studio e o VS Code, portanto deixarmos essa informação guardadas.

Caso você esteja no iOS e queira configurar a build, precisamos rodar os seguintes comandos no Terminal:

• pod --version para descobrir a versão do Pod;
• xcodebuild --version para descobrir a versão do Xcode.

Com essas versões já temos o que é necessário para conseguirmos configurar o processo de CD dentro do nosso projeto.

Entrega contínua (CD) no Flutter - Configurando o seu primeiro fluxo de CD

Com as informações já definidas e compreendendo como funciona o fluxo de entrega contínua, vamos iniciar a configuração desse fluxo dentro do CodeMagic. Basicamente, o que faremos agora é abrir o link do CodeMagic dentro do nosso projeto.

Assim como fizemos no CI, você vai abrir a configuração. Dentro do CodeMagic, já temos os workflows que configuramos no curso passado.

Temos tanto o workflow de CI, de Dev-CI, quanto o workflow de HOMOLOG-CI, que são workflows que configuramos justamente para executar os testes em Dev, executar os testes em HOMOLOG, garantindo que temos uma regra de qualidade antes de chegar em produção.

Configurando o CD

Agora, estamos prestes a começar uma nova configuração, especificamente uma configuração de Continuous Deployment (CD). Em teoria, os fluxos de Continuous Integration (CI) e CD estão interligados. Temos pipelines para CI e CD, fluxos para CI e CD, entre outros elementos.

No entanto, neste caso, concentraremos nossa configuração apenas no CD, criando um fluxo de trabalho separado para ele. Mais adiante, ao longo do curso, faremos a conexão entre CI e CD para que você compreenda melhor seu funcionamento e como um fluxo de CI e CD mais estruturado seria implementado.

Para começarmos, escolhemos o Dev-CI e duplicamos esse workflow selecionando "duplicate workflow" do lado direito. Uma vez duplicado, ele vem com o nome do que copiamos com o copy no final: "DEV-CI-WORKFLOW (COPY)".

Ajustamos o nome clicando nele e digitando CD-WORKFLOW. Salvamos teclando "Enter". E então, já vamos iniciar a configuração.

De início, vamos definir quais as plataformas que faremos a build na seção "Build for platforms". Como não estamos fazendo a build para nenhuma plataforma, ela está marcada aqui na opção "Run Tests Only". No nosso caso, vamos fazer a build tanto para Android quanto para iOS. Selecionamos essas apenas "Android" e desmarcamos "Run Tests Only".

Para iOS, não vamos fazer nesse início, faremos apenas para Android. Caso você opte por fazer para iOS, o fluxo é o mesmo. Como estamos utilizando agora, neste momento, uma versão que estamos buildando apenas para Android, definimos Android, mas, à frente, no curso, faremos para iOS.

Na sequência, descemos dentro do CodeMagic. Abrimos a aba de "Build". E aqui que entram os pontos, as versões que coletamos. Por exemplo, coletamos que o projeto, ele está rodando a versão estável do Flutter (channel Stable). Então, no campo "Flutter Version" podemos selecionar qual a versão que estamos utilizando.

Como é a versão estável, ela já está pré-selecionada. Mas caso você esteja utilizando, por exemplo, a versão 1.18. alguma coisa, você consegue escolher neste campo e utilizar, não tem problema nenhum. No nosso caso, vamos deixar no estável. Caso você tenha marcado para iOS, você consegue definir qual a versão do iOS, tanto do Xcode quanto do CocoaPods, e selecionar para poder fazer a build.

Na sequência, selecionamos o "Project Path" do projeto. Pense comigo, temos o projeto, e o projeto tem um Path, que é onde fica o pubspec.yaml daquele projeto.

Mas algumas empresas, ou dependendo do contexto, que utilizam um Monorepo, um Packages, com alguns outros projetos juntos, no mesmo contexto, teremos mais de um Path.

Por exemplo, teremos um Monorepo, com três aplicativos diferentes. Podemos ir nesses campos e selecionar qual o aplicativo que será buildado. No caso, como é apenas um projeto, ele está na raiz do projeto, ele vai trazer apenas o ponto no campo "Project Path", e selecionamos.

Uma vez que selecionamos o Path do projeto, na sequência, selecionamos o formato da build do Android, no campo "Android build format". No Android, temos duas diferentes formas de arquivos que são gerados na build. Temos o AAB e o APK.

AAB e APK

Qual é a diferença? O AAB é uma versão um pouco mais segura, mais cartografada, seguindo alguns padrões necessários da Google Play para publicação. Inclusive, ela só utiliza esse tipo de versão para publicar. Antigamente, você usava o APK para subir e publicar. Hoje, não mais. Foi uma versão mais performática e estruturada.

Qual é a finalidade do APK? O APK continua sendo utilizado para realizar testes. Portanto, basicamente, ao utilizar o APK, você pode subir o APK e instalar no seu dispositivo móvel. Neste caso, como estamos criando uma versão de teste, optamos pelo APK, que é uma versão mais abrangente que pode ser instalada em qualquer dispositivo Android.

Em seguida, escolhemos o modo de compilação em "Mode". Podemos optar por debug, release ou profile. Novamente, para nossa versão de teste, escolhemos debug. Se desejar, também é possível gerar uma versão para publicação na loja de aplicativos, selecionando release nessa etapa.

Na sequência, vamos trazer o "Build arguments", tanto para Android, iOS e Web. Parte importante. Caso você esteja utilizando flavors, ambientes ou alguma configuração específica na hora de rodar seu aplicativo, você vai ter que trazer a mesma configuração para cá.

Por exemplo, se você tivesse seu aplicativo dividido em ambientes, você conseguiria definir nesta seção o flavor. Por exemplo, em "Android", colocaris "flavor development". Além do "flavor development", o target (flavor development -t) que seria o arquivo de geração.

Quando você tem ambientes distintos, é provável que tenha três main diferentes, ou até mesmo duas main distintas, como por exemplo, um main dev, um main prod, ou um main homolog. No campo colocaríamos: "-t lib/main_dev.dart".

Assim, ele será direcionado corretamente para seguir toda a configuração específica do ambiente. No entanto, em nosso projeto, que é simples e não possui configuração de ambientes separados, não será necessário definir esses argumentos.

Como já está tudo muito estabelecido, salvamos as mudanças clicando no botão verde "Save chances" no canto superior direito.

Além da Build, podemos configurar a notificação. Ainda não vamos configurar a distribuição.

Configurando a notificação

A distribuição é um processo que faremos a entrega já, de maneira automática, direto onde será configurado. Neste caso, não vamos distribuir de maneira automática. Ainda, porque vamos deixar um pouco mais para frente, que tem algumas coisas bem específicas.

Mas, por enquanto, vamos gerar essa Build e notificar nossas pessoas usuárias, nossos testes, que essa Build foi gerada para ele conseguir baixar o APK e fazer o teste. Para isso, abrimos seção de "notifications", que já expliquei como configurar no curso de CI.

Basicamente, abrimos a seção de e-mail e colocamos os e-mails que desejamos que receba esses artefatos. No caso, também, você pode estar configurando o Slack.

Assim que concluímos o fluxo de CD, a primeira compilação automática não constitui ainda um fluxo de CD totalmente estruturado, mas já está configurada como uma compilação automática. Podemos então iniciar uma nova compilação a partir daqui clicando em "Start new build" no canto superior direito.

Para isso, selecionamos o Workflow "CD-WORKFLOW" na janela exibida, clicamos em iniciar nova compilação ("Start new build") e o processo de compilação é iniciado.

No entanto, antes de prosseguirmos com isso, gostaria de destacar outra funcionalidade, que são os "Build Triggers", os quais também aprendemos a configurar no fluxo de CI. Basicamente, o funcionamento é semelhante, seguindo a mesma lógica e padrão.

Na seção "Build Triggers", podemos definir o padrão para a compilação automática ao abrir um PR, ao fechar um PR, ao estruturar uma Tag, entre outras opções. Isso proporcionará uma definição clara do que acionará automaticamente a compilação, permitindo que ela seja disparada de forma automática.

Seguindo esse princípio, mantemos as configurações semelhantes às do desk, apenas para que possamos realizar a execução. Mais adiante, iremos configurar as coisas de forma mais estruturada. Por enquanto, para vermos o fluxo funcionando, vamos iniciar manualmente a compilação. Isso será feito clicando em "Start New Build", selecionando a branch (ramificação), no caso, a "Main", escolhendo o Workflow, que no caso é o "CD Workflow", e então clicando no botão "Start New Build".

Ele iniciará automaticamente o processo de execução. A etapa de tags não será executada devido à nossa configuração de desativação, portanto, desabilitamos essa etapa e ele seguirá com a compilação do Droid. Voltarei quando a compilação estiver concluída.

Agora que a compilação foi finalizada e os artefatos foram gerados, ao abrir o VS Code na mesma aba que estávamos configurando em "Building Android", observamos que o processo de compilação foi concluído. Ele gerou e publicou os artefatos conforme observamos na seção "Publishing", que atualmente estão sendo publicados apenas no e-mail.

Os artefatos incluem o app-debug.apk e outras partes estruturais. Eles estão listados na lateral esquerda. Se desejar, por exemplo, baixar o apk gerado pelo Codemagic, você pode fazê-lo aqui.

Você pode vir diretamente do lado esquerdo sem precisar de um e-mail específico. Basta clicar no arquivo apk em "Artifacts", que ele será baixado automaticamente. Ao abrir o arquivo, você poderá baixar e instalar no seu projeto.

O tamanho do arquivo ficou maior, cerca de 146 MB, porque é um arquivo apk de depuração (debug). Isso significa que não passou por todos os processos de otimização para reduzir seu tamanho.

Conclusão e Próximos Passos

O sistema está estruturado e funcionando conforme esperado. Nesta aula, aprendemos como criar essa build automaticamente. Ainda não finalizamos o processo de integração para distribuição automática na loja, mas já estamos simplificando bastante o processo de geração dessas versões.

Não precisamos repetir todo o processo a cada vez, podemos manter uma estrutura organizada para facilitar. Por enquanto, continuaremos dessa forma e na próxima aula aprenderemos a realizar entregas automáticas das versões de software no nosso fluxo de trabalho diário, garantindo um processo consistente tanto em termos de qualidade como já fizemos no processo de Integração Contínua, quanto na etapa de construção (Build).

Após isso, conforme planejado e com a estrutura pronta, implementaremos a distribuição automática na loja. Nos vemos na próxima aula!

Sobre o curso Flutter: automatizando o projeto com entrega contínua (CD)

O curso Flutter: automatizando o projeto com entrega contínua (CD) possui 76 minutos de vídeos, em um total de 34 atividades. Gostou? Conheça nossos outros cursos de Flutter em Mobile, ou leia nossos artigos de Mobile.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Entrega contínua (CD) no Flutter
• Pipelines de CI/CD
• Automação da build de produção
• Versionamento do app