Githawk: Buddybuild 的替代品？

对于另一个自托管选项，TeamCity(https://www.jetbrains.com/teamcity)？

通常，开源项目的 CircleCI 作业队列比 TravisCI 拥挤得多。

我从管理一些 RxSwiftCommunity 存储库中获得的 0.02 美元。

Travis 绝对是垃圾（或者随着时间的推移已经变成垃圾）。
排队是不能容忍的，并且会减慢开发工作的速度（等待 50 分钟进行 90 年代的构建是不可接受的）并且配置相对烦人。

我们正在缓慢但肯定地将大多数存储库移至 CirlceCI 并且对此非常满意。 排队真的很活泼很公平，配置也比较轻而易举。

在这个意义上也听说过关于 Bitrise 的好消息。

关于 BB 的超级羞耻，关注它很有趣，因为我认为 Apple 不会杀死它 - 但是是的

有使用旧版本 Jenkins 的经验，作为一种工具，它绝对有能力，但需要大量的维护/配置，而且在保持开放和协作的艺术方面，老实说可能不是最好的事情

此外，如果我们选择另一家“大”供应商，我们也会面临同样的风险，即被另一家玩垄断的公司席卷而来

我倾向于尝试 Bitrise，我的 2 美分

我显然有偏见 ;) 但是 App Center 不会发生这样的事情。
如果您有兴趣，请与我们联系。

抄送@帕利亚斯

_{使用GitHawk发送}

https://Buildozer.io支持 iOS 和 Android。 （披露：我是其创始人之一）

我们一直在所有需要 mac 进行 CI 的 Artsy iOS 项目上使用 CircleCI - OSS 队列并不是像 travis 那样的问题

我花了一整天时间试用 Bitrise 和 App Center。 到目前为止，它们看起来并不像 BuddyBuild 那样易于使用和神奇......
我为 BB 团队感到高兴（也为我在温哥华感到自豪）但作为用户非常生气......
BuddyBuild 是那些可以正常工作的服务之一，几乎不需要配置。

我真的很喜欢 Buddybuild 的工作方式。 我之前厌倦了 Circle CI，但这里有一些事情需要注意，它使用 Fastlane 进行签名并部署到试飞，不能使用自动签名。 必须使用“手动”

我安排了一些时间和@TroubleMakerBen聊天，AppCenter _looks_ 真的很好。 要去了解更多关于它并报告！

检查https://buildkite.com/他们为 OSS 提供免费帐户

这里是 bitrise 的忠实粉丝。 我们的解决方案经常使用它

@sregg什么在 App Center 中对您不起作用？ 我很乐意帮助任何构建特定的东西。

@derpixeldan例如，松弛整合是全手动使用网络挂接相比，只是一个BB复选框。 此外，无法从指定编号（即我当前在 BB 上的版本号）开始生成编号。 最后，签署 iOS 应用程序并不像 BB 那样简单（我想我只给了他们我的 Apple id 用户名/密码，他们自动管理证书和配置）

我是 Microsoft App Center Build 的工程经理。 我们有一支优秀的团队，每周都在进行改进，我们致力于提供多平台支持。

@sregg很好的反馈，我认为所有这些领域的改进都在我们的待办事项上。

如有任何问题/关注/反馈，也可以随时在 Twitter 上通过https://twitter.com/0xlukekim向我发送 DM。

我不得不说我对 App Center 印象非常深刻，主要是在“元”意义上：

• 微软正在投入的开发工作。
• 在这里发表评论时，一些员工表现出的主人翁精神和关怀。
• 去年我在 AltConf 上看到了它的实际效果，看起来确实不错。

没有足够的经验，但似乎也是一个有价值的竞争对手:)

大家好，我是来自https://www.bitrise.io （CTO 和联合创始人）的 Viktor。

感谢大家的推荐，这对我们的团队意义重大！

只是想打个招呼 👋 并确保您我们当然会倾听，请随时通过我们的任何支持渠道与我们联系，我也很乐意回答您在此处提出的任何问题！

哈哈，我想我们现在可以开始竞价战了😄

