Cómo GitLab con fastlane compila, firma y publica aplicaciones para iOS en el App Store.
Recientemente tuvimos con GitLab y . Aquí veremos cómo compilar y lanzar una aplicación de iOS y publicarla en TestFlight. Echa un vistazo a lo genial que es , tomar la compilación y obtener la actualización de la versión de prueba de la aplicación en el mismo iPad Pro donde la desarrollé.
Aquí utilizaremos , con la que grabé el video.
Algunas palabras sobre la configuración de Apple Store
Necesitaremos una aplicación en App Store, certificados de distribución y un perfil de aprovisionamiento para unir todo.
Lo más complicado aquí es configurar los permisos de firma en el App Store. Espero que puedan manejar esto por sí mismos. Si son nuevos, les indicaré la dirección correcta, pero aquí no hablaremos de los detalles de la gestión de certificados de Apple, además, estos cambian constantemente. Esta publicación les ayudará a empezar.
Mis aplicaciones
Necesitan una aplicación en App Store Connect para tener un ID para la configuración .xcodebuild. El perfil y el ID de la aplicación combinan las compilaciones de código, precios y disponibilidad, así como la configuración de TestFlight para distribuir aplicaciones de prueba entre los usuarios. No hagan pruebas públicas, es suficiente con la privada si tienen un grupo pequeño, una configuración sencilla y no necesitan permisos adicionales de Apple.
El perfil de aprovisionamiento
Además de configurar la aplicación, necesitan claves de distribución y desarrollo de iOS, creadas en la sección Certificados, Identificadores y Perfiles en la consola de Apple Developer. Todos estos certificados se pueden combinar en un perfil de aprovisionamiento.
Los usuarios que pasarán por la autenticación necesitan la capacidad de crear certificados, de lo contrario, en las etapas verán un error.
Otras opciones
Además de este método sencillo, hay otras formas de configurar certificados y perfiles. Así que, si trabajan de manera diferente, tal vez tengan que reconfigurarse. Lo más importante es que necesitarán una configuración .xcodebuild, que apunte a los archivos necesarios, y la llavero debe estar disponible en la computadora de compilación para el usuario bajo cuyo nombre opera el runner. Para la firma digital utilizamos fastlane, y si hay problemas o quieren saber más, revisen su documentación detallada. .
En este ejemplo, utilizo un enfoque , pero para aplicaciones reales, probablemente sea mejor .
Preparación de GitLab y fastlane
Preparación del CI Runner
Una vez que tengas todos estos datos, pasamos a la configuración del GitLab Runner en un dispositivo MacOS. Desafortunadamente, crear aplicaciones iOS solo es posible en MacOS. Pero todo puede cambiar, y si esperas avances en este área, sigue proyectos como y , y nuestra tarea interna .
Configurar el runner es muy sencillo. Sigue las .
Nota. El runner debe utilizar el programa ejecutable shell. Esto es obligatorio para compilar iOS en macOS, para trabajar directamente como usuario y no a través de contenedores. Si estás utilizando shell, la compilación y prueba se realizan bajo el nombre del usuario del runner, directamente en el host de compilación. Esto no es tan seguro como los contenedores, así que es mejor revisar la , para no dejar nada al azar.
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 startEl llavero de Apple debe estar configurado en este host con acceso a las claves que Xcode necesita para la compilación. La forma más sencilla de probar esto es iniciar sesión como el usuario que ejecutará la compilación e intentar realizar la compilación manualmente. Si el sistema solicita acceso al llavero, selecciona "Siempre permitir" para que CI funcione. Puede que valga la pena iniciar sesión y observar los primeros par de pipelines, para asegurarte de que ya no solicitan el llavero. El problema es que Apple no facilita el trabajo con el modo automático, pero una vez que lo configures, todo debería estar bien.
fastlane init
Para utilizar fastlane en el proyecto, ejecuta fastlane init. Simplemente sigue las , especialmente en la sección sobre , ya que necesitamos un inicio rápido y predecible a través del pipeline automatizado de CI.
En el directorio del proyecto, ejecuta estos comandos:
xcode-select --install
sudo gem install fastlane -NV
# Alternativamente usando Homebrew
# brew cask install fastlane
fastlane initfastlane te pedirá la configuración básica y luego creará en el proyecto una carpeta fastlane con tres archivos:
1. fastlane/Appfile
No hay nada complicado aquí. Simplemente verifica que el ID de Apple y el ID de la aplicación estén correctos.
app_identifier("com.vontrance.flappybird") # El identificador del paquete de tu aplicación
apple_id("your-email@your-domain.com") # Tu dirección de correo electrónico de Apple2. fastlane/Fastfile
Fastfile define los pasos de construcción. Usamos muchas capacidades integradas de fastlane, así que aquí también es claro. Creamos una línea que obtiene los certificados, realiza la construcción y la sube a TestFlight. Puedes dividir este proceso en diferentes tareas si es necesario. Todas estas operaciones (get_certificates, get_provisioning_profile, gym y upload_to_testflight) ya están incluidas en fastlane.
Acciones get_certificates y get_provisioning_profile están relacionadas con el enfoque de firma . Si usas o algo más, realiza los cambios.
default_platform(:ios)
platform :ios do
desc "Construir la aplicación"
lane :flappybuild do
get_certificates
get_provisioning_profile
gym
upload_to_testflight
end
end3. fastlane/Gymfile
Este es un archivo opcional, pero lo creé manualmente para cambiar el directorio de salida predeterminado y colocar los resultados en la carpeta actual. Esto facilita la CI. Si te interesa, lee sobre gym y sus parámetros en .
https://docs.fastlane.tools/actions/gym/Nuestro .gitlab-ci.yml
Así que tenemos un corredor de CI para el proyecto y estamos listos para probar el pipeline. Veamos qué tenemos en .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.ipa¡Todo está perfecto! , usamos la estrategia clone con el ejecutable shell, para tener un espacio de trabajo limpio para cada construcción, y simplemente llamamos a flappybuild fastlane, como se muestra arriba. Como resultado, obtenemos la construcción, firma y despliegue de la última construcción en TestFlight.
También obtenemos el artefacto y lo guardamos con la construcción. Ten en cuenta que el formato .ipa es un archivo ejecutable ARM firmado, que no se puede ejecutar en el simulador. Si deseas resultados para el simulador, simplemente añade un objetivo de construcción que lo genere y luego inclúyelo en la ruta del artefacto.
Otras variables de entorno
Aquí hay un par de variables de entorno en las que todo funciona.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD y FASTLANE_SESSION
Para la autenticación en la App Store y la carga en TestFlight, se necesita autenticación para fastlane. Para ello, crea una contraseña de aplicación que se utilizará en CI. Detalles .
Si tienes autenticación de dos factores, crea una variable FASTLANE_SESSION (instrucciones allí mismo).
FASTLANE_USER y FASTLANE_PASSWORD
Para llamamos al perfil de inicialización y certificados bajo demanda, necesitas establecer variables FASTLANE_USER y FASTLANE_PASSWORD. Detalles . Esto no es necesario si utilizas otro método de firma.
En conclusión
Vea cómo funciona todo esto .
Espero que haya sido útil y que lo haya inspirado a trabajar con las compilaciones de iOS en su proyecto de GitLab. Aquí hay más para fastlane, por si acaso. Quizás quiera usar CI_BUILD_ID (para compilaciones incrementales), para .
Otra gran función de fastlane es para la App Store, que son muy fáciles de configurar.
Comparta en los comentarios su experiencia y comparta ideas para mejorar GitLab para el desarrollo de aplicaciones iOS.
Fuente: habr.com
