Configurando CI/CD para aplicativos dotnet MAUI utilizando AzureDevops.
Esse artigo faz parte de uma série que visa explicar sobre todo potencial que podemos adquirir através de pipelines automatizadas.
Nesses artigos vou apresentar formas de criar essas automações tanto utilizando o Azure Pipelines quanto o Github Actions.
Caso você tenha alguma outra sugestão de artigo, fique a vontade para sugerir nos comentários no final do post!
1. Repositório
Caso você ja possua um repositório no AzureDevops ou vinculado ao Azure através de outra fonte, você pode pular para o tópico 2.
Com sua conta do AzureDevops criada, você irá criar um projeto preenchendo as informações de nome, descrição e visibilidade.
Ao criar o projeto, podemos iniciar um repositório diretamente via portal ou, caso o código do app ja exista, podemos importá-lo.
Para esse caso vou importar do Github, pois o aplicativo já existe no meu perfil, selecionando diretamente Pipelines > New Pipeline.
Após vincular sua conta Github, você poderá selecionar qualquer repositório para utilizar na pipeline que você está criando.
Então alguns templates serão oferecidos mas, até a escrita desse artigo, nenhum template de dotnet maui existia, então iniciaremos com uma pipeline vazia.
2. Criando pipeline
Ao criar uma pipeline em formato YAML, teremos o template a seguir oferecido pelo AzureDevops:
O “trigger” simboliza quando a pipeline vai ser executada de forma automática. No caso do template, sempre que o branch “main” tiver alguma alteração, seja através de um PullRequest ou Commits diretos.
Além disso estamos utilizando um ubuntu na ultima versão do sistema operacional, para rodar os passos dessa pipeline.
Nesse exemplo vamos gerar nosso aplicativo para android e iOS, portanto queremos que esses artefatos sejam construidos de forma paralela e independente. Assim conseguimos verificar se existe problema de compilação em apenas uma plataforma entre outros benefícios, como o da redução do tempo total da pipeline.
No AzureDevops um agrupador de tarefas se chama “Job”, onde podemos criar um “passo a passo” para a execução de um processo especifico.
3. Configurando Android
A partir da linha 9 até a linha 45 temos todo o processo de compilação para android chamados de Task.
Cada Task tem o objetivo de ajustar o ambiente para que a compilação ocorra de forma correta.
Primeiro instalamos definimos a versão do dotnet (linha 10) que é necessaria para o nosso projeto, nesse exemplo estamos usando a versao net7.
Logo após instalamos o workload do dotnetMaui (linha 16), que é necessário para compilar o qualquer projeto feito em MAUI.
Finalmente começamos o processo de compilação (linha 24) utilizando o comando dotnet publish passando como parametro a informação — f net7-android indicando que compilaremos apenas para a plataforma android.
Como queremos ter acesso ao “apk” e/ou “aab”, vamos copiá-los (linha 31) para o diretório de artefatos e em seguida publicá-los (linha 40).
Dessa forma teremos acesso diretamente na pipeline, na aba de artifacts.
4. Configurando iOS
Aqui o processo é bem parecido com o do android, a diferença começa na máquina virtual (linha 7) utilizada pra compilar, que precisamos que seja Mac.
Nesse caso utilizei o macos-latest, que utiliza a ultima versão do MacOs estavél disponivel pelo AzureDevops.
Considerações finais
Nesse post aprendemos um pouco do funcionamento do AzurePipelines, utilizando yaml focado em MAUI. No meu próximo post ensinarei a fazer a assinatura dos artefatos, tanto para Android quanto para IOS.
Caso tenha dúvidas ou sugestões sobre algum tema específico, deixa aqui nos comentários para eu trazer de forma simplificada para você.
Repositório de exemplo:
felipebaltazar
/
Maui.AzurePipelines
Utilitários para Azure pipelines feito em dotnet MAUI
Maui.AzurePipelines
Utilitários para Azure Pipelines feito em MAUI
Utilização
Acesse a documentação da microsoft para criação do "Personal Access Token"
Top comments (2)
Uma dica, dá pra otimizar mais se rodar tudo no MacOs quando estiver trabalhando com Android e iOS. Exemplo, definir a imagem que todo o arquivo que compila para as duas plataformas ser o MacOs. Economiza uns bons minutos de build essa mudança.
Só tem que ficar de olho que o
MacOsgera custos de utilização da imagem, geralmente as empresas limitam o uso dele, oque acaba criando mais fila.