微软 appcenter
AppCenter is one of Microsoft's offerings if you need a Continuous Integration (CI) solution for mobile apps. While Fastlane can probably be called the “industry standard” for mobile app CI software, AppCenter fills a certain niche which makes it a good option for certain use cases.
如果您需要针对移动应用程序的持续集成(CI)解决方案，则AppCenter是Microsoft的产品之一。 虽然Fastlane可能被称为移动应用程序CI软件的“行业标准”，但AppCenter占据了一定的位置，这使其成为某些用例的不错选择。
Fastlane is definitely a much more complete tool-belt than AppCenter. But, in order to qualify as being used in “CI”, it has to run somewhere other than locally on your computer. This means you have to configure both Fastlane, and an on-premise box or remote cloud infrastructure where it can run.
Fastlane绝对比AppCenter更完整。 但是，为了符合在“ CI”中使用的条件，它必须在计算机本地以外的其他位置运行。 这意味着您必须同时配置Fastlane以及可以运行它的本地盒或远程云基础架构。
I like Fastlane and all of its bells, whistles and warts. But for beginners, and developers who want to do CI securely¹, Fastlane is quite a bit more complicated than AppCenter.
我喜欢Fastlane及其所有的钟声，口哨声和疣。 但是对于想要安全地执行CI的初学者和开发人员来说，Fastlane比AppCenter复杂得多。
Compare it to AppCenter, where you pretty much only have to do two things in order to get started:
将其与AppCenter进行比较，您几乎只需要做两件事即可上手：
- Create and choose the app type in the AppCenter dashboard 在AppCenter仪表板中创建并选择应用程序类型
- Connect the app in AppCenter to your git repository 将AppCenter中的应用程序连接到您的git存储库
After that you can create a build configuration which already has sane defaults. Things like incrementing the build number, environment secrets and signing the build “just works”. The app will build on new commits, and you have a functioning CI in place.
之后，您可以创建已经具有默认值的构建配置。 诸如增加内部版本号，环境秘密和对内部版本进行签名等工作就可以了。 该应用程序将基于新的提交，并且您具有有效的CI。
AppCenter利基市场 (AppCenters niche)
This is AppCenters niche. The ease and speed when getting started. This is true for setting up builds, and for many other features like testing or distribution. I’ve used AppCenter in multiple projects for different clients, where we needed to start building and distributing the app from day one.
这是AppCenter的利基市场。 入门时的便捷性和速度。 这对于设置构建以及其他许多功能(例如测试或分发)都是正确的。 我已经在针对不同客户的多个项目中使用了AppCenter，从第一天开始我们就需要开始构建和分发该应用程序。
Through the distribution channels, you have multiple ways of getting the app to early users. You can distribute the app directly to test groups within AppCenter. This means you don’t need to connect to the official channels, like TestFlight or Google Play. Which is a benefit since those channels have unpredictable review times the first time you submit the app. But you also have the option to distribute to different groups on those beta channels, or directly to the official store.
通过发行渠道，您可以通过多种方式将应用程序吸引到早期用户。 您可以将应用程序直接分发到AppCenter中的测试组。 这意味着您无需连接到TestFlight或Google Play等官方频道。 这是一个好处，因为这些通道在您首次提交应用程序时具有不可预测的审核时间。 但是您也可以选择在这些Beta频道上分发给不同的小组，或直接分发到官方商店。
AppCenter also has a generous free plan, with (at the time of this writing) 240 build minutes each month per app, and unlimited distributions. A lot of the time, that’s all you’re going to need.
AppCenter还提供了一个免费的免费计划，在撰写本文时，每个应用每月有240分钟的构建时间，并且发行量不受限制。 很多时候，这就是您所需要的。
I would argue that AppCenter is likely the best solution for hobby projects, smaller teams, or even larger projects which doesn’t update frequently. And for some of those that do need to build often, the pricing is quite fair for unlimited builds.
我认为AppCenter可能是不经常更新的业余项目，小型团队甚至大型项目的最佳解决方案。 对于某些确实需要经常建造的建筑来说，无限建造的价格是相当合理的。
超越利基市场 (Growing beyond the niche)
I find that an often occurring cliche in development, is that tools which are easy to use, are also usually difficult to configure exactly how you want them. The same is true for AppCenter. Unless you follow the happy path, you will likely not stay happy.
我发现开发中经常出现的陈词滥调是，易于使用的工具通常也很难准确配置所需的工具。 AppCenter也是如此。 除非您遵循幸福的道路，否则您可能不会保持幸福。
As you scale any project up, the needs from your CI solution usually becomes more complex depending on the team members, cooperation between them, and the release processes. This is something our team also noticed recently while working on a new React Native-app for AtB, where we used AppCenter to get rolling quickly.
当您扩展任何项目时，CI解决方案的需求通常会变得更加复杂，这取决于团队成员，他们之间的合作以及发布过程。 这是我们团队最近在为AtB开发新的React Native应用程序时注意到的 ，我们使用AppCenter来快速滚动。
The problems started small, like wanting to generate app icons in the required sizes when building in our CI. While Fastlane supports this directly with a simple plugin, AppCenter only supports this indirectly through build scripts where you can script those tasks. Still, it’s just a simple script right? We quickly fixed that, and moved on.
问题开始时很小，就像想要在我们的CI中构建所需尺寸的应用程序图标一样。 虽然Fastlane通过一个简单的插件直接支持此功能，但是AppCenter仅通过构建脚本间接支持此功能，您可以在其中编写这些任务的脚本。 不过，这只是一个简单的脚本吧？ 我们很快解决了这个问题，然后继续进行。
Then bigger hurdles started showing up. For example, the team wanted different build configurations for our QA-builds and release-builds. The issue is that AppCenter build configs are linked to git branches — one branch equals one build config. You cannot have multiple build configs per branch. We solved this by having a dedicated branch for our release-builds, and more routines and processes for releases. But these are just band aids to compensate for a lack of functionality in AppCenter. And it’s unnecessary extra work at that.
然后更大的障碍开始出现。 例如，团队希望我们的QA构建和发行构建使用不同的构建配置。 问题是，AppCenter构建配置链接到git分支-一个分支等于一个构建配置。 每个分支不能有多个构建配置。 我们通过为发布版本建立专用分支以及更多的发布例程和流程来解决此问题。 但是，这些仅仅是创可贴，可以弥补AppCenter中功能的不足。 这是不必要的额外工作。
While AppCenter has been good to us in an early phase of development, we see that we’re growing beyond the niche.
尽管AppCenter在开发的早期阶段对我们有利，但我们看到我们正在超越特定领域。
其他限制 (Other limitations)
There are other limitations as well that we’d love to see AppCenter do something about.
我们也希望看到AppCenter可以做一些其他的事情。
Like with multiple build configs per branch, another thing we’d love to have is builds on pull requests and git tags. Our team uses pull requests (PR) and reviews for all new commits, and having the ability to build PRs before a merge would be very nice². We also tag all releases, and having the ability to build those automatically would simplify our release process. In many other CIs you can setup git branch filters, which can make builds flexible. What if you want a feature-branch build with its own dedicated distribution channel? These things would be a powerful feature in AppCenter, specifically because of its distribution solution.
就像每个分支具有多个构建配置一样，我们希望拥有的另一件事是在pull request和git tags上构建 。 我们的团队对所有新提交使用请求请求(PR)和审阅，并且能够在合并之前构建PR会非常好²。 我们还会标记所有发行版，并且能够自动构建这些发行版将简化我们的发行过程。 在许多其他配置项中，您可以设置git分支过滤器，以使构建更加灵活。 如果您想要具有自己专用发行渠道的功能分支构建，该怎么办？ 这些事情在AppCenter中将是一项强大的功能，特别是由于其分发解决方案。
Another issue with AppCenter is the manual process when handling certificates and provisioning profiles. If you want to do this securely, you should not include those files in your git repository along with the code. But the only secure option on AppCenter is manually uploading these files. If AppCenter had something like fastlane match, which was available to team members, and could automatically recreate expired or revoked certificates, that would be a huge improvement.
AppCenter的另一个问题是处理证书和配置文件时的手动过程 。 如果要安全地执行此操作，则不应将这些文件与代码一起包括在git存储库中。 但是AppCenter上唯一安全的选项是手动上传这些文件。 如果AppCenter拥有类似fastlane match的东西，可供团队成员使用，并且可以自动重新创建已过期或已撤销的证书，那将是一个巨大的改进。
Other minor stuff, like automatically downloading bitcode dSYMs from Apple, or breadcrumb logging for AppCenter Diagnostics would be welcome as well. These are minor things, but stuff which works in Fastlane and other solutions. Anecdotally, we’ve also noticed that the builds on AppCenter have intermittently been unstable and slow, and have hampered our speed at times. But that might just be bad luck on our part.
其他较小的东西，例如从Apple自动下载位码dSYM或AppCenter Diagnostics的面包屑日志记录，也将受到欢迎。 这些是次要的事情，但是可以在Fastlane和其他解决方案中使用的东西。 有趣的是，我们还注意到AppCenter上的构建间歇性地不稳定且缓慢，有时会阻碍我们的速度。 但这可能只是我们的运气不好。
不是最后的告别 (Not a final goodbye)
All in all, we are currently looking at other options for our mobile app CI needs.
总而言之，我们目前正在寻找满足移动应用程序CI需求的其他选项。
But this is not a final goodbye. I will continue to use AppCenter for other apps where the scope of the project, and the needs of the team are met. Our team will also likely continue to use AppCenter for QA distribution as well, which works great, and for CodePush if we decide to move in that direction with our React Native-app.
但这不是最终的告别。 我将继续将AppCenter用于满足项目范围和团队需求的其他应用程序。 如果我们决定使用React Native-app朝这个方向发展，我们的团队也可能会继续使用AppCenter进行质量检查分发，这非常有用 ，对于CodePush也是如此。
Hopefully AppCenter will continue to improve, as times goes, because I really love how easy it is to get started. I just wish the tool-belt was more on par with Fastlane and other CIs — and that you could configure or extend different parts of the pipeline when you get past the early phase of an app. That would make it easier to grow projects within AppCenter.
希望随着时间的流逝，AppCenter将会继续改进，因为我真的很喜欢入门非常容易。 我只是希望工具带能够与Fastlane和其他CI保持同等水平，并且希望当您超出应用程序的早期阶段时，可以配置或扩展管道的不同部分。 这将使在AppCenter中扩展项目变得更加容易。
—
-
¹ Like handling certificates, environment variables and distribution securely² There are security concerns with building PRs in CI. If you build a PR from a forked repository, they could potentially expose secrets through modified build scripts. Although this could be mitigated by only allowing building PRs from the main repository.
¹像安全地处理证书，环境变量和分发一样²在CI中构建PR时存在安全隐患。 如果您从派生的存储库中构建PR，则它们可能会通过修改后的构建脚本公开秘密。 尽管仅允许从主存储库构建PR可以缓解这种情况。
翻译自: https://medium.com/variant-as/mobile-app-ci-with-appcenter-good-but-could-be-better-7c7eb515dcea
微软 appcenter