Githawk: ¿Alternativas a Buddybuild?

Para otra opción autohospedada, TeamCity (https://www.jetbrains.com/teamcity)?

Por lo general, la cola de trabajos de CircleCI para proyectos de código abierto está mucho menos concurrida que TravisCI.

Mis $ 0.02 por administrar algunos de los repositorios de RxSwiftCommunity.

Travis es basura absoluta (o se ha convertido con el tiempo).
La cola es intolerable y ralentiza los esfuerzos de desarrollo (esperar 50 minutos para una compilación de los 90 es inaceptable) y la configuración es relativamente molesta.

Estamos moviendo la mayoría de los repositorios de forma lenta pero segura a CirlceCI y estamos muy contentos con ello. Hacer cola es realmente rápido y justo, y la configuración es relativamente sencilla.

También escuché grandes cosas sobre Bitrise en ese sentido.

Es una lástima lo de BB, sería interesante vigilarlo, ya que no creo que Apple lo mate, pero sí.

Tenía experiencia con una versión anterior de Jenkins, como herramienta es definitivamente capaz, pero requeriría bastante mantenimiento / configuración y en el arte de mantener las cosas abiertas y colaborativas probablemente no sea lo mejor, honestamente.

Además, si buscamos otro proveedor "grande", corremos el mismo riesgo de que otra empresa que juegue al Monopoly se lo lleve.

Me inclinaría a probar Bitrise, mis 2 centavos

Obviamente soy parcial;) pero algo como esto no sucederá con App Center.
Por favor, póngase en contacto en caso de que esté interesado.

cc @Palleas

_{Enviado con GitHawk}

Https://Buildozer.io es compatible con iOS y Android. (divulgación: soy uno de sus fundadores)

Hemos estado usando CircleCI en todos los proyectos de Artsy iOS que requieren una Mac para CI; las colas de OSS no han sido un problema como el de Travis.

Pasé todo el día probando Bitrise y App Center. Hasta ahora, no parecen tan fáciles de usar y mágicos como lo hizo BuddyBuild ...
Estoy feliz por el equipo de BB (y orgulloso porque también estoy en Vancouver) pero muy enojado como usuario ...
BuddyBuild era uno de esos servicios que simplemente funciona, casi sin necesidad de configuración.

Me gustó mucho la forma en que funciona Buddybuild. Ya me cansé de Circle CI antes, pero hay algunas cosas a tener en cuenta aquí: usa Fastlane para firmar y desplegar en vuelo de prueba, la firma automática no se puede usar. tienes que usar "Manual"

Configuré algo de tiempo para charlar con @TroubleMakerBen , AppCenter _ se ve muy bien. ¡Aprenderé más sobre esto e informaré!

Consulte https://buildkite.com/ ofrecen una cuenta gratuita para OSS

Gran fan de bitrise aquí. Lo usamos mucho con nuestra solución https://www.appaloosa-store.com/

@sregg, ¿qué es exactamente lo que no te

@derpixeldan, por ejemplo, la integración de Slack es manual usando webhooks en comparación con solo una casilla de verificación con BB. Además, no hay forma de iniciar un número de compilación a partir de un número específico (es decir, mi número de compilación actual en BB). Finalmente, firmar la aplicación de iOS no parecía tan sencillo como BB (creo que solo les di mi nombre de usuario / contraseña de Apple id y ellos administraron el certificado y el aprovisionamiento automáticamente)

Soy el gerente de ingeniería en Microsoft para App Center Build. Tenemos un gran equipo que realiza mejoras cada semana y estamos comprometidos con el soporte multiplataforma.

@sregg excelentes comentarios y creo que las mejoras en todas esas áreas están en nuestra cartera de pedidos.

También no dude en enviarme un mensaje de texto en Twitter a https://twitter.com/0xlukekim con cualquier problema / inquietud / comentario.

Debo decir que me ha impresionado mucho App Center principalmente en el sentido "meta" de:

• Los esfuerzos de desarrollo que Microsoft está poniendo en ello.
• La propiedad y el cuidado que muestran algunos de los empleados al comentar aquí.
• Lo vi en acción en AltConf el año pasado y me pareció bastante agradable.

No tengo suficiente experiencia con él, pero parece un competidor digno también :)

Hola a todos, soy Viktor de https://www.bitrise.io (CTO y cofundador).

Gracias a todos por la recomendación, ¡significa mucho para nuestro equipo!

Solo quería saludar y asegurarme de que, por supuesto, te escuchamos, no dudes en enviarnos un ping en cualquier momento a través de cualquiera de nuestros canales de soporte y también estaré feliz de responder cualquier pregunta que tengas aquí.

Jaja, creo que podemos comenzar la guerra de ofertas ahora 😄

Mi GitHawk trae todos los IC al patio 🤓

También está https://buddy.works No usé su servicio, por lo que es difícil decir si son buenos. Definitivamente tienen un nombre genial; P

Me mudé de BuddyBuild a Bitrise (realmente queremos un lugar para nuestro iOS y Android). Tomó algo de lectura de los documentos y también algunos de los repositorios de git del paso, pero fue bastante bien, tomó aproximadamente un día junto con otras cosas.

@sregg Solo por mencionar que usamos el paso "Ajustar número de compilación" a + = 640, ya que lo usamos para versionCode y nos estábamos implementando automáticamente desde BB.

Las diferencias clave que encontré con Bitrise sobre BuddyBuild (aparte de que prácticamente todo está basado en GUI en BB) fue dividir la compilación de Gradle en varios pasos. BuddyBuild construiría (posiblemente de manera más eficiente) todo lo que pediría y luego sacaría las cosas relevantes para, por ejemplo, correos electrónicos de implementación o publicar en Play Store, con Bitrise tiene un par de opciones que pude ver: 1. dividirlo en varios pasos de Build / Gradle, por ejemplo, para IU / Pruebas de Android, para sus compilaciones de prueba [2x3 = 6 variantes para nosotros], uno para sus artefactos de implementación de App / Play Store, con algunos pasos de limpieza entre ellos (por ejemplo, cambio la carpeta de implementación después de evitar que los correos electrónicos salgan donde los filtros no son suficientes) ... o 2. sentirse cómodo con el script bash y tener un paso del script que divida las variables ENV del mapa de tuberías para que puedan usarse más fácilmente en pasos posteriores.

También sería bueno tener más ejemplos, configurando los mensajes de holgura para incluir algo como los que BB envió por defecto, por ejemplo, es bueno poder personalizarlos, pero en general solo queremos volver a escribir código.

Las otras serían las funciones que no estábamos usando, la administración de probadores (usamos Play Store Alpha y TestFlight) y agitar para el registrador de fallas / fallas (preferimos Firebase).

Una de las características que es realmente interesante es poder no solo ver y editar su flujo de trabajo como un archivo .yml, sino descargarlo y ejecutarlo localmente con la CLI.

Para ser honesto, es mucho más trabajo del que estábamos acostumbrados, ese es el punto de pagar mensualmente, ¿verdad? Pero es prácticamente algo que se hace una sola vez y la ventaja es la personalización adicional. En general, está funcionando muy bien y por un buen precio. Estoy feliz con este cambio. Estoy seguro de que CircleCI también es bueno (lo usamos para nuestro back-end).

También vale la pena señalar que toda la infraestructura de bitrise es OSS: https://github.com/bitrise-io/bitrise.io

Gracias @richardleggett por los comentarios. ¡Lo discutiré con el equipo!

Especialmente el de Slack: creo que hace mucho tiempo que se debe tener un mensaje predeterminado "más elegante" (más útil) allí, en lugar de requerir que crees tu mensaje de "sueño" justo después de ingresar el paso por primera vez. La flexibilidad es importante, pero también lo es el valor / experiencia de configuración predeterminados (y la velocidad). Puede modificar el mensaje después de eso de todos modos, por lo que no hay problema en hacer que el predeterminado sea más detallado.

Gradle: también lo discutiremos con el equipo de herramientas, ¡gracias por resaltarlo!

He estado pateando la lata con esto (aumentando lentamente mi ansiedad). Quería enlazar a esta publicación de blog que explora alternativas en caso de que haya más información allí.

Quiero pasar un tiempo con @orta y @krausefx mientras

Gracias por la actualización de este @rnystrom. Te siento. 😕

