Como o GitLab com o fastlane compila, assina e publica aplicativos para iOS na App Store.
Recentemente, tivemos um com GitLab e . Aqui veremos como compilar e lançar um aplicativo iOS e publicá-lo no TestFlight. Confira como é legal , pego a compilação e recebo a atualização da versão beta do aplicativo no mesmo iPad Pro em que o desenvolvi.
Aqui pegaremos , com o qual gravei o vídeo.
Algumas palavras sobre a configuração da Apple Store
Precisamos de um aplicativo na App Store, certificados de distribuição e um perfil de inicialização para conectar tudo isso.
O mais difícil aqui é configurar as permissões de assinatura na App Store. Espero que você consiga lidar com isso por conta própria. Se você é iniciante, eu indicarei a direção certa, mas aqui não falaremos sobre as nuances da gestão de certificados da Apple, pois eles mudam constantemente. Este post ajudará a dar os primeiros passos.
Meus aplicativos
É necessário um aplicativo no App Store Connect para ter um ID para configuração .xcodebuild. O perfil e o ID do aplicativo unem as compilações de código, preços e disponibilidade, além da configuração do TestFlight para distribuir aplicativos de teste entre usuários. Não faça testes públicos, um teste privado é suficiente se você tiver um grupo pequeno, configuração simples e não precisar de permissões adicionais da Apple.
Perfil de inicialização
Além da configuração do aplicativo, você precisa de chaves de distribuição e desenvolvimento para iOS, criadas na seção Certificados, Identificadores e Perfis no console do Apple Developer. Todos esses certificados podem ser combinados em um perfil de inicialização.
Os usuários que farão a autenticação precisam ter a capacidade de criar certificados, caso contrário, nas etapas você verá um erro.
Outras opções
Além desse método simples, existem outras formas de configurar certificados e perfis. Portanto, se você trabalhar de maneira diferente, talvez precise se adaptar. O mais importante é que você precisará de uma configuração .xcodebuild, que indicará os arquivos necessários, e o chaveiro deve estar acessível no computador da construção para o usuário sob o qual o runner opera. Para a assinatura digital, usamos o fastlane, e se houver problemas ou você quiser saber mais, estude a sua documentação detalhada .
Neste exemplo, eu uso a abordagem , mas para a aplicação real, provavelmente será melhor usar .
Preparação do GitLab e fastlane
Preparação do CI Runner
Reunindo todas essas informações, passamos à configuração do GitLab-runner no dispositivo MacOS. Infelizmente, compilar aplicativos iOS só é realmente possível no MacOS. Mas tudo pode mudar, e se você está esperando por atualizações nessa área, fique de olho em projetos como e , e na nossa tarefa interna .
Configurar o runner é muito simples. Siga as .
Nota. O runner deve usar o programa executável shell. Isso é fundamental para compilar iOS no macOS, para operar diretamente como um usuário, e não através de contêineres. Se você usar shell, a construção e os testes são realizados sob o nome do usuário do runner, diretamente no host de construção. Isso não é tão seguro quanto contêineres, então é melhor revisar a , para não perder nada.
sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
cd ~
gitlab-runner install
gitlab-runner startO chaveiro da Apple deve estar configurado neste host com acesso às chaves necessárias que o Xcode precisa para compilar. A maneira mais fácil de testar isso é entrar como o usuário que iniciará a construção e tentar compilar manualmente. Se o sistema solicitar acesso ao chaveiro, escolha 'Sempre permitir' para que o CI funcione. Pode ser útil entrar e monitorar os primeiros pipelines, para garantir que não solicitem mais o chaveiro. O problema é que a Apple não facilita a automação, mas quando você configurar, tudo funcionará corretamente.
fastlane init
Para usar o fastlane no projeto, execute fastlane init. Basta seguir as , especialmente na seção sobre , pois precisamos de um lançamento rápido e previsível através do pipeline automático de CI.
No diretório do projeto, execute estes comandos:
xcode-select --install
sudo gem install fastlane -NV
# Alternativamente usando o Homebrew
# brew cask install fastlane
fastlane initfastlane solicitará a configuração básica e, em seguida, criará uma pasta fastlane no projeto com três arquivos:
1. fastlane/Appfile
Aqui não há nada complicado. Basta verificar se o Apple ID e o ID do aplicativo estão corretos.
app_identifier("com.vontrance.flappybird") # O identificador do pacote do seu aplicativo
apple_id("your-email@your-domain.com") # Seu endereço de e-mail da Apple2. fastlane/Fastfile
Fastfile define os passos de construção. Usamos muitas funcionalidades integradas do fastlane, então aqui também está tudo claro. Criamos uma linha que obtém certificados, executa a construção e a envia para o TestFlight. Você pode dividir esse processo em tarefas diferentes, se necessário. Todas essas operações (get_certificates, get_provisioning_profile, gym e upload_to_testflight) já estão incluídas no fastlane.
Ações get_certificates e get_provisioning_profile relacionadas à abordagem de assinatura . Se você estiver usando ou algo mais, faça alterações.
default_platform(:ios)
platform :ios do
desc "Build the application"
lane :flappybuild do
get_certificates
get_provisioning_profile
gym
upload_to_testflight
end
end3. fastlane/Gymfile
Este é um arquivo opcional, mas eu criei manualmente para alterar o diretório de saída padrão e colocar a saída na pasta atual. Isso simplifica o CI. Se estiver interessado, leia sobre gym e suas opções em .
https://docs.fastlane.tools/actions/gym/Nosso .gitlab-ci.yml
Então, temos um CI-runner para o projeto, e estamos prontos para testar o pipeline. Vamos ver o que temos em .gitlab-ci.yml:
stages:
- build
variables:
LC_ALL: "en_US.UTF-8"
LANG: "en_US.UTF-8"
GIT_STRATEGY: clone
build:
stage: build
script:
- bundle install
- bundle exec fastlane flappybuild
artifacts:
paths:
- ../FlappyBird.ipaTudo ótimo! , usando a estratégia clone com o executável shell, para que tenhamos um espaço de trabalho limpo para cada construção e apenas chamamos flappybuild fastlane, como visto acima. No final, obtemos a construção, assinatura e implantação da última construção no TestFlight.
Além disso, obtemos o artefato e o salvamos junto com a construção. Observe que o formato .ipa — é um arquivo executável ARM assinado que não é executável no simulador. Se você deseja a saída para o simulador, basta adicionar um alvo de construção que o produza e depois incluí-lo no caminho do artefato.
Outras variáveis de ambiente
Aqui existem algumas variáveis de ambiente que fazem tudo funcionar.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD e FASTLANE_SESSION
Para autenticação na App Store e upload para o TestFlight, é necessária a autenticação para o fastlane. Para isso, crie uma senha específica para o aplicativo que será usada no CI. Detalhes .
Se você tem autenticação de dois fatores, crie uma variável FASTLANE_SESSION (instruções lá mesmo).
FASTLANE_USER e FASTLANE_PASSWORD
Para chamar o perfil de inicialização e os certificados sob demanda, você precisa definir as variáveis FASTLANE_USER e FASTLANE_PASSWORD. Detalhes . Isso não é necessário se você estiver usando outro método de assinatura.
Para concluir
Veja como tudo isso funciona .
Espero que isso tenha sido útil e que eu tenha inspirado você a trabalhar com builds iOS no projeto GitLab. Aqui estão mais para fastlane, caso você queira usar CI_BUILD_ID (para builds incrementais), para .
Mais uma função legal do fastlane é para a App Store, que são muito fáceis de configurar.
Conte nos comentários sobre sua experiência e compartilhe ideias para melhorar o GitLab para o desenvolvimento de aplicativos iOS.
Fonte: habr.com
