Con un equipo móvil en crecimiento y lanzamientos semanales, es esencial contar con un canal de CI fiable. Necesitamos poder crear y probar nuestras aplicaciones e implementarlas en la App Store y Google Play Store. También mantenemos versiones preliminares internas para probar las últimas funciones.
Descubra cómo utilizamos ClickUp, Fastlane y GitHub Actions para automatizar nuestra integración continua (CI) y entrega continua (CD).
La vida de un error 🐜
Comencemos por repasar rápidamente nuestro proceso de gestión y corrección de incidencias.
- Se informa de un error (o se solicita una función) y se crea una tarea en ClickUp.
- La tarea se asigna a un desarrollador y se fija en una solicitud de incorporación de cambios (PR) contra la rama de staging.
- La CI ejecuta todas las pruebas, crea la app, implementa una vista previa web y sube todo a la tarea de ClickUp.
- Nuestro equipo de control de calidad verifica la corrección y, si es correcta, la tarea se marca como terminada.
- Las solicitudes de incorporación de cambios se combinan automáticamente en la fase de pruebas.
- La rama de staging se crea y se implementa en nuestro TestFlight interno.
- Todos los miércoles se crea, compila y prueba una rama de lanzamiento.
- Los viernes, creamos una versión en GitHub y la CI la implementa en la App Store y la Play Store.
Una tarea de ClickUp contiene toda la información sobre el error. Utilizamos estados personalizados como «En curso» o «Revisión de código» para realizar un seguimiento del error. Los flujos de trabajo de CI cambian el estado automáticamente. Los campos personalizados contienen información adicional, como quién informó del error, quién trabaja en él, cuándo se publicará, etc.
Flujo de trabajo de relaciones públicas 📜
Los dos primeros pasos descritos anteriormente no están realmente relacionados con la CI, pero el tercero es interesante...
Nuestro flujo de trabajo de desarrollo se ejecuta para cualquier PR. Comprueba los lints, el formato y ejecuta todas las pruebas antes de comenzar a crear los artefactos de Android e iOS.
Cuando una compilación se realiza con éxito, la CI publica un mensaje en la tarea enlazada. Los ingenieros de control de calidad pueden ir a la solicitud de incorporación de cambios, descargar los artefactos de compilación o utilizar la vista previa web.
Mensaje de CI automatizado publicado en la tarea de ClickUp enlazada tras una compilación satisfactoria.
Configuración de Flutter en el ejecutor de CI 🛠
Utilizamos la conocida acción de GitHub subosito/flutter-action para configurar Flutter en la CI. De forma predeterminada, por defecto, instalará la última versión estable de Flutter. Para evitar interrumpir sus flujos de trabajo de CI cuando se lance una nueva versión de Flutter, debe especificar la versión manualmente.
Si tienes varios flujos de trabajo, es mejor almacenar la versión de Flutter en un archivo. Utilizamos FLUTTER_VERSION en la raíz del repositorio.
Otra solución sencilla es almacenar la versión de Flutter como secreto de GitHub y acceder a ella utilizando {{ secrets. FLUTER_VERSION }}.
Vista previa web 🕸
Gracias a la capacidad de Flutter para ejecutarse en la web, podemos crear una vista previa web totalmente funcional de las solicitudes de validación. Con el paquete device_preview, se puede ajustar el tamaño y los ajustes del dispositivo.
La vista previa ha demostrado ser muy útil y no solo la utiliza nuestro equipo de control de calidad. A los diseñadores y gestores de productos también les gusta para iterar rápidamente en nuevas funciones.
a través de Flutter
Cómo crear una vista previa web 🐶
Para empezar, asegúrate de que tu aplicación sea compatible con Flutter web, ya que no todas las API tienen compatibilidad.
En nuestra app, por ejemplo, necesitábamos desactivar las notificaciones push y los sockets web.
Este flujo de trabajo de muestra crea una vista previa web de su aplicación Flutter y la carga en un bucket S3. Utilizamos una variable de entorno ENABLE_DEVICE_PREVIEW para desactivar device_preview en producción.
El paso «Fix base href» es necesario porque la vista previa no estará en la raíz del bucket.
Y algo de código para habilitar de forma condicional la vista previa del dispositivo (device_preview).
Las variables de entorno son una herramienta muy potente y permiten al algoritmo de optimización de código de Flutter eliminar el código de depuración para las compilaciones de lanzamiento.
Fastlane 💨
Fastlane simplifica enormemente la creación, firma e implementación de aplicaciones Flutter. Gestiona nuestros certificados, perfiles de aprovisionamiento y otros ajustes. Utilizamos los secretos de GitHub para almacenar contraseñas y tokens de forma segura.
Acciones útiles de Fastlane:
- fastlane match para crear y almacenar claves y perfiles iOS en un repositorio GitHub.
- build_app para crear aplicaciones para iOS y Android.
- upload_to_testflight y entrega para implementar compilaciones iOS.
- upload_to_play_store para implementar compilaciones de Android
Muestra de compilación de desarrollo para iOS 🍏
No olvide setup_ci, le evitará errores extraños 👾. Obtenga más información sobre Fastlane para aplicaciones Flutter.
Firma de Android 🔒
La forma más sencilla de firmar de forma segura las compilaciones de lanzamiento de Android es almacenar los tokens como secretos de GitHub y utilizar variables de entorno y una clave temporal. jks creados por la CI:
Almacenamos la clave .jks como cadena codificada en base64 en GitHub Secrets y la decodificamos en el flujo de trabajo:
Flujo de trabajo de lanzamiento y producción 🚀
El flujo de trabajo previo al lanzamiento se ejecuta para las ramas que comienzan con release/v. Elimina todo el código de depuración e interno para garantizar que probamos el mismo código que se lanzará.
Además, el flujo de trabajo previo al lanzamiento publica en varios canales de Slack para notificar a los equipos de control de calidad y marketing sobre un nuevo lanzamiento mediante webhooks entrantes.
Después de realizar pruebas exhaustivas, creamos una versión en GitHub que es el desencadenante del flujo de trabajo de producción. Esta versión compila y firma la aplicación con certificados de producción y la envía a la App Store.
Más trucos para tu CI 🦾
Si utiliza el desencadenante push para GitHub Actions, es probable que tenga problemas si se producen varios envíos a la misma rama en rápida sucesión. Se iniciará más de una instancia del flujo de trabajo y consumirá minutos de compilación o causará otros problemas.
- Recomendamos utilizar la acción Cancelar flujo de trabajo para cancelar todas las instancias anteriores del flujo de trabajo.
- Si busca una solución fácil y fácil de mantener para generar números de compilación secuenciales, pruebe el generador de números de compilación. También puede utilizar GITHUB_RUN_ID, pero no se puede personalizar.
- Echa un vistazo a la aplicación ClickUp GitHub para ver las ramas, las confirmaciones y el estado de GitHub directamente en tus tareas de ClickUp. Utiliza ClickUp Automations o la API pública de ClickUp para automatizaciones avanzadas.
Resumen 🍩
Crear su CI es un proceso divertido. Es fácil empezar y puede ir evolucionando a medida que avanza. Nuestra CI se basa en uno de los valores fundamentales de ClickUp: Progreso hacia la perfección. Trabajamos constantemente en la mejora de la CI para nuestros equipos de control de calidad e ingeniería.
La combinación de ClickUp, GitHub Actions y Fastlane es muy potente y permite crear un canal de CI/CD flexible y totalmente automatizado en menos de una hora. ¡Pruébelo!
Tenemos muchos temas interesantes en preparación, así que no deje de visitar el blog de ingeniería de ClickUp.