我的 GitHawk 将所有 CI 带到了院子里 🤓

还有https://buddy.works我没用过他们的服务，不好说好不好。 他们肯定有一个很酷的名字;P

我从 BuddyBuild 搬到了 Bitrise（我们真的希望我们的 iOS 和 Android 有一个地方）。 它确实需要阅读一些文档以及一些步骤的 git 存储库，但它进行得非常顺利，在做其他事情的同时花了大约一天的时间。

@sregg 顺便提一下，我们使用“调整 BuildNumber”步骤到 += 640，因为我们将它用于versionCode并且是从 BB 自动部署的。

我发现 Bitrise 与 BuddyBuild 的主要区别（除了 BB 中几乎所有基于 GUI 的东西）是将 Gradle 构建分成多个步骤。 BuddyBuild 会（可能更有效地）构建您要求的所有内容，然后提取相关内容，例如部署电子邮件或发布到 Play 商店，使用 Bitrise，我可以看到您有几个选择：1. 将其拆分为多个 Build/Gradle 步骤，例如 UI/Android 测试，用于您的测试构建 [2x3=6 变体对我们来说]，一个用于您的 App/Play 商店部署工件，之间有一些清理步骤（例如，我将部署文件夹更改为防止电子邮件在过滤器不够用的地方发送出去）...或 2. 熟悉 bash 脚本并有一个脚本步骤来拆分管道映射 ENV 变量，以便在以后的步骤中可以更轻松地使用它们。

如果有更多示例，将 slack 消息设置为包含 BB 默认发送的消息，例如，能够自定义是很好的，但通常我们只想回到编写代码的阶段。

另一个是我们没有使用的功能，测试人员管理（我们使用 Play Store Alpha 和 TestFlight），以及用于崩溃/崩溃记录器的抖动（我们更喜欢 Firebase）。

非常酷的功能之一是不仅能够以 .yml 文件的形式查看和编辑您的工作流，还能够使用 CLI 在本地下载和运行它。

老实说，这比我们习惯的工作要多得多，这就是每月支付的重点，对吗？ 但这几乎是一次性的，好处是额外的可定制性。 总而言之，尽管它做得很好，而且价格合理。 我对这个开关很满意。 我确信 CircleCI 也很好（我们将它用于我们的后端）。

同样值得注意的是，bitrise 的整个基础设施都是 OSS - https://github.com/bitrise-io/bitrise.io

感谢@richardleggett的反馈，我会与团队讨论这个问题！

尤其是 Slack 的 - 我认为现在早就应该在那里有一个“更高级”（更有用）的默认消息，而不是要求您在第一次进入步骤后立即创建“梦想”消息。 灵活性很重要，但默认值/设置体验（和速度）也很重要。 无论如何，您都可以在此之后调整消息，因此使默认设置更详细没有问题。

Gradle：也将与工具团队讨论，感谢您的强调！

我一直在踢这个（慢慢增加我的焦虑）。 想要链接到这篇探索替代方案的

我想在城里花一​​些时间与@orta和@krausefx一起讨论我对自动化这个项目（不仅仅是 CI）的“北极星”愿景。 一旦我集中精力实际工作，我会回来报告。

感谢您对此@rnystrom 的更新。 我能感觉得出你。 😕

@rnystrom感谢您的博客文章，很遗憾听到您在 bitrise 上设置发行版时遇到问题。 不确定您是否看到它，但我们现在已经内置了用于代码签名的自动配置，一旦配置可以自动为您管理 iOS 签名文件： https :

无论如何，只是想对您试用 bitrise 表示感谢，并让您知道我们总是很乐意提供帮助，以防您再次尝试 bitrise。 随意在任何地方 ping 我，例如在我们的 Slack (http://chat.bitrise.io) 上。

@viktorbenei就其价值而言，这不是 Ryan 的博文！

哎呀，我的不好，现在还很早呢😅对不起先生们，谢谢@Sherlouk ！

实际上昨晚开始了Bitrise的工作。 会回来汇报的！

_{使用GitHawk发送}

Bitrise 构建是绿色的！ 就像 BB 一样容易设置。 我认为我们有一个赢家。

_{使用GitHawk发送}

很高兴听到@rnystrom ！ :)

