Githawk: Alternatives à Buddybuild ?

Créé le 2 janv. 2018  ·  71Commentaires  ·  Source: GitHawkApp/GitHawk

Juste au moment où je me familiarisais avec ça ....

Les plans de démarrage gratuits existants et le développement d'applications Android seront interrompus le 1er mars 2018.

Nous perdrons presque certainement le soutien de ce projet. Il est temps de trouver un nouveau CI. Aucune suggestion?

Je lis cet article qui propose :

J'ai lu sur Buildkite et AppCenter sur Hacker News.

J'envisage également des solutions open source et auto-hébergées afin que quelque chose comme ça ne se reproduise plus :

❔ question

Commentaire le plus utile

Je suis évidemment partial ;) mais quelque chose comme ça n'arrivera pas avec App Center.
Veuillez nous contacter au cas où vous seriez intéressé.

Tous les 71 commentaires

Pour une autre option auto-hébergée, TeamCity(https://www.jetbrains.com/teamcity) ?

Habituellement, la file d'attente de travaux CircleCI pour les projets open source est beaucoup moins encombrée que TravisCI.

Mon 0,02 $ pour la gestion de certains des dépôts RxSwiftCommunity.

Travis est un déchet absolu (ou est devenu au fil du temps).
La file d'attente est intolérable et ralentit les efforts de développement (attendre 50 minutes pour une version des années 90 est inacceptable) et la configuration est relativement ennuyeuse.

Nous déménageons lentement mais sûrement la plupart des dépôts vers CirlceCI et en avons été très satisfaits. La file d'attente est vraiment rapide et juste, et la configuration est relativement facile.

J'ai également entendu de bonnes choses à propos de Bitrise dans ce sens.

Super dommage pour BB, être intéressant de garder un œil dessus car je ne pense pas qu'Apple le tuerait - mais oui

Avait de l'expérience avec une ancienne version de Jenkins, en tant qu'outil, il est certainement capable mais nécessiterait beaucoup de maintenance/configuration et dans l'art de garder les choses aussi ouvertes et collaboratives, ce n'est probablement pas la meilleure chose honnêtement

De plus, si nous choisissons un autre "grand" fournisseur, nous courons le même risque qu'il soit simplement balayé par une autre entreprise jouant au Monopoly.

Je serais enclin à essayer Bitrise, mes 2 cents

Je suis évidemment partial ;) mais quelque chose comme ça n'arrivera pas avec App Center.
Veuillez nous contacter au cas où vous seriez intéressé.

cc @Palleas

Envoyé avec GitHawk

Https://Buildozer.io prend en charge iOS et Android. (divulgation : je suis l'un de ses fondateurs)

Nous avons utilisé CircleCI sur tous les projets Artsy iOS qui nécessitent un mac pour CI - les files d'attente OSS n'ont pas été un problème comme Travis '

J'ai passé toute la journée à essayer Bitrise et App Center. Jusqu'à présent, ils n'ont pas l'air aussi faciles à utiliser et magiques que BuddyBuild l'a fait...
Je suis content pour l'équipe BB (et fier car je suis aussi à Vancouver) mais très énervé en tant qu'utilisateur...
BuddyBuild était l'un de ces services qui fonctionnent, avec presque aucune configuration nécessaire.

J'ai vraiment aimé la façon dont Buddybuild fonctionne. J'ai déjà fatigué Circle CI, mais il y a certaines choses à noter ici, c'est qu'il utilise Fastlane pour la signature et le déploiement sur Test Flight, la signature automatique ne peut pas être utilisée. il faut utiliser "Manuel"

J'ai pris le temps de discuter avec @TroubleMakerBen , AppCenter _looks_ vraiment sympa. Je vais en savoir plus et faire un retour !

Vérifiez https://buildkite.com/ ils offrent un compte gratuit pour OSS

Grand fan de bitrise ici. Nous l'utilisons beaucoup avec notre solution https://www.appaloosa-store.com/

@sregg, qu'est-ce qui ne fonctionnait pas exactement pour vous dans App Center ? Je serais heureux de vous aider pour tout ce qui est spécifique à Build.

@derpixeldan par exemple, l'intégration de Slack est entièrement manuelle à l'aide de webhooks par rapport à une simple case à cocher avec BB. De plus, il n'y a aucun moyen de démarrer un numéro de build à partir d'un numéro spécifié (c'est-à-dire mon numéro de build actuel sur BB). Enfin, la signature de l'application iOS n'a pas semblé aussi simple que celle de BB (je pense que je leur ai seulement donné mon nom d'utilisateur/mot de passe Apple et ils ont géré le certificat et le provisionnement automatiquement)

Je suis le responsable de l'ingénierie chez Microsoft pour App Center Build. Nous avons une excellente équipe qui apporte des améliorations chaque semaine et nous nous engageons à prendre en charge plusieurs plates-formes.

@sregg d' excellents retours et je pense que des améliorations dans tous ces domaines sont dans notre carnet de commandes.

N'hésitez pas également à me contacter par DM sur Twitter à l' adresse https://twitter.com/0xlukekim pour tout problème/préoccupation/rétroaction.

Je dois dire que j'ai été très impressionné par App Center principalement dans le sens "méta" de :

  • Les efforts de développement que Microsoft y consacre.
  • La propriété et l'attention que certains des employés montrent en commentant ici.
  • Je l'ai vu en action dans AltConf l'année dernière et ça avait l'air plutôt sympa.

Je n'ai pas assez d'expérience avec ça, mais ça semble aussi être un digne concurrent :)

Salut à tous, je suis Viktor de https://www.bitrise.io (CTO & Co-fondateur).

Merci à tous pour la recommandation, cela signifie beaucoup pour notre équipe!

Je voulais juste vous dire bonjour et vous assurer que nous sommes bien sûr à l'écoute, n'hésitez pas à nous contacter à tout moment via l'un de nos canaux d'assistance et je suis également heureux de répondre à toutes vos questions ici !

Haha, je pense que nous pouvons commencer la guerre des enchères maintenant 😄

Mon GitHawk amène tous les CI au chantier 🤓

Il y a aussi https://buddy.works Je n'ai pas utilisé leur service, donc difficile de dire s'ils sont bons. Ils ont définitivement un nom sympa ;P

Je suis passé de BuddyBuild à Bitrise (nous voulons vraiment un endroit pour nos iOS et Android). Cela a pris un peu de lecture de la documentation et aussi de certains des dépôts git de l'étape, mais cela s'est plutôt bien passé, a pris environ une journée en plus de faire d'autres choses.

@sregg Juste pour mentionner que nous utilisons l'étape "Ajuster le numéro de construction" à += 640, car nous l'utilisons pour versionCode et nous déployions automatiquement à partir de BB.

Les principales différences que j'ai trouvées avec Bitrise par rapport à BuddyBuild (à part à peu près tout ce qui est basé sur l'interface graphique dans BB) était de diviser la construction de Gradle en plusieurs étapes. BuddyBuild construirait (peut-être plus efficacement) tout ce que vous demanderiez, puis extrairait les éléments pertinents pour, par exemple, les e-mails de déploiement ou la publication sur Play Store, avec Bitrise, vous avez plusieurs choix que je pourrais voir : 1. le diviser en plusieurs étapes de build/gradle, par exemple pour les tests UI/Android, pour vos builds de test [2x3=6 variantes pour nous], une pour vos artefacts de déploiement App/Play Store, avec quelques étapes de nettoyage entre (par exemple, je change le dossier de déploiement après pour empêcher les e-mails de sortir là où les filtres ne suffisent pas)... ou 2. être à l'aise avec le script bash et disposer d'une action de script qui divise les variables ENV de la carte du tuyau afin qu'elles puissent être utilisées plus facilement dans les étapes ultérieures.

Ce serait également bien d'avoir plus d'exemples, en définissant les messages slack pour inclure quelque chose comme ceux que BB a envoyés par défaut, par exemple, c'est bien de pouvoir les personnaliser, mais en général, nous voulons simplement revenir à l'écriture de code.

L'autre serait les fonctionnalités que nous n'utilisions pas, la gestion des testeurs (nous utilisons Play Store Alpha et TestFlight) et le shake pour le crash / crash logger (nous préférons Firebase).

L'une des fonctionnalités vraiment intéressantes est de pouvoir non seulement afficher et modifier votre flux de travail sous forme de fichier .yml, mais également de le télécharger et de l'exécuter localement avec la CLI.

Pour être honnête, c'est beaucoup plus de travail que ce à quoi nous étions habitués, c'est le but de payer mensuellement, non? Mais c'est à peu près une chose unique et le bonus est une personnalisation supplémentaire. Dans l'ensemble, il fait très bien son travail et à un bon prix. Je suis content de cet interrupteur. Je suis sûr que CircleCI est bon aussi (nous l'utilisons pour notre back-end).

Il convient également de noter que toute l'infra de bitrise est OSS - https://github.com/bitrise-io/bitrise.io

Merci @richardleggett pour le retour, j'en discuterai avec l'équipe !

Surtout celui de Slack - je pense qu'il est grand temps d'avoir un message par défaut "plus sophistiqué" (plus utile), au lieu de vous obliger à créer votre message "de rêve" juste après avoir franchi l'étape la première fois. La flexibilité est importante, tout comme la valeur par défaut/l'expérience de configuration (et la vitesse). Vous pouvez de toute façon modifier le message après cela, il n'y a donc aucun problème à rendre la valeur par défaut plus détaillée.

Gradle : en discutera également avec l'équipe d'outillage, merci de l'avoir souligné !

J'ai donné un coup de pied à ce sujet (ce qui augmente lentement mon anxiété). Je voulais créer un lien vers cet article de blog explorant des alternatives au cas où il y aurait plus d'informations.

Je veux passer du temps avec @orta et @krausefx en ville pour discuter de ma vision "d'étoile du nord" pour automatiser ce projet (au-delà de CI). Je ferai un rapport une fois que j'aurai rassemblé l'énergie nécessaire pour travailler sur cela.

Merci pour la mise à jour sur ce @rnystrom. Je vous comprends. ??

@rnystrom merci pour le billet de blog et désolé d'apprendre que vous avez eu des problèmes avec la configuration de la distribution sur bitrise. Je ne sais pas si vous l'avez vu, mais nous avons maintenant intégré le provisionnement automatique pour la signature de code, qui, une fois configuré, peut gérer automatiquement les fichiers de signature iOS pour vous : https://blog.bitrise.io/ios-auto-provision-step

Quoi qu'il en soit, je voulais juste vous remercier d'avoir essayé bitrise, et vous faire savoir que nous sommes toujours heureux de vous aider, au cas où vous essaieriez à nouveau bitrise. N'hésitez pas à me contacter n'importe où, par exemple sur notre Slack (http://chat.bitrise.io).

@viktorbenei Pour ce que ça vaut, ce n'est pas le blog de Ryan !

Aïe, mon mal, il est encore assez tôt le matin ici 😅 Désolé messieurs et merci @Sherlouk !

En fait, j'ai lancé un travail sur Bitrise hier soir. fera rapport !

Envoyé avec GitHawk

La version Bitrise est verte ! Tout aussi facile à installer que BB. Je pense que nous avons un gagnant.

Envoyé avec GitHawk

Heureux d'entendre @rnystrom ! :)

En effet, la configuration initiale devrait être assez fluide, similaire à BB. La principale différence est l'interface utilisateur de configuration après cela. L'approche de BB était de fournir une interface utilisateur simple, ce qui implique que certaines choses pourraient ne pas être possibles / ne peuvent pas être modifiées, tandis que nous nous sommes concentrés principalement sur la flexibilité, pour vous permettre de spécifier chaque aspect du processus si vous le souhaitez (mais cela vient avec un certain complexité et courbe d'apprentissage plus raide). Nous savons que cette courbe d'apprentissage peut être trop longue, en particulier pour les projets de loisirs et nous travaillons à l'améliorer ; pas mal de choses prévues pour cette année pour faciliter le déploiement des configs etc. ;)

https://appcenter.ms semble prometteur

Au nom de la transparence, voici où nous en sommes pour le moment : j'ai à la fois Bitrise et App Center CI construisant GitHawk. Les deux services sont assez faciles à utiliser, je veux donc essayer d'utiliser les deux pour fournir plusieurs versions bêta et une seule version App Store, documentant mon processus.

Voici mes premières réflexions

Bitrise

Avantages

  • Grand soutien (h/t @viktorbenei)
  • Constructions assez rapides
  • Déployer via fastlane
  • Personnalisation et granularité extrêmes des étapes de construction
  • La plate-forme est open source (ish)
  • Transférer automatiquement les builds vers ITC à partir de master (j'adore ça)

Les inconvénients

  • Pas de plan gratuit open source (_yet_)
  • Démarrage (pourrait être acquis ou disparaître)

Centre d'application

Avantages

  • Les builds sont _très_ rapides
  • Moins de personnalisation = plus de rationalisation
  • Adapté au déploiement iOS/Android
  • @TroubleMakerBen déchire 😄
  • Soutenu par Microsoft

    • Ne partira probablement pas de sitôt

    • ++ressources

Les inconvénients

  • Pas de plan gratuit open source (_yet_)
  • Nécessite une cible partagée pour construire
  • Déploiement automatisé à déterminer (confirmé sa venue)
  • Trop de choses que nous n'utiliserons pas (par exemple, je n'ai pas besoin du SDK App Center)
  • La sortie du journal est _très verbeuse_, il est difficile de trouver des erreurs de construction
  • Pas d'intégration du statut GitHub

Merci pour le partage @rnystrom ! Juste une correction, le composant web service de bitrise n'est pas open source, il n'est donc pas possible d'auto-héberger l'API & l'UI web (encore ;)). Tous les outils utilisés pour exécuter la configuration (l'éditeur de workflow, le runner CLI, ...) sont open source, vous pouvez donc télécharger la configuration de construction et l'exécuter sur votre propre Mac (ou sur n'importe quel Mac/Linux), similaire à voie rapide.

Juste une question pour comparer

Bitrise : Inconvénients : Pas de plan gratuit open source (encore)

AppCenter a-t-il un plan open source ? Peut-être l'a-t-il manqué, AFAIK, ils n'en ont pas non plus. Je suis vraiment curieux car je n'ai rien trouvé de lié sur le site Web d'Appcenter.

Pas d'intégration du statut GitHub

C'est un gros ☹️

@viktorbenei mettra à jour ! Pas encore non plus

Envoyé avec GitHawk

Salut les gars,

Merci pour le retour et la comparaison. J'aime ça et nos PMs regardent ce fil.

Déploiement automatisé à déterminer (confirmé sa venue)

Nous travaillons actuellement dur pour améliorer la distribution. Restez à l'écoute.

AppCenter a-t-il un plan open source ? Peut-être l'a-t-il manqué, AFAIK, ils n'en ont pas non plus. Je suis vraiment curieux car je n'ai rien trouvé de lié sur le site Web d'Appcenter.

Nous n'avons pas encore de plan OSS.

Bravo à tous et bon week-end !

Cela pourrait être pertinent maintenant https://github.com/fastlane/ci 👍

@KrauseFx J'ai vu ça et j'en suis tellement ravi.

Pourquoi demander des fonctionnalités si nous, en tant que communauté, pouvons les créer ? De plus, Google soutient cela ? ne pouvait pas demander beaucoup plus.

J'ai vraiment hâte de contribuer au code à mesure qu'il progresse et de l'appliquer à notre flux de travail à mesure qu'il mûrit.

Merci pour tout ce que vous faites pour la communauté !

@KrauseFx player 3 est entré dans le jeu

Envoyé avec GitHawk

lolz

Je ne pense pas que le centre d'applications prend en charge par commit [ci skip] comme la syntaxe

@dkhamsing malheureusement pas (encore).

Un vrai plus pour Buddybuild que j'ai adoré était la façon dont ils affichent avant/après/diffs dans les résultats du test si un test unitaire

Est-ce que quelqu'un sait si l'un de ces autres systèmes a une fonctionnalité similaire?

App Center prend-il en charge la création à partir d'une demande d'extraction ?  Je suis très confus cc @TroubleMakerBen

@dkhamsing c'est le cas !

edit : tant pis 🙊

Envoyé avec GitHawk

@dkhamsing App Center prend en charge la construction sur PUSH, mais pas encore sur PR (construction sur fusion), pour le moment.

Ah, je vois. Merci Ryan, Ben

Envoyé avec GitHawk

Après avoir lu ce fil, cela semble être une course à deux chevaux : Bitrise et App Center. Pourtant, personne n'a abordé le sujet des tests d'interface utilisateur : j'ai adoré la façon dont dans BB, en quelques clics, vous pouviez exécuter des tests d'espresso sur un appareil virtuel. Est-ce que l'une des deux plates-formes en discussion prend en charge cela?

@dkhamsing App Center Test exécute en fait des tests d'interface utilisateur sur des appareils physiques - nous en avons quelques milliers. Non, vous ne pouvez pas voir les photos ;)

Nous essayons en fait d'identifier une nouvelle solution CI.

  • AppCenter : similaire à bb mais ne fournit pas de support de relations publiques, je pense qu'il est plus axé sur les personnes de gestion, de plus les journaux ne fournissent pas de pile en cas d'échec d'une tâche.

  • Bitrise : très configurable, offre de nombreuses « étapes » ouvertes telles que la couverture de code, le déploiement, la signature, le test unitaire, l'UITest, la création, la livraison, le nettoyage et la personnalisation, car vous avez la possibilité de le configurer, vous peut déclencher des étapes données Push, PR, etc.

  • Nevercode Très configurable, vous pouvez choisir entre une tâche progressive par branche, construire des relations publiques, pas de plan gratuit.

Je pense qu'au moins Bitrise offre de nombreuses fonctionnalités que nous pouvons exploiter !

À partir du lien publié ci-dessus à propos des tests dans l'App Center

  1. Revoir les concepts de base
    Comprendre les concepts de base de l'expérience Test Cloud améliore la facilité d'utilisation, la navigation et les communications avec le support. Il est recommandé de se familiariser avec ces concepts avant d'effectuer vos premiers tests.

Que diable... Je ne veux revoir aucun concept, de base ou autre, je veux juste que ça marche en 2 clics comme ça l'a fait sur BB :( Je n'ai pas 10 heures pour m'enfoncer dans ce travail, Je suis un codeur pas un ingénieur devops...

Oui, la documentation de l'App Center pourrait être rationalisée

Envoyé avec GitHawk

@acristescu

Après avoir lu ce fil, cela semble être une course à deux chevaux : Bitrise et App Center. Pourtant, personne n'a abordé le sujet des tests d'interface utilisateur : j'ai adoré la façon dont dans BB, en quelques clics, vous pouviez exécuter des tests d'espresso sur un appareil virtuel. Est-ce que l'une des deux plates-formes en discussion prend en charge cela?

Pas (encore) un simple clic mais aussi plus puissant de plusieurs manières : https://blog.bitrise.io/introducing-solid-and-snappy-virtual-device-testing-for-android

Nous travaillons à rendre la configuration plus facile (c'est pourquoi c'est toujours "beta", pas à cause d'un manque de fonctionnalités ;)).

@acristescu @dkhamsing On est au courant ! Gardez les commentaires à venir.

@viktorbenei Je vais essayer mais oh mon dieu, ce style artistique est rebutant. Je me suis souvenu pourquoi je suis resté loin de Bitrise dans le passé... des nuages ​​souriants s'étreignant ? Des requins avec des lasers attachés à eux ?!? Des boutons verts sur un fond violet éclatant ? Peut-être que je montre simplement mon âge ici, mais comment pourrais-je recommander cet outil à un client qui est... disons... une banque ?

Pas de problème @acristescu , je vois vraiment votre point de vue, les commentaires honnêtes sont toujours les bienvenus et une mise à jour du design est déjà en cours ;)

J'ai décidé de les essayer tous les deux avec un simple repo ( https://github.com/acristescu/GreenfieldTemplate ) et de voir où j'en suis. Jusqu'à présent, j'ai essayé App Center et j'ai rencontré quelques problèmes :

  • résolu (il n'a pas pu trouver les outils de construction de gradle !), vous devez ajouter manuellement le référentiel google() au gradle de votre projet
  • il a redémarré le numéro de build à partir de 1 alors que j'avais déjà sorti sur play store un 42, google va juste rejeter le build !)
  • Je n'ai pas trouvé comment tester gratuitement sur un appareil virtuel, uniquement sur des appareils réels avec un essai gratuit de 30 jours .
  • Je ne suis pas sûr qu'il ait exécuté les tests unitaires parce que
##[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.

Je ne sais pas de quoi il s'agit...

Bitrise: Du côté positif, la configuration était tout aussi indolore, bien que je pense que si je dois changer quoi que ce soit, je dois afficher un fichier yml et le manipuler (mise à jour: j'ai trouvé un élément appelé éditeur de flux de travail. il a l'air effrayant mais puissant) . Accrocs :

  • il ne m'a jamais demandé quelle variante construire et a choisi la mauvaise. Je voulais prodRelease mais pour une raison quelconque, il a décidé de construire exactement les deux autres mockDebug et prodDebug . Je ne trouve pas où changer cela, mais je suis presque sûr qu'il doit y en avoir un.
  • la construction a pris plus de temps, 4 minutes au lieu de 2 minutes 16 pour App Center. C'est peut-être à cause du problème ci-dessus?
  • ne voyez aucune mention de tests junit nulle part dans les journaux. Je doute qu'il les ait dirigés. Pas évident de savoir comment les ajouter, peut-être quelque part dans l'éditeur de workflow ? (la mise à jour a bricolé avec l'éditeur de flux de travail pendant environ 10 minutes et l'a trouvée. Des points bonus pour m'avoir laissé la liberté de choisir quelle cible test exécuter)
  • je ne sais pas quel ID de build il a utilisé, comment puis-je même voir cela?

Merci d'avoir posté ces

Envoyé avec GitHawk

image

Merci @acristescu pour le retour détaillé, nous l'apprécions grandement. Surtout sur l'avertissement pour les fichiers de rapport de test JUnit dans App Center, cela n'affecte pas votre test réel et devrait être corrigé bientôt.
Laisse le venir!

Cela m'a pris deux heures, mais j'ai réussi à convaincre App Center de télécharger sur Google Play. Cependant, je n'arrive pas à le convaincre de le faire automatiquement, j'ai dû télécharger l'APK signé à partir du centre d'applications, puis le télécharger à nouveau dans la section déploiement/magasins (!) Pour le faire fonctionner. Cela semble terriblement alambiqué, qu'est-ce que je fais de mal ?

PS : Pour ajouter l'insulte à la blessure, BuddyBuild s'est déployé plusieurs fois dans le même laps de temps puisque j'ai oublié de le désactiver au début et il fonctionne juste automatiquement sans aucune intervention humaine...

Salut @acristescu ,

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

il ne m'a jamais demandé quelle variante construire et a choisi la mauvaise. Je voulais prodRelease mais pour une raison quelconque, il a décidé de construire exactement les deux autres mockDebug et prodDebug. Je ne trouve pas où changer cela, mais je suis presque sûr qu'il doit y en avoir un.

En effet, notre scanner actuel ajoutera une étape Gradle Runner, avec assembleDebug configuré pour le workflow de base. Nous réalisons que cela n'est peut-être pas assez simple, mais en bref, si vous voulez construire prodRelease la tâche de gradle est assembleProdRelease . Si vous souhaitez exécuter lint, la tâche de gradle est lint . Vous pouvez faire tout cela avec l'étape Gradle Runner, en fait, gradle peut gérer plusieurs tâches, donc pour exécuter lint puis assembleProdRelease vous pouvez également spécifier ceci comme tâche : lint assembleProdRelease qui fera les deux.

Nous travaillons sur de nouvelles étapes et de nouvelles configurations par défaut du scanner qui faciliteront cela, avec des étapes plus spécifiques (par exemple une étape "Lint" qui exécute la tâche gradle lint , au lieu de vous obliger à définir cette tâche dans l'étape "Gradle Runner") 😉

la construction a pris plus de temps, 4 minutes au lieu de 2 minutes 16 pour App Center. C'est peut-être à cause du problème ci-dessus?

En effet, cela semble être le cas, car assembleDebug génère très probablement 2 APK / variantes distincts dans votre cas au lieu du seul "ProdRelease".

ne voyez aucune mention de tests junit nulle part dans les journaux. Je doute qu'il les ait dirigés.

Spécifiez test comme entrée de tâche graduelle de l'étape Gradle Runner, qui exécutera vos tests - ou ajoutez l'étape de test unitaire Gradle qui est configurée pour exécuter cette tâche graduelle par défaut.

je ne sais pas quel ID de build il a utilisé, comment puis-je même voir cela?

Si vous voulez dire si nous définissons le numéro de build sur le numéro de build bitrise.io : par défaut, nous ne le faisons pas, vous pouvez le faire en ajoutant l'étape Change Android versionCode et versionName par exemple.

Merci encore pour vos retours, nous sommes à l'écoute et déjà programmés pour améliorer ces points de l'expérience de configuration ! ;)

Super débat. J'ai eu du mal à trouver une alternative à BuddyBuild qui prend en charge Carthage.

J'ai regardé dans Nevercode, ils ne supportent que les cocopodes.

Je pense que l'App Center prend en charge Carthage.

D'autres ?

@jamesone

Je pense que la meilleure option pour vous pourrait être Bitrise, ils fournissent une plate-forme comme les pipelines bitbucket , vous pouvez également configurer en fonction de vos besoins en utilisant Steps.

En fait on est passé de bb à bitrise, on utilise Android et iOS et tout est parfait !

Génial @cbedoy Qu'avez-vous fait à propos des versions installables fournies par buddybuild pour toutes vos branches ? Bitrise a-t-il une intégration OU un support pour cela ?

Vous pouvez déclencher des workflows (de nombreuses _étapes_) lorsque vous poussez, créez un PR ou un tag.

Vous pouvez également planifier des builds par branche.

Vous devez vérifier :

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

Lorsque vous comprenez le fonctionnement de bitrise, vous pouvez créer des flux de travail en fonction de vos besoins, c'est-à-dire que je veux un flux de travail où il suffit d'exécuter unitTesting si quelqu'un crée un PR ou je veux un flux de travail où construire et générer le .ipa lorsque le maître a été balisé.

Bitrise est quelque chose comme des images docker où vous pouvez choisir des _étapes_ tierces pour exécuter unitTest, CodeCoverage ou Archive et déployer.

Homme merveilleux! Cela semble vraiment intéressant. Je vais me renseigner.

Cette page vous a été utile?
0 / 5 - 0 notes