从头开始开发gis
This story guide you to implement the CI/CD cloud service in less than one hour. CI/CD is one of the best practices for mobile development teams to implement:
这个故事指导您在不到一小时的时间内实现CI / CD云服务。 CI / CD是移动开发团队要实现的最佳实践之一：
It is also an agile methodology best practice, as it enables mobile development team to focus on meeting business requirements, code quality, and security because other tasks are automated.
这也是一种敏捷方法论的最佳实践，因为它使移动开发团队能够专注于满足业务需求，代码质量和安全性，因为其他任务是自动化的。
In this tutorial, I would like to introduce Bitrise. Bitrise is a leading CI/CD cloud platform for mobile. The setup of workflows using in this platform is easy and intuitive. As a mobile developer, we can setup some basic workflows in just a few hours. In this story, you will be presented how to setup a typical workflow: merge check for a Pull Request. The main objective of this workflow is to validate the pull request created by a developer in our team, before merging it in development branch. This example workflow will run all tests (UI tests, unit tests, …) enabled in the project’s test target.
在本教程中，我想介绍Bitrise 。 Bitrise是领先的CI / CD移动云平台。 在此平台上使用的工作流程的设置既简单又直观。 作为移动开发人员，我们可以在几个小时内设置一些基本的工作流程。 在这个故事中，将向您介绍如何设置典型的工作流程：合并请求的合并检查。 此工作流程的主要目的是在合并到开发分支之前，验证我们团队中的开发人员创建的拉取请求。 此示例工作流将运行项目测试目标中启用的所有测试(UI测试，单元测试等)。
Prerequisites: in this tutorial, I assume that you already had a Bitrise’s account and was given all necessary permissions to create and modify a Bitrise’s app. If you don’t have an account, you can create one for free. A Bitrise’s app can be quickly created from Dashboard -> Add new app -> then follow the guide to connect your repo to the app. Though this tutorial’s objective is to merge check an iOS build, it’s still relevant for Android developers to look at and learn the set up process.
先决条件：在本教程中，我假设您已经拥有一个Bitrise的帐户，并且已获得创建和修改Bitrise的应用程序的所有必要权限。 如果您没有帐户，则可以免费创建一个帐户。 可以从仪表板->添加新应用->快速创建一个Bitrise的应用，然后按照指南将您的仓库连接到该应用。 尽管本教程的目的是合并检查iOS版本，但对于Android开发人员来说，了解并了解设置过程仍然很重要。
设置Bitrise应用 (Setup Bitrise app)
To create this merge-check workflow, firstly go to the app dashboard, then click on workflow tab to open Workflow manager.
要创建此合并检查工作流，请首先转到应用程序仪表板，然后单击“工作流”选项卡以打开“工作流管理器”。
You will see workflow manager displayed like below:
您将看到工作流管理器显示如下：
On the first row, it displays all configurations needed for an iOS build:
在第一行中，它显示iOS构建所需的所有配置：
- Workflows: this is where we can see and manage all workflows. On the second line, there are options we can use to switch, create, add existing, and rearrange workflows. When we created this app, by default, Bitrise provide us a “primary” workflow, which is used to archive iOS apps. Now, click on “+ Workflow” and give it a name (in this tutorial I will use “DemoWorkflow”) by cloning the “primary”. We now have our first baby workflow. For the sake of our tutorial, we remove all preset steps, so we can created them from scratch. 工作流程：在这里我们可以查看和管理所有工作流程。 在第二行中，我们可以使用一些选项来切换，创建，添加现有的和重新安排工作流程。 当我们创建此应用程序时，默认情况下，Bitrise为我们提供了一个“主要”工作流程，用于存档iOS应用程序。 现在，单击“ + Workflow”并通过克隆“ primary”为其命名(在本教程中，我将使用“ DemoWorkflow”)。 现在，我们有了第一个婴儿工作流程。 为了我们的教程，我们删除了所有预设步骤，因此我们可以从头开始创建它们。
- Code Signing: this is where we can safely keep certificates and provisioning profiles. At the top of this tab, we will see the guide about using a script to export our local certificates and provisioning profiles on Bitrise. In this tutorial, we don’t need to setup them, since the tests will run only on simulator. Later, when we need to archive the build to export it to Beta tools or App Store, we definitely need to setup this. 代码签名：在这里我们可以安全地保存证书和配置文件。 在此选项卡的顶部，我们将看到有关使用脚本在Bitrise上导出本地证书和供应配置文件的指南。 在本教程中，我们不需要设置它们，因为测试仅在模拟器上运行。 稍后，当我们需要存档构建以将其导出到Beta工具或App Store时，我们肯定需要进行设置。
- Secrets and Env Vars: basically theses are stored parameters we need to use in the workflows. “Secrets”, well, mean confidential ones. Parameters saved here will be encrypted and will never be exposed in the logs. Info stored will be displayed as ***** in this section and in the logs. This is typical place to save passwords, token…etc. On the other hand, “Env Vars”, stored regular variables. This is where our stored parameters like: scheme name, project path, app version, …etc. Info stored here are exposed to all of our team members. 秘密和环境变量：基本上，这些是我们需要在工作流程中使用的存储参数。 “机密”是指机密。 保存在此处的参数将被加密，并且永远不会在日志中公开。 在此部分和日志中，存储的信息将显示为*****。 这是保存密码，令牌等的典型位置。 另一方面，“ Env Vars”存储常规变量。 这是我们存储的参数，例如：方案名称，项目路径，应用程序版本等。 此处存储的信息向我们所有团队成员公开。
- Triggers: this is where we create rules on how to trigger a workflow. Bitrise provide 3 ways of triggering: Pull request, Push and Tagging. In this tutorial, we want to tests a pull request, so check the Pull Request tab, click on “+ Add Trigger” and fill the source, destination and workflow, we will get something like this: 触发器：这是我们在其中创建有关如何触发工作流程的规则的地方。 Bitrise提供了三种触发方式：拉取请求，推送和标记。 在本教程中，我们要测试一个拉取请求，因此检查“拉取请求”选项卡，单击“ +添加触发器”并填充源，目标和工作流，我们将得到如下内容：
This config mean when there’s a pull request from any branch, toward branch ‘develop’, it will trigger the workflow ‘DemoWorkflow’. Do ‘Save’ (Cmd + S) now. In addition of this triggers, we can also schedule a workflow at specified time, but it will be presented a bit later.
此配置意味着，当任何分支向分支“ develop”发出拉取请求时，它将触发工作流“ DemoWorkflow”。 立即执行“保存”(Cmd + S)。 除了这些触发器之外，我们还可以在指定的时间安排工作流程，但是稍后会介绍。
5. Stack: this is where we specify Xcode and Mac OS version to run our workflow. Select the correct one for your project.
5.堆栈：这是我们指定Xcode和Mac OS版本以运行我们的工作流的地方。 为您的项目选择正确的。
6. bitrise.yml: this is the configuration file that sum up our whole setup in this Bitrise’s app. We may need to backup this file from time to time, just in case we need to rollback.
6. bitrise.yml：这是一个配置文件，总结了此Bitrise应用程序中的整个设置。 我们可能需要不时备份此文件，以防万一我们需要回滚。
设置合并前工作流程 (Setup Pre-Merge workflow)
Now, it’s time for real work …:] Actually, there’s not much left to do here, we will finish it in 5 minutes. So, let’s switch back to Workflow tab. We will design the flow like this: get the repo, install pod or Carthage if needed, run tests, and that’s it.
现在，是时候进行实际工作了……：]实际上，这里要做的事不多，我们将在5分钟内完成。 因此，让我们切换回“工作流程”选项卡。 我们将像这样设计流程：获取仓库，如果需要，安装pod或Carthage，运行测试，仅此而已。
- Cloning the git repo on the pull request’s branch: if your repo is private, add the step SSH Key (click on the “+” sign, and search for keyword ‘SSH’). This will activate the SSH key you generate when creating this Bitrise’s app. Then we add the step Git Clone repository. Normally, this’s all correct already, since Bitrise is smart enough to pre-fill all the information needed like Git URL, branch name (which is always Source branch) 在请求请求的分支上克隆git repo：如果您的repo是私有的，则添加步骤SSH Key(单击“ +”号，然后搜索关键字“ SSH”)。 这将激活您在创建此Bitrise应用时生成的SSH密钥。 然后，我们添加步骤Git Clone存储库。 通常，这已经完全正确了，因为Bitrise足够聪明，可以预先填写所有需要的信息，例如Git URL，分支名称(始终是Source分支)
2. Depend on the project, you may need to do pod install, or run Carthage. Do add step using keyword ‘Cocoapods’ or ‘Carthage’. Again you may not need to specify anything in the step’s config (in case of Cocoapods, Bitrise will setup pod repo and do pod install by default)
2.根据项目，您可能需要执行Pod安装或运行Carthage。 请使用关键字“ Cocoapods”或“ Carthage”添加步骤。 同样，您可能不需要在步骤的配置中指定任何内容(对于Cocoapods，Bitrise将默认设置pod repo并进行pod安装)
3. Now we have the project setup, we need to run tests. To do so add the step ‘Xcode Test’. In this step we should check if all pre-filled parameters are actually what we want, for example: the scheme, the iDevice to run tests, the iOS version…
3.现在我们有了项目设置，我们需要运行测试。 为此，添加步骤“ Xcode测试”。 在这一步中，我们应该检查所有预先填写的参数是否确实是我们想要的，例如：方案，运行测试的iDevice，iOS版本…
At this point, we’re proud to say our mission was archived. This workflow will tests our app when there’s a pull request toward our develop branch. In effect, we can stop here, save our changes, and make a pull request to see if everything connects correctly together. Our workflow now will look similar to below:
在这一点上，我们很自豪地说我们的任务已经存档。 当对我们的开发分支有拉动请求时，此工作流程将测试我们的应用程序。 实际上，我们可以在此处停止，保存更改，并发出拉取请求，以查看所有内容是否正确连接在一起。 现在，我们的工作流程将类似于以下内容：
It’s worth to mention that some cloud repo, like Bitbucket, integrates Bitrise seamlessly, so we will see a green checkmark once workflow finish successfully:
值得一提的是，某些云存储库(例如Bitbucket)无缝集成了Bitrise，因此一旦工作流成功完成，我们将看到绿色的对号：
Below is two popular extra steps that make our CI/CD fancier ^^
以下是两个受欢迎的额外步骤，这些步骤使我们的CI / CD爱好者们^^
4. Export apps, logs or artifacts: this step will export everything generated by the previous steps: logs, unit tests reports, archives, IPA, dSYM… so we can download it for review. Once implement this, we will get all the stuffs in the Apps & Artifacts tab:
4.导出应用程序，日志或工件：此步骤将导出由先前步骤生成的所有内容：日志，单元测试报告，档案，IPA，dSYM…，以便我们下载以供审核。 实施此步骤后，我们将在“应用程序和工件”选项卡中获取所有内容：
5. Send success/fail message to Slack: we may not want to go check our Bitrise or Git repo from time to time to see if the tests passed. By sending message to our communication tools, we passively and immediately notified workflow’s result. So go search for ‘Slack’ step. This step required our Slack’s Wekhook URL or Slack’s API token, which is sensitive so we should stored them in ‘Secrets’
5.将成功/失败消息发送给Slack：我们可能不希望不时检查Bitrise或Git存储库，以查看测试是否通过。 通过向我们的通信工具发送消息，我们可以被动地立即通知工作流程的结果。 因此，请搜索“松弛”步骤。 这一步需要我们的Slack的Wekhook URL或Slack的API令牌，它们很敏感，因此我们应该将它们存储在“秘密”中
The final workflow now look like this:
现在，最终的工作流程如下所示：
一些有用的提示 (Some helpful tips)
It’s better to use environment variables in our workflow, rather than hard-code ones. When all ENV VARS in one place, it’s easier to review our configurations.
最好在我们的工作流程中使用环境变量 ，而不要硬编码。 当所有ENV VARS放在一个地方时，查看我们的配置会更容易。
Variables should avoid Bitrise prefix: almost all steps in Bitrise generate output variables which have Bitrise prefix. Do not use this prefix help you avoid confuse when reading step’s config and possible conflicts.
变量应避免使用Bitrise前缀 ： Bitrise中的几乎所有步骤都会生成具有Bitrise前缀的输出变量。 不要使用此前缀，以帮助您避免在读取步骤的配置时出现混淆以及可能的冲突。
Create common workflow steps: as you may notices, a workflow can be combined of multiple other workflows. If we intend to create many workflows for different scenarios, we should group the common steps in one workflow. For example, every workflow need firsts steps similar to SSH-> Git clone -> Pod install. So those steps could be set up in a workflow name ‘PreBuild’.
创建通用的工作流程步骤 ：您可能会注意到，一个工作流程可以与多个其他工作流程组合。 如果我们打算为不同的场景创建许多工作流程，则应将一个工作流程归为一组通用步骤。 例如，每个工作流程都需要类似于SSH-> Git clone-> Pod安装的第一步。 因此，可以在工作流名称“ PreBuild”中设置这些步骤。
Use Pull, Push cache steps: Bitrise provide Pull/Push steps, which allow to pull cache builds from previous build, and push the current cache when workflow done. It improve considerably workflow’s build time.
使用“推入，推入”缓存步骤 ：Bitrise提供了“推入/推入”步骤，这些步骤允许从以前的构建中提取缓存构建，并在工作流完成时推入当前缓存。 它大大缩短了工作流程的构建时间。
Use option ‘Run if previous steps failed’: every step has this toggle. Use it when we feel convenient. For example, we don’t need to export apps build if previous step archiving app failed. It helps saving time since we don’t have to spend time in running a step for nothing.
使用选项“如果先前的步骤失败，则运行” ：每个步骤都有此切换。 当我们感到方便时使用它。 例如，如果上一步归档应用失败，则无需导出应用构建。 因为我们不必花时间进行任何步骤，它有助于节省时间。
Enable rolling builds: activate all theses options in App’s Settings. It will cancel all previous builds for Pull Requests/Pushes to the same branch, so we avoid duplicated worked
启用滚动构建 ：激活“应用程序设置”中的所有这些选项。 它将取消所有先前的请求/推送到同一分支的构建，因此我们避免重复工作
Schedule workflow: in addition of trigger on events, we can schedule workflow to run at a specific time. At the app’s dashboard, click on “Start/Schedule a build” -> toggle ON “Schedule this build” and setup the day, time and the workflow we want to run. This feature is mostly use for time consuming tasks, like UI tests, performance tests, TestFlight build delivery. Since it’s time consuming, we don’t want them to run during our workday, because they will create traffic jams without much adding value. We should make our CI/CD works while we sleep ;)
安排工作流程 ：除了触发事件外，我们还可以安排工作流程在特定时间运行。 在应用程序的仪表板上，单击“开始/计划构建”->启用“计划此构建”，然后设置要运行的日期，时间和工作流程。 此功能主要用于耗时的任务，例如UI测试，性能测试，TestFlight构建交付。 由于这很耗时，因此我们不希望它们在工作日内运行，因为它们会造成交通拥堵，而不会增加太多价值。 我们应该在睡觉时使CI / CD起作用;)
然后去哪儿？ (Where to go from here?)
There are still many awesome step features to discover. What we did in this tutorial is just a scratch on the surface of what CI/CD can help us improving our daily performance. Take your time to discover them and try them. That may help you generate some ideas on how to facilitate your daily tasks’s.
仍有许多很棒的步骤功能可供发现。 我们在本教程中所做的只是对CI / CD可以帮助我们改善日常性能的表面上的一个草稿。 花点时间去发现它们，然后尝试一下。 这可能有助于您就如何简化日常任务产生一些想法。
Cloud CI/CD is a great start in enabling automation in our development process. In fact, my team use this tool alone during two first years and it improves a lot our work’s velocity, quality and happiness. But it turns out that CI/CD level up to full power and versatility only when combining with Fastlane. Fastlane is an open source automation app that allows you to write customized tasks, defined your own action’s rules, and sync all our work platforms seamlessly. To name a few:
Cloud CI / CD是在我们的开发过程中实现自动化的一个很好的开始。 实际上，我的团队在最初的头两年中仅使用此工具，它极大地提高了我们工作的速度，质量和幸福感。 但是事实证明，仅当与Fastlane结合使用时，CI / CD才能发挥出全部功能和多功能性。 Fastlane是一个开源自动化应用程序，可让您编写自定义任务，定义自己的操作规则以及无缝同步我们所有的工作平台。 仅举几例：
- Capture screenshots automatically 自动捕获屏幕截图
- Distribute beta builds to multiple Beta testing services (Testflight, Firebase App Distribution, Hockey…) 将Beta版本分发到多个Beta测试服务(Testflight，Firebase应用分发，曲棍球…)
- Publish multiple apps at once with a single command line 使用单个命令行一次发布多个应用
- Automatic code signing for iOS 适用于iOS的自动代码签名
- Update test, build, delivery info on your JIRA ticket 更新您的JIRA票证上的测试，建造，交付信息
- All of these happen while we’re working on something else 所有这些都是在我们进行其他工作时发生的
Basically Fastlane is able to sync with every platform that provide an API, and his abilities is limited only by our imagination ;]
基本上，Fastlane能够与提供API的每个平台同步，并且他的能力仅受我们的想象力限制；]
If you’re interested to know more about Fastlane, this is the part 2 of this tutorial:
如果您想了解有关Fastlane的更多信息，这是本教程的第二部分：
翻译自: https://medium.com/swlh/ci-cd-automation-for-mobile-development-from-scratch-part-1-d2b41705afa9
从头开始开发gis
1374
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