@rnystrom gracias por la publicación del blog y lamento saber que tuvo problemas para configurar la distribución en bitrise. No estoy seguro de si lo vio, pero ahora hemos incorporado el aprovisionamiento automático para la firma de código, que una vez configurado puede administrar los archivos de firma de iOS automáticamente: https://blog.bitrise.io/ios-auto-provision-step

De todos modos, solo quería darte las gracias por probar bitrise y hacerte saber que siempre estamos encantados de ayudarte, en caso de que vuelvas a intentarlo. No dude en enviarme un ping en cualquier lugar, por ejemplo, en nuestro Slack (http://chat.bitrise.io).

@viktorbenei Por lo que vale, ¡esa no es la publicación del blog de Ryan!

Ay, mi mal, todavía es bastante temprano en la mañana aquí 😅 ¡Lo siento caballeros y gracias @Sherlouk !

De hecho, anoche inició un trabajo en Bitrise. ¡Informaré de nuevo!

_{Enviado con GitHawk}

¡La construcción de Bitrise es verde! Tan fácil de configurar como BB. Creo que tenemos un ganador.

_{Enviado con GitHawk}

¡Me alegra escuchar a @rnystrom ! :)

De hecho, la configuración inicial debería ser bastante fluida, similar a BB. La principal diferencia es la interfaz de usuario de configuración después de eso. El enfoque de BB fue proporcionar una interfaz de usuario simple, lo que implica que ciertas cosas podrían no ser posibles / no se pueden cambiar, mientras que nos enfocamos principalmente en la flexibilidad, para permitirle especificar cada aspecto del proceso si lo desea (pero esto viene con un cierto complejidad y curva de aprendizaje más pronunciada). Sabemos que esta curva de aprendizaje puede ser demasiado, especialmente para proyectos de pasatiempos y estamos trabajando para mejorarla; Se han planeado bastantes cosas para este año para facilitar la implementación de configuraciones, etc.;)

https://appcenter.ms parece prometedor

En nombre de la transparencia, aquí es donde estamos en este momento: tengo Bitrise y App Center CI construyendo GitHawk. Ambos servicios son bastante fáciles de usar, así que quiero probar usando ambos para entregar varias compilaciones beta y una sola compilación de la App Store, documentando mi proceso.

Aquí están mis pensamientos iniciales

Bitrise

Pros

• Gran apoyo (h / t @viktorbenei)
• Construcciones bastante rápidas
• Implementar a través de Fastlane
• Personalización extrema y granularidad de los pasos de construcción
• La plataforma es de código abierto (ish)
• Enviar compilaciones automáticamente a ITC desde master (I _love_ this)

Contras

• Sin plan gratuito de código abierto (_yet_)
• Inicio (podría adquirirse o desaparecer)

Centro de Aplicaciones

Pros

• Las compilaciones son _muy_ rápidas
• Menos personalización = más racionalización
• Adaptado para la implementación de iOS / Android
• @TroubleMakerBen rocas 😄
• Respaldado por Microsoft
  
  
  
  • Probablemente no se vaya pronto
  
  
  • ++ recursos
  
  

Contras

• Sin plan gratuito de código abierto (_yet_)
• Requiere un objetivo compartido para construir
• Despliegue automatizado tbd (confirmó su llegada)
• Demasiadas cosas que no usaremos (por ejemplo, no necesito el SDK de App Center)
• La salida del registro es _muy detallada_, es difícil encontrar errores de compilación
• Sin integración de estado de GitHub

¡Gracias por compartir @rnystrom ! Solo una corrección, el componente de servicio web de bitrise no es de código abierto, por lo que no es posible autohospedar la API y la interfaz de usuario web (todavía;)). Todas las herramientas utilizadas para ejecutar la configuración (el editor de flujo de trabajo, la CLI del corredor, ...) son de código abierto, por lo que puede descargar la configuración de compilación y ejecutarla en su propia Mac (o en cualquier Mac / Linux), similar a carril rápido.

Solo una pregunta, por el bien de la comparación

Bitrise: Contras: No hay plan gratuito de código abierto (todavía)

¿AppCenter tiene un plan de código abierto? Podría haberlo perdido, AFAIK, tampoco tienen uno. Tengo mucha curiosidad porque no pude encontrar nada relacionado en el sitio web de appcenter.

Sin integración de estado de GitHub

Eso es un gran ☹️

¡@viktorbenei se actualizará! Tampoco todavía

_{Enviado con GitHawk}

Hey gente,

Gracias por los comentarios y la comparación. Me gusta eso y nuestros PM están viendo este hilo.

Despliegue automatizado tbd (confirmó su llegada)

Actualmente estamos trabajando duro para mejorar la distribución. Manténganse al tanto.

¿AppCenter tiene un plan de código abierto? Podría haberlo perdido, AFAIK, tampoco tienen uno. Tengo mucha curiosidad porque no pude encontrar nada relacionado en el sitio web de appcenter.

Todavía no tenemos un plan de OSS.

¡Saludos a todos y que tengan un buen fin de semana!

Esto podría ser relevante ahora https://github.com/fastlane/ci 👍

@KrauseFx He visto esto y estoy muy feliz por ello.

¿Por qué pedir funciones si nosotros, como comunidad, podemos crearlas? Además, ¿Google respalda esto? No podría pedir mucho más.

Tengo muchas ganas de contribuir con código a esto a medida que avanza y aplicarlo a nuestro flujo de trabajo a medida que madura.

¡Gracias por todo lo que están haciendo por la comunidad!

@KrauseFx El jugador 3 ha entrado en el juego

_{Enviado con GitHawk}

lolz

No creo que el centro de aplicaciones admita por compromiso [ci skip] como sintaxis

@dkhamsing lamentablemente no (todavía).

Una ventaja real de buddybuild que me encantó fue la forma en que se muestran antes / después / diferencias en los resultados de la prueba si una prueba unitaria FBSnapshotTestCase producía una imagen inesperada.

¿Alguien sabe si alguno de estos otros sistemas tiene una característica similar?

¿App Center admite la construcción a partir de una solicitud de extracción? Estoy muy confundido cc @TroubleMakerBen

@dkhamsing lo hace!

editar: no importa 🙊

_{Enviado con GitHawk}

@dkhamsing App Center admite la creación de PUSH, pero no la creación de PR (creación de fusión), todavía.

Ah, ya veo. Gracias Ryan, Ben 😊

_{Enviado con GitHawk}

Después de leer este hilo, parece ser una carrera de dos caballos: Bitrise y App Center. Sin embargo, nadie ha tocado el tema de las pruebas de IU: me encantó cómo en BB, con solo unos pocos clics, se podían ejecutar pruebas de espresso en un dispositivo virtual. ¿Alguna de las dos plataformas en discusión apoya esto?

https://docs.microsoft.com/en-us/appcenter/test-cloud/

_{Enviado con GitHawk}

@dkhamsing App Center Test en realidad ejecuta pruebas de IU en dispositivos físicos; tenemos algunos miles. No, no puedes ver fotos;)

De hecho, estamos tratando de identificar una nueva solución de CI.

• AppCenter : similar a bb pero no proporciona soporte de relaciones públicas, creo que está más enfocado a la gente de gestión, además, los registros no proporcionan una pila si falla alguna tarea.

• Bitrise: muy configurable, ofrece muchos "pasos" abiertos como cobertura de código, implementar, firmar, unitTest, UITest, construir, entregar, limpiar y personalizar, porque tiene la capacidad de configurarlo, acaba de confundirlo un poco con los archivos .yaml, Puede activar pasos dados Push, PR, etc.

• Nevercode Muy configurable, puede seleccionar entre tareas de Gradlew por rama, construir PR, sin plan gratuito.

¡Creo que al menos Bitrise ofrece muchas características que podemos aprovechar!

Desde el enlace publicado arriba sobre las pruebas en App Center

1. Revise los conceptos básicos
   La comprensión de los conceptos básicos de la experiencia de Test Cloud mejora la facilidad de uso, la navegación y las comunicaciones con soporte. Se recomienda familiarizarse con estos conceptos antes de ejecutar sus primeras pruebas.

Qué diablos ... No quiero revisar ningún concepto, básico o de otro tipo, solo quiero que funcione con 2 clics como lo hizo en BB :( No tengo 10 horas para dedicarme a hacer que esto funcione, Soy un codificador, no un ingeniero devops ...

Sí, la documentación del App Center podría simplificarse

_{Enviado con GitHawk}

@acristescu

Después de leer este hilo, parece ser una carrera de dos caballos: Bitrise y App Center. Sin embargo, nadie ha tocado el tema de las pruebas de IU: me encantó cómo en BB, con solo unos pocos clics, se podían ejecutar pruebas de espresso en un dispositivo virtual. ¿Alguna de las dos plataformas en discusión apoya esto?

No es (todavía) un solo clic, pero también es más poderoso en un par de formas: https://blog.bitrise.io/introducing-solid-and-snappy-virtual-device-testing-for-android

Estamos trabajando para facilitar la configuración (por eso sigue siendo "beta", no por falta de funcionalidad;)).

@acristescu @dkhamsing ¡ Somos conscientes! Sigan recibiendo comentarios.

@viktorbenei Voy a intentarlo, pero Dios mío, ese estilo artístico es desagradable. Recordé por qué me alejé de Bitrise en el pasado ... ¿nubes sonrientes abrazándose? ¿Tiburones con láseres atados?!? ¿Botones verdes sobre un fondo violeta vibrante? Quizás solo esté mostrando mi edad aquí, pero ¿cómo podría recomendar esta herramienta a un cliente que es ... digamos ... un banco?

No hay problema @acristescu , definitivamente veo su punto, los comentarios honestos siempre son bienvenidos y ya se está trabajando en una actualización de diseño;)

Decidí probar ambos con un repositorio simple (https://github.com/acristescu/GreenfieldTemplate) y ver dónde llego. Hasta ahora probé App Center y encontré algunos inconvenientes:

• resuelto (¡no pudo encontrar las herramientas de compilación de Gradle!), debe agregar manualmente el repositorio google() al gradle de su proyecto
• reinició el número de compilación desde 1 mientras que ya lancé en Play Store un 42, ¡Google simplemente rechazará la compilación!)
• No pude encontrar cómo realizar la prueba en un dispositivo virtual de forma gratuita, solo en dispositivos reales con una prueba gratuita de 30 días.
• No estoy seguro de que ejecutó las pruebas unitarias porque

##[warning]No test result files matching /Users/vsts/agent/2.127.0/work/1/s/**/build/test-results/TEST-*.xml were found, so publishing JUnit test results is being skipped.

No estoy seguro de qué va eso ...

Bitrise: en el lado positivo, la configuración fue igual de sencilla, aunque creo que si necesito cambiar algo, necesito abrir un archivo yml y jugar con él (actualización: encontré una cosa llamada editor de flujo de trabajo. Parece aterrador pero poderoso) . Enganches:

• nunca me preguntó qué variante construir y eligió la incorrecta. Quería prodRelease pero por alguna razón decidió construir exactamente los otros dos mockDebug y prodDebug . No puedo encontrar dónde cambiar eso, pero estoy bastante seguro de que debe haber uno.
• la construcción tomó más tiempo, 4 minutos en lugar de 2 minutos 16 para el centro de aplicaciones. ¿Esto se debe quizás al problema anterior?
• no veo ninguna mención de pruebas junit en ningún lugar de los registros. Dudo que los haya corrido. ¿No es obvio cómo agregarlos, tal vez en algún lugar del editor de flujo de trabajo? (Actualización modificada con el Editor de flujo de trabajo durante aproximadamente 10 minutos y lo encontré. Puntos de bonificación por permitirme la libertad de elegir qué test objetivo ejecutar)
• No estoy seguro de qué ID de compilación usó, ¿cómo puedo ver eso?

Gracias por publicar estos

_{Enviado con GitHawk}

Gracias @acristescu por los comentarios detallados, lo apreciamos mucho. Especialmente en la advertencia para los archivos de informe de prueba de JUnit en App Center, esto no afecta su ejecución de prueba real y debería solucionarse pronto.
¡Sigue viniendo!

Me tomó dos horas, pero logré convencer al centro de aplicaciones para que subiera a Google Play. Sin embargo, parece que no puedo convencerlo de que haga esto automáticamente, tuve que descargar el APK firmado desde el centro de aplicaciones y luego volver a cargarlo en la sección de implementación / tiendas (!) Para que funcione. Parece terriblemente complicado, ¿qué estoy haciendo mal?

PD: Para colmo de males, BuddyBuild se implementó varias veces en el mismo período de tiempo ya que olvidé deshabilitarlo al principio y simplemente funciona automáticamente sin ninguna intervención humana ...

Hola @acristescu ,

Re: https://github.com/rnystrom/GitHawk/issues/1330#issuecomment -368228417

nunca me preguntó qué variante construir y eligió la incorrecta. Quería prodRelease pero por alguna razón decidió construir exactamente los otros dos mockDebug y prodDebug. No puedo encontrar dónde cambiar eso, pero estoy bastante seguro de que debe haber uno.

De hecho, nuestro escáner actual agregará un paso de Gradle Runner, con assembleDebug configurado para el flujo de trabajo base. Nos damos cuenta de que esto puede no ser lo suficientemente sencillo, pero en resumen, si desea compilar prodRelease , la tarea de Gradle es assembleProdRelease . Si desea ejecutar lint, la tarea de Gradle es lint . Puede hacer todo esto con el paso de Gradle Runner, de hecho, gradle puede manejar varias tareas, por lo que para ejecutar lint y luego assembleProdRelease también puede especificar esto como la tarea: lint assembleProdRelease que hará ambas cosas.

Estamos trabajando en nuevos pasos y nuevas configuraciones predeterminadas del escáner que harán esto más fácil, con pasos más específicos (por ejemplo, un paso "Lint" que ejecuta la tarea gradle lint , en lugar de requerir que establezca esa tarea en el paso "Gradle Runner") 😉

la construcción tomó más tiempo, 4 minutos en lugar de 2 minutos 16 para el centro de aplicaciones. ¿Esto se debe quizás al problema anterior?

De hecho, ese parece ser el caso, ya que assembleDebug probablemente genere 2 APK / variantes separados en su caso en lugar del único "ProdRelease".

no veo ninguna mención de pruebas junit en ningún lugar de los registros. Dudo que los haya corrido.

Especifique test como la entrada de la tarea de Gradle del paso de Gradle Runner, que ejecutará sus pruebas, o agregue el paso de Prueba de unidad de Gradle que está configurado para ejecutar esa tarea de Gradle de forma predeterminada.

No estoy seguro de qué ID de compilación usó, ¿cómo puedo ver eso?

Si quiere decir si establecemos el número de compilación en el número de compilación de bitrise.io: por defecto no lo hacemos, puede hacerlo agregando el paso Cambiar versión de Android y nombre de versión, por ejemplo.

Gracias nuevamente por sus comentarios, ¡estamos escuchando y ya programamos mejorar estos puntos de la experiencia de configuración! ;)

Discusión impresionante. Me ha resultado difícil encontrar una alternativa de BuddyBuild que sea compatible con Carthage.

Miré Nevercode, solo admiten cocoapods.

Creo que el centro de aplicaciones es compatible con Carthage.

¿Cualquier otro?

@jamesone

Creo que la mejor opción para ti podría ser Bitrise, proporcionan una plataforma como bitbucket pipelines , también puedes configurar según tus necesidades usando Steps.

De hecho, pasamos de bb a bitrise, estamos usando Android e iOS y ¡todo es perfecto!

Awesome @cbedoy ¿Qué hiciste con las compilaciones instalables que buddybuild proporciona para todas tus sucursales? ¿Bitrise tiene una integración O soporte para esto?

Puede desencadenar flujos de trabajo (muchos _pasos_) cuando presiona, crea un PR o una etiqueta.

También puede programar construcciones por sucursal.

Deberías comprobar:

https://devcenter.bitrise.io/bitrise-cli/workflows/
https://devcenter.bitrise.io/bitrise-cli/steps/

Cuando entienda cómo funciona bitrise, puede crear flujos de trabajo basados ​​en lo que necesita, es decir, quiero un flujo de trabajo en el que solo ejecute unitTesting si alguien crea un PR o quiero un flujo de trabajo donde se construya y genere el .ipa cuando se etiquetó el maestro.

Bitrise es algo así como imágenes de ventana acoplable donde puede elegir _pasos_ de terceros para ejecutar unitTest, CodeCoverage o Archive and deploy.

¡Hombre asombroso! Suena realmente interesante. Lo miraré.