确实，初始设置应该非常顺利，类似于 BB。 主要区别在于之后的配置 UI。 BB 的方法是提供一个简单的 UI，这意味着某些事情可能无法/无法更改，而我们主要关注灵活性，让您可以根据需要指定流程的每个方面（但这附带了一定的复杂性和更陡峭的学习曲线）。 我们知道这个学习曲线可能太多，特别是对于业余爱好项目，我们正在努力改进它； 今年计划了很多事情以使部署等配置更容易;)

https://appcenter.ms似乎很有希望

以透明的名义，这就是我们目前所处的位置：我同时拥有 Bitrise 和 App Center CI 构建 GitHawk。 这两种服务都非常易于使用，所以我想尝试使用这两种服务来交付多个 beta 版本和一个 App Store 版本，记录我的过程。

这是我最初的想法

比特升

优点

• 大力支持 (h/t @viktorbenei)
• 相当快速的构建
• 通过 fastlane 部署
• 构建步骤的极端自定义和粒度
• 平台是开源的（ish）
• 从master自动将构建推送到 ITC（我_爱_这个）

缺点

• 没有开源免费计划（_还_）
• 启动（可能被收购或消失）

应用中心

优点

• 构建速度_非常_快
• 更少的定制 = 更多的精简
• 为 iOS/Android 部署量身定制
• @TroubleMakerBen摇滚😄
• 由微软支持
  
  
  
  • 可能不会很快消失
  
  
  • ++资源
  
  

缺点

• 没有开源免费计划（_还_）
• 需要一个共享目标来构建
• 自动化部署待定（确认即将到来）
• 太多我们不会使用的东西（例如我不需要 App Center SDK）
• 日志输出_非常详细_，很难找到构建错误
• 没有 GitHub 状态集成

感谢分享@rnystrom ！ 只是一个更正，bitrise 的 Web 服务组件不是开源的，因此不可能自托管 API 和 Web UI（还;））。 用于运行配置的所有工具（工作流编辑器、运行器 CLI 等）都是开源的，因此您可以下载构建配置并在您自己的 Mac（或任何 Mac/Linux）上运行它，类似于快车道。

只是一个问题，为了比较

Bitrise：缺点：没有开源免费计划（还）

AppCenter 有开源计划吗？ 可能错过了，AFAIK 他们也没有。 我真的很好奇，因为在 appcenter 的网站上找不到任何相关内容。

没有 GitHub 状态集成

这是一个大☹️

@viktorbenei将更新！ 还没有

_{使用GitHawk发送}

嘿伙计，

感谢反馈和比较。 我喜欢这样，我们的 PM 正在查看此线程。

自动化部署待定（确认即将到来）

我们目前正在努力使分发变得更好。 敬请关注。

AppCenter 有开源计划吗？ 可能错过了，AFAIK 他们也没有。 我真的很好奇，因为在 appcenter 的网站上找不到任何相关内容。

我们还没有 OSS 计划。

祝大家周末愉快！

这现在可能是相关的https://github.com/fastlane/ci 👍

@KrauseFx我看过这个，我很兴奋。

如果我们作为一个社区可以构建它们，为什么要要求功能？ 另外，谷歌支持这个？ 不能要求更多了。

真的很期待在它的进展过程中为此贡献代码，并随着它的成熟将其应用到我们的工作流程中。

感谢你们为社区所做的一切！

@KrauseFx玩家 3 已进入游戏

_{使用GitHawk发送}

哈哈

我认为应用中心不支持每次提交[ci skip]类的语法

@dkhamsing不幸的是（还没有）。

我喜欢 buddybuild 的一个真正优点是，如果FBSnapshotTestCase单元测试产生了意外的图像，它们会在测试结果中显示之前/之后/差异的方式。

有谁知道这些其他系统中是否有类似的功能？

App Center 是否支持从拉取请求构建？ 我很困惑 cc @TroubleMakerBen

@dkhamsing确实如此！

编辑：没关系🙊

_{使用GitHawk发送}

@dkhamsing App Center 支持在 PUSH 上构建，但不支持在 PR 上构建（构建在合并上）。

啊我明白了。 谢谢瑞恩，本 😊

_{使用GitHawk发送}

阅读此线程后，它似乎确实是一场两匹马的竞赛：Bitrise 和 App Center。 然而，没有人触及 UI 测试的主题：我喜欢在 BB 中，只需点击几下，您就可以在虚拟设备上运行 espresso 测试。 正在讨论的两个平台中的任何一个是否支持这一点？

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

_{使用GitHawk发送}

@dkhamsing App Center Test 实际上在物理设备上运行 UI 测试——我们有几千个。 不，你看不到图片;)

我们实际上是在尝试确定一个新的 CI 解决方案。

• AppCenter ：类似于 bb 但不提供 PR 支持，我认为更专注于管理人员，如果任何任务失败，日志也不提供堆栈。

• Bitrise：非常可配置，提供许多开放的“步骤”，如代码覆盖、部署、签名、unitTest、UITest、构建、交付、清理和自定义，因为你有能力配置它，只是对 .yaml 文件有点困惑，你可以触发给定 Push、PR 等的步骤

• Nevercode非常可配置，您可以在每个分支的 gradlew 任务、构建 PR、没有免费计划之间进行选择。

我认为至少Bitrise提供了许多我们可以利用的功能！

从上面发布的关于在 App Center 中测试的链接

1. 回顾核心概念
   了解 Test Cloud 体验的核心概念可提高易用性、导航和与支持的通信。 建议在运行第一次测试之前熟悉这些概念。

到底是什么......我不想回顾任何概念，核心或其他，我只是想让它像在 BB 上一样点击 2 次 :( 我没有 10 个小时的时间来完成这项工作，我是一名编码员，而不是 DevOps 工程师...

是的，可以简化 App Center 文档

_{使用GitHawk发送}

@acristescu

阅读此线程后，它似乎确实是一场两匹马的竞赛：Bitrise 和 App Center。 然而，没有人触及 UI 测试的主题：我喜欢在 BB 中，只需点击几下，您就可以在虚拟设备上运行 espresso 测试。 正在讨论的两个平台中的任何一个是否支持这一点？

不是（还）单击一次，但在几个方面也更强大： https :

我们正在努力使设置更容易（这就是为什么它仍然是“测试版”，而不是因为缺乏功能;)）。

@acristescu @dkhamsing我们知道！ 继续反馈。

@viktorbenei我打算试试，但天哪，这种艺术风格令人

没问题@acristescu ，我绝对明白你的意思，诚实的反馈总是受欢迎的，设计更新已经

我决定用一个简单的 repo ( https://github.com/acristescu/GreenfieldTemplate ) 来尝试它们，看看我能到达哪里。 到目前为止，我已经尝试过 App Center 并遇到了一些问题：

• 解决了（它找不到 gradle 构建工具！），您必须手动将google()存储库添加到您的项目的 gradle
• 它从 1 重新开始构建号，而我已经在 Play 商店发布了 42，谷歌将拒绝构建！）
• 我找不到如何在虚拟设备上免费进行测试，只能在具有 30 天免费试用期的真实设备上进行
• 我不确定它是否运行了单元测试，因为

##[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.

不知道那是什么...

Bitrise：从好的方面来说，设置同样轻松，尽管我认为如果我需要更改任何内容，我需要调出一个 yml 文件并摆弄它（更新：找到了一个叫做工作流编辑器的东西。它看起来很可怕但功能强大） . 障碍：

• 它从不问我要构建哪个变体并选择了错误的变体。 我想要prodRelease但无论出于何种原因，它决定完全构建另外两个mockDebug和prodDebug 。 找不到改变它的地方，但我很确定必须有一个。
• 构建花费了更长的时间，4 分钟而不是应用程序中心的 2 分钟 16 分钟。 这也许是因为上面的问题？
• 在日志中的任何地方都看不到任何提及 junit 测试的内容。 我怀疑它跑了他们。 不明显如何添加它们，也许在工作流编辑器的某个地方？ （更新修补工作流编辑器大约 10 分钟并找到它。奖励积分让我可以自由选择要运行的test目标）
• 不确定它使用了什么构建 ID，我怎么看？

感谢张贴这些

_{使用GitHawk发送}

感谢@acristescu的详细反馈，我们非常感谢。 特别是在应用中心的 JUnit 测试报告文件的警告，这不会影响您的实际测试运行，应该尽快修复。
继续加油！

我花了两个小时，但我设法说服应用中心上传到 google play。 但是，我似乎无法说服它自动执行此操作，我必须从应用中心下载已签名的 APK，然后将其上传回部署/存储部分 (!) 以使其工作。 看起来非常令人费解，我做错了什么？

PS：雪上加霜的是，BuddyBuild 在同一时间跨度内部署了多次，因为我一开始忘记禁用它，它会在没有任何人工干预的情况下自动运行......

嗨@acristescu ，

回复： https :

它从不问我要构建哪个变体并选择了错误的变体。 我想要 prodRelease，但无论出于何种原因，它决定完全构建另外两个 mockDebug 和 prodDebug。 找不到改变它的地方，但我很确定必须有一个。

事实上，我们当前的扫描器将添加一个 Gradle Runner 步骤，为基本工作流配置assembleDebug 。 我们意识到这可能不够简单，但简而言之，如果您想构建prodRelease则 gradle 任务是assembleProdRelease 。 如果你想运行 lint 那么 gradle 任务是lint 。 您可以使用 Gradle Runner 步骤完成所有这些操作，实际上 gradle 可以处理多个任务，因此要运行lint然后assembleProdRelease您也可以将其指定为任务： lint assembleProdRelease两者都可以。

我们正在研究新的步骤和新的扫描仪默认配置，这将使这更容易，具有更具体的步骤（例如，运行 gradle lint任务的“Lint”步骤，而不是要求您在“Gradle Runner”步骤）😉

构建花费了更长的时间，4 分钟而不是应用程序中心的 2 分钟 16 分钟。 这也许是因为上面的问题？

确实如此，因为assembleDebug最有可能在您的情况下生成 2 个单独的 APK/变体，而不是单个“ProdRelease”。

在日志中的任何地方都看不到任何提及 junit 测试的内容。 我怀疑它跑了他们。

指定test作为 Gradle Runner 步骤的 gradle 任务输入，这将运行您的测试 - 或者添加Gradle 单元测试步骤，该步骤配置为默认运行该 gradle 任务。

不确定它使用了什么构建 ID，我怎么看？

如果您的意思是我们是否将版本号设置为 bitrise.io 版本号：默认情况下我们不这样做，您可以通过添加更改 Android versionCode 和 versionName步骤来做到这一点，例如。

再次感谢您的反馈，我们正在倾听并已安排改进设置体验的这些要点！ ;)

精彩的讨论。 我一直发现很难找到支持 Carthage 的 BuddyBuild 替代方案。

我查看了 Nevercode，他们只支持 cocoapods。

我相信应用中心支持迦太基。

还有其他人吗？

@jamesone

我认为对你来说最好的选择可能是 Bitrise，他们提供了一个像管道 bitbucket这样的平台，你也可以根据你的需要使用 Steps 进行配置。

实际上我们从 bb 转移到了 bitrise，我们使用的是 Android 和 iOS，一切都很完美！

真棒@cbedoy你对 buddybuild 为你的所有分支提供的可安装构建做了什么？ Bitrise 是否对此有集成或支持？

您可以在推送、创建 PR 或标签时触发工作流（许多 _steps_）。

您也可以安排每个分支的构建。

你应该检查：

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

当您了解 bitrise 的工作原理时，可以根据您的需要创建工作流，即我想要一个工作流，如果有人创建 PR，则只运行 unitTesting，或者我想要一个在 master 被标记时构建和生成 .ipa 的工作流。

Bitrise 类似于 docker 镜像，您可以在其中选择第三方 _steps_ 来运行 unitTest、CodeCoverage 或存档和部署。

了不起的人！ 听起来真的很有趣。 我会调查一下。