Introdução à integração contínua com o Xamarin
A Integração Contínua é uma prática de engenharia de software na qual um build automatizado compila e, opcionalmente, testa um aplicativo quando o código é adicionado ou alterado por desenvolvedores no repositório de controle de versão do projeto. Este artigo discutirá os conceitos gerais de Integração Contínua e algumas das opções disponíveis para integração contínua com projetos do Xamarin.
É comum em projetos de software para desenvolvedores trabalharem em paralelo. Em algum momento, é necessário integrar todos esses fluxos paralelos de trabalho em uma base de código que compõe o produto final. Nos primeiros dias de desenvolvimento de software, essa integração era executada no final de um projeto, que era um processo difícil e arriscado.
A CI (integração contínua) evita essas complexidades mesclando as alterações de cada desenvolvedor na base de código comum continuamente, geralmente sempre que qualquer desenvolvedor verifica alterações no repositório de código compartilhado do projeto. Cada marcar dispara um build automatizado e executa testes automatizados para verificar se o código recém-introduzido não interrompeu nenhum código existente. Dessa forma, a CI apresenta erros e problemas imediatamente e garante que todos os membros da equipe permaneçam atualizados com o trabalho uns dos outros. Isso resulta em uma base de código coesa e estável.
Os sistemas de integração contínua têm duas partes main:
- Controle de versão – VC (controle de versão), também chamado de controle do código-fonte ou gerenciamento de código-fonte, consolida todo o código de um projeto em um único repositório compartilhado e mantém um histórico completo de cada alteração em cada arquivo. Esse repositório, geralmente chamado de branch de linha principal , contém o código-fonte que, em última análise, será usado para criar a versão de produção ou lançamento do aplicativo. Há muitas código aberto e produtos comerciais para essa tarefa, que normalmente permitem que equipes ou indivíduos criem fork de uma cópia do código em branches secundários, onde eles podem fazer alterações extensivas ou realizar experimentos sem risco para o branch main. Depois que as alterações em um branch secundário forem validadas, elas poderão ser todas mescladas novamente no branch main.
- Servidor de Integração Contínua – o Servidor de Integração Contínua é responsável por coletar todos os artefatos de um projeto (código-fonte, imagens, vídeos, bancos de dados, testes automatizados etc.), compilar o aplicativo e executar os testes automatizados. Novamente, há muitas ferramentas de servidor de CI comerciais e código aberto.
Os desenvolvedores normalmente têm uma cópia funcional de um ou mais branches em suas estações de trabalho, em que o trabalho é feito inicialmente. Depois que um conjunto de trabalho apropriado for concluído, as alterações serão "verificadas" ou "confirmadas" no branch apropriado, o que as propaga para as cópias de trabalho de outros desenvolvedores. É assim que uma equipe garante que todos estejam trabalhando no mesmo código.
Novamente, com a integração contínua, o ato de confirmar alterações faz com que o servidor de CI compile o projeto e execute testes automatizados para verificar a exatidão do código-fonte. Se houver erros de build ou falhas de teste, um servidor de CI notificará o desenvolvedor responsável (por email, mensagens instantâneas, Twitter, Growl etc.) para que ele possa corrigir o problema. (Os servidores de CI podem até mesmo recusar a confirmação se houver falhas, o que é chamado de "marcar fechado".)
O diagrama a seguir ilustra esse processo:
Os aplicativos móveis apresentam desafios exclusivos para a integração contínua. Os aplicativos podem exigir sensores como o GPS ou a câmera que só estão disponíveis em dispositivos físicos. Além disso, simuladores ou emuladores são apenas uma aproximação de hardware e podem ocultar ou obscurecer problemas. No final, é necessário testar um aplicativo móvel em hardware real para ter certeza de que ele está realmente pronto para o cliente.
O Teste do App Center resolve esse problema específico testando aplicativos diretamente em centenas de dispositivos físicos. Os desenvolvedores gravam testes de aceitação automatizados, que permitem testes avançados de interface do usuário. Depois que esses testes são carregados no App Center, o servidor de CI pode executá-los automaticamente como parte de um processo de CI, conforme mostrado no diagrama a seguir:
Há um amplo ecossistema de ferramentas comerciais e de software livre projetadas para dar suporte à CI. Esta seção explica algumas das mais comuns.
O Azure DevOps e o TFS (Team Foundation Server ) são ferramentas colaborativas da Microsoft para serviços de build de integração contínua, acompanhamento de tarefas, planejamento ágil e ferramentas de relatório e controle de versão. Com o controle de versão, o Azure DevOps e o TFS podem trabalhar com seu próprio sistema (Controle de Versão do Team Foundation ou TFVC) ou com projetos hospedados no GitHub.
- O Azure DevOps fornece serviços por meio da nuvem. Sua principal vantagem é que ele não requer hardware ou infraestrutura dedicado e pode ser acessado de qualquer lugar por meio de navegadores da Web e por meio de ferramentas de desenvolvimento populares, como o Visual Studio, tornando-o atraente para equipes que são distribuídas geograficamente. Ele é gratuito para equipes de cinco desenvolvedores ou menos, após os quais licenças adicionais podem ser compradas para acomodar uma equipe em crescimento.
- O TFS foi projetado para servidores Windows locais e acessado por meio de uma rede local ou uma conexão VPN com essa rede. Sua principal vantagem é que você controla totalmente a configuração dos servidores de build e pode instalar qualquer software ou serviço adicional necessário. O TFS tem uma edição Express de nível de entrada gratuita para equipes pequenas.
O TFS e o Azure DevOps são totalmente integrados ao Visual Studio e permitem que os desenvolvedores executem muitas tarefas de CONTROLE de versão e CI de dentro do conforto de um único IDE. O plug-in Team Explorer Everywhere para Eclipse (veja abaixo) também está disponível. Visual Studio para Mac tem uma versão prévia do TFVC disponível.
O Azure DevOps Pipelines tem suporte direto para projetos Xamarin, nos quais você cria uma definição de build para cada plataforma que deseja direcionar (Android, iOS e Windows). A licença do Xamarin apropriada é necessária para cada definição de build. Também é possível conectar um servidor de build TFS local compatível com Xamarin ao Azure DevOps para essa finalidade. Com essa configuração, os builds enfileirados no Azure DevOps serão delegados ao servidor local. Para obter detalhes, consulte Agentes de build e versão. Como alternativa, você pode usar outra ferramenta de build, como Jenkins ou Team City.
Um resumo completo de todos os recursos do ALM (Gerenciamento do Ciclo de Vida do Aplicativo) do Visual Studio, do Azure DevOps e do Team Foundation Server, confira DevOps com aplicativos Xamarin.
Team Explorer Everywhere traz o poder do Team Foundation Server e do Azure DevOps para equipes que estão desenvolvendo fora do Visual Studio. Ele permite que os desenvolvedores se conectem a projetos de equipe locais ou na nuvem do Eclipse ou do cliente de linha de comando multiplataforma para OS X e Linux. Team Explorer Everywhere fornece acesso completo ao controle de versão (incluindo Git), itens de trabalho e recursos de build para plataformas não Windows.
O Git é uma solução de controle de versão código aberto popular que foi originalmente desenvolvida para gerenciar o código-fonte do kernel do Linux. É um sistema muito rápido e flexível que é popular entre projetos de software de todos os tamanhos. Ele é facilmente dimensionado de desenvolvedores individuais com acesso ruim à Internet para grandes equipes que abrangem o mundo. O Git também facilita muito a ramificação, o que, por sua vez, pode incentivar fluxos paralelos de desenvolvimento com risco mínimo.
O Git pode operar inteiramente por meio de navegadores da Web ou clientes gui que são executados no Linux, Mac OSX e Windows. Ele é gratuito para repositórios públicos; os repositórios privados exigem um plano pago.
As versões atuais do Visual Studio para Windows e Mac fornecem suporte nativo para Git. A Microsoft fornece uma extensão para download do Git para versões mais antigas do Visual Studio. Conforme observado acima, o Azure DevOps e o TFS podem usar o Git para controle de versão em vez de TFVC.
O SVN (Subversion) é um sistema de controle de versão popular código aberto que está em uso desde 2000. O SVN é executado em todas as versões modernas do OS X, Windows, FreeBSD, Linux e Unix. Visual Studio para Mac tem suporte nativo para SVN. Há extensões de terceiros que trazem suporte a SVN para o Visual Studio.
Configurar um ambiente de integração contínua significa combinar um sistema de controle de versão com um serviço de build. Para este último, os dois mais comuns são:
- O Azure Pipelines é o sistema de build do Azure DevOps e do TFS. Ele é totalmente integrado ao Visual Studio, o que torna conveniente que os desenvolvedores disparem builds, executem testes automaticamente e vejam os resultados.
- O Jenkins é um servidor de CI de software livre com um ecossistema avançado de plug-ins para dar suporte a todos os tipos de desenvolvimento de software. Ele é executado no Windows e no Mac OS X. O Jenkins não está integrado a nenhum IDE específico. Em vez disso, ele é configurado e gerenciado por meio de uma interface da Web. A CI do Jenkins também é fácil de instalar e configurar, o que a torna atraente para equipes pequenas.
Você pode usar o TFS/Azure DevOps sozinho ou pode usar o Jenkins em combinação com o TFS/Azure DevOps ou o Git, conforme descrito nas seções a seguir.
Conforme discutido, o Azure DevOps e o Team Foundation Server fornecem controle de versão e serviços de build. Os serviços de build sempre exigem uma licença do Xamarin Business ou Enterprise para cada plataforma de destino.
Com o Azure DevOps, você cria uma definição de build separada para cada plataforma de destino e insere a licença apropriada lá. Depois de configurado, o Azure DevOps executará builds e testes na nuvem. Confira Azure Pipelines para obter mais detalhes.
Com o Team Foundation Server, você configura um computador de build da seguinte maneira para plataformas de destino específicas:
- Android e Windows: Instale o Visual Studio e as ferramentas do Xamarin (para Android e Windows) e configure com suas licenças do Xamarin. Também é necessário mover o SDK do Android para um local compartilhado no servidor onde o agente de build do TFS pode encontrá-lo. Para obter detalhes, consulte Configurando o TFVC.
- iOS e Xamarin: Instale o Visual Studio e as ferramentas do Xamarin no servidor Windows com a licença apropriada. Em seguida, instale Visual Studio para Mac em um computador Mac OS X acessível pela rede, que servirá como um host de build e criará o pacote final do aplicativo (IPA para iOS, APP para OS X).
O diagrama a seguir ilustra esta topografia:
Também é possível vincular um servidor TFS local a um projeto do Azure DevOps para que os builds do Azure DevOps sejam delegados ao servidor local. Para obter detalhes, consulte Agentes de build e lançamento.
Se você usar o Jenkins para criar seus aplicativos, poderá armazenar seu código no Azure DevOps ou no Team Foundation Server e continuar a usar o Jenkins para seus builds de CI. Você pode disparar um build do Jenkins ao enviar código por push para o repositório Git do projeto de equipe ou quando marcar código no TFVC. Para obter detalhes, consulte Jenkins com o Azure DevOps.
Outro ambiente de CI comum pode ser totalmente baseado em OS X. Esse cenário envolve o uso do Git para o controle de código-fonte e o Jenkins para o servidor de build. Ambos estão em execução em um único computador Mac OS X com Visual Studio para Mac instalado. Isso é muito semelhante ao ambiente do Azure DevOps + Jenkins discutido na seção anterior:
Importante
O Jenkins não tem suporte da Microsoft.