1. 初识DevCloud与CodeHub为什么移动端团队要重构代码托管链路我们团队之前一直用自建Git服务器托管代码服务器放在某办公楼的机房里平时用着还行一旦遇到网络抖动或者机房断电整个团队的提交和拉取就全卡住了。最难受的是iOS和Android两个端的同学要用不同的工具链代码托管和构建环境割裂得很厉害每次发版都要人工协调半天。后来我们立项做一款新的移动端管理App决定把代码托管和云端构建整体迁到华为云DevCloud上核心的代码仓库放到CodeHub。这件事看起来只是把Git仓库换个地方放实际操作下来牵扯到的东西比我预想的多得多SSH密钥怎么配、iOS和Android两端如何共用一套托管策略、本地环境怎么和云端构建机对齐、CI/CD流水线怎么串联起来。这篇就是整个系列的第一篇专门讲Git连接CodeHub以及iOS、Android的本地和云端开发环境怎么一步步搭起来。如果你正准备把移动端项目迁到华为云或者刚开始用DevCloud和CodeHub这篇应该能帮你省不少时间。我个人的体会是迁移最怕的不是技术难度而是两边环境不一致。本地是本地云端是云端代码托管又是中间那一环任何一环版本对不上后面跑流水线的时候就会冒出一堆莫名其妙的报错。所以这篇文章会从代码托管这条链路切入先把Git和CodeHub的连接彻底讲透再分别展开iOS和Android这边的环境配置最后把云端构建的环境对齐和常见坑也一并说清楚。1.1 华为云DevCloud到底是什么和CodeHub是什么关系先把这个概念理清楚。华为云DevCloud现在控制台里也经常看到CodeArts品牌指的是同一套DevOps服务是一个一站式研发云平台涵盖项目管理、代码托管、编译构建、部署发布、流水线等能力。而CodeHub是其中负责代码托管的模块本质上就是一个基于Git的云端仓库服务和GitHub、GitLab属于同类产品只是它深度集成在华为云的整体生态里。对于移动端团队来说CodeHub解决的核心痛点是仓库不再依赖内网服务器团队成员在任意网络环境都能拉取和推送代码仓库权限可以和DevCloud的项目成员体系打通同时代码仓库和构建服务天然联动后续做CI/CD的时候不需要额外写一堆脚本去对接。这里有一个很重要的认知CodeHub不是简单的云盘版Git仓库它和DevCloud的流水线、编译构建任务是联动的。你在本地提交代码到CodeHubCodeHub触发Webhook云端构建机拉取最新代码开始编译整个链条是通的。如果只是把代码推到远程仓库而不用云端构建那这套迁移的意义就打了一半折扣。1.2 为什么我觉得这一步值得单独写一篇很多教程上来就直接让你执行git clone忽略了环境搭建的系统性。但移动端开发和后端不一样涉及的本地工具链很重iOS必须用macOS加XcodeAndroid需要JDK、Android Studio、SDK、Gradle一大堆。如果只讲仓库配置不讲环境对齐你本地跑得好好的代码到了云端构建机上大概率编译不过。另外一个容易被忽略的问题是iOS和Android两个平台对Git的使用习惯有差异。iOS端通常直接在Xcode里操作GitAndroid端则习惯用Android Studio的VCS菜单或者命令行。两端提交代码时对.gitignore的处理、对二进制文件的管理方式也不同。既然放在同一个CodeHub仓库下这些差异就必须在环境搭建阶段就统一规范好。所以我这篇的定位是先搞定代码托管这一层再搞定两端环境这一层两者的交叉点就是本地Git配置和SSH密钥。下面我从最基础的SSH配置开始讲这是连接CodeHub的第一道关卡。2. Git与CodeHub建立连接SSH密钥生成、配置与验证全程记录2.1 本地Git环境准备与版本选择无论iOS还是Android端第一步都是在本地装好Git。macOS上我推荐用Homebrew安装命令是brew install git安装完检查版本git --version这里有一个需要注意的细节macOS自带的Git版本可能比较老而且Xcode如果更新过系统的Git路径可能会被Xcode的命令行工具覆盖导致版本混乱。建议用Homebrew的Git并确保which git指向/usr/local/bin/git或/opt/homebrew/bin/git不要指向/usr/bin/git。Windows端推荐直接装Git for Windows安装时选Use Git from the Windows Command Prompt和Checkout as-is, commit as-is这两个选项前者方便在CMD和PowerShell里直接用git命令后者避免行尾符转换引发一堆莫名奇妙的diff。Android端的同学还要装JDK和Android Studio这个我在第四部分细说这里先保证Git本身是可用的。2.2 SSH密钥对生成一对密钥还是两对密钥连接CodeHub有两种方式HTTPS和SSH。HTTPS每次push都要输入用户名密码可以配置credential缓存但团队协作时容易出问题SSH则是通过公钥认证配置好之后push/pull都不需要再输密码。移动端团队我强烈建议用SSH。生成SSH密钥的命令ssh-keygen -t rsa -b 4096 -C your_emailexample.com -f ~/.ssh/id_rsa_devcloud这里有几个参数说明一下-t rsa指定算法虽然现在也支持Ed25519但CodeHub对RSA的兼容性最稳妥4096位长度足够安全-C是注释建议填你在DevCloud注册的邮箱方便后期识别-f指定文件名我习惯不以默认的id_rsa命名而是单独命名为id_rsa_devcloud这样如果电脑上还有其他Git平台比如自建GitLab或GitHub的密钥就不会互相覆盖生成之后~/.ssh目录下会出现两个文件id_rsa_devcloud私钥和id_rsa_devcloud.pub公钥。私钥留在本地公钥要填到CodeHub后台。如果你同时维护多个代码托管平台我建议在~/.ssh/config里做区分。示例配置Host codehub HostName codehub.devcloud.huaweicloud.com User git IdentityFile ~/.ssh/id_rsa_devcloud这样后面git clone时可以直接用gitcodehub:Group/Repo.git这种写法Git会自动使用对应密钥。没有这个配置也不影响功能但配置了之后在多密钥环境下会省掉很多麻烦。2.3 公钥配置到CodeHub后台与本地验证登录华为云DevCloud控制台进入CodeHub服务在个人设置里找到SSH密钥管理把id_rsa_devcloud.pub里的内容完整复制粘贴进去保存即可。这个公钥和你的华为云账号绑定同一账号下的所有CodeHub仓库都能用。然后在本地验证连通性ssh -T gitcodehub.devcloud.huaweicloud.com第一次连接会提示确认指纹输入yes回车。如果返回类似于Welcome to CodeHub的欢迎信息说明密钥配置成功。如果提示权限拒绝Permission denied按顺序排查公钥是否完整复制有没有多复制空格或者漏掉末尾的邮箱注释私钥文件的权限是否过宽运行chmod 600 ~/.ssh/id_rsa_devcloudssh-add -l查看私钥是否已加载到ssh-agent没有就执行ssh-add ~/.ssh/id_rsa_devcloud这里我要特别提一个坑Windows环境下如果你用的是Git for Windows自带的OpenSSH但同时又装了别的SSH工具可能会遇到公钥能配但就是连不上的问题大概率是SSH客户端选择冲突。解决办法是在Git for Windows的安装选项里明确设置Use OpenSSH或者在系统环境变量里把GIT_SSH指向正确的ssh.exe路径。2.4 创建CodeHub仓库并完成首次push在CodeHub后台新建仓库填充仓库名选择可见范围私有还是公开。国内团队项目的代码仓库保险起见都选私有同时注意DevCloud里项目的成员权限配置——不是项目成员的人看不到仓库这一点和GitLab的Group权限模型类似。仓库创建后CodeHub会给出完整的命令行指引HTTPS和SSH两种方式都有。我们按SSH的方式操作。以iOS端为例如果项目已经存在本地cd your-ios-project git init git add . git commit -m Initial commit git remote add origin gitcodehub.devcloud.huaweicloud.com:GroupName/RepoName.git git push -u origin masterAndroid端的操作完全一致。这里提醒几个细节首次git add .之前务必先把.gitignore写好。iOS项目至少要忽略Pods/、DerivedData/、*.xcuserstateAndroid项目至少要忽略build/、local.properties、.idea/。这些目录一旦被提交进去后面再想清理就得用git rm -r --cached麻烦不说还容易误删分支命名建议统一用master或mainDevCloud的仓库默认分支可以在后台改。后续如果走Git Flow再按需建develop、release分支首次push的仓库建议不要太大超过几百MB时用git gc压缩一下对象否则网络不稳定时容易push失败3. iOS本地与云端开发环境Xcode、模拟器与构建机的配合3.1 Xcode版本选择与命令行工具iOS开发绕不开Xcode。官方渠道是App Store安装等Xcode下载完再装Command Line Toolsxcode-select --install装完后把命令行工具路径指向Xcode自带的工具链sudo xcode-select -s /Applications/Xcode.app/Contents/Developer然后验证xcode-select -p这一步看似简单但我遇到过一个很头疼的问题Xcode更新到新版本后xcodebuild命令报错找不到SDK。这个问题的根源是xcode-select的路径被重置了或者多个Xcode版本并存导致系统指向了错误的Developer目录。所以每次升级Xcode后我都习惯先跑一遍xcode-select -p确认路径再跑xcodebuild -version确认版本。云端构建这部分华为云DevCloud提供macOS构建机。这里的关键点是本地Xcode主版本和云端构建机的Xcode版本必须一致或至少兼容。比如本地用Xcode 15云端也尽量保持在15这个大版本。如果不一致最容易出现的情况是本地编译链接通过提交上去之后云端构建报错什么SDK版本过低parameter of xxx is unavailable之类看起来像是代码问题实际是工具链版本不一致导致的。DevCloud的构建任务配置页面里可以选择构建机类型和Xcode版本这一步一定要和本地对齐。我记过一次很典型的例子A同学本地Xcode 16提交的代码云端的构建机还停留在Xcode 14结果一跑流水线就报iOS 17 SDK required。当时排查了半小时最后发现不是代码问题纯粹是版本错位。3.2 本地模拟器与真机调试的环境细节模拟器本身不算复杂但涉及证书签名的环节容易卡人。模拟器构建不需要证书直接CommandR就能跑真机调试需要Apple Development证书和描述文件。这个证书体系对新手来说是第一道坎。实操层面在Xcode的Signing Capabilities面板里勾选Automatically manage signingXcode会自动帮你生成开发证书和描述文件。但如果你是用CodeHub拉下来的仓库且项目里的Bundle Identifier和当前开发者账号不匹配会自动签名会失败。我一般建议确认团队里每个开发者在DevCloud项目的成员列表里并且有对应的Apple开发者账号权限项目里如果涉及推送、App Group等能力在Apple开发者后台提前配好不要提交个人证书和描述文件到Git仓库用Xcode的自动管理机制代替云端iOS构建时证书的处理方式不同需要把证书和描述文件上传到DevCloud的证书管理里构建时通过配置关联。这个我放到第五节讲流水线时一起说。3.3 使用Xcode连接CodeHub仓库的操作路径Xcode内置了Git客户端在项目初始化的界面上Xcode 15及以上的版本在创建项目时可以选择源码控制。如果是已有的项目要通过Xcode连接CodeHub可以在Xcode的Source Control菜单里添加远程仓库填入CodeHub的SSH地址。这里有个Xcode使用上的细节Xcode的Git界面在查看Diff、提交、推送时还算好用但遇到冲突解决时我还是建议切换到命令行或第三方工具。Xcode的冲突解决界面做得比较简陋多个纷争并发时容易点错导致误把别人的修改覆盖掉。比较稳妥的工作流是在Xcode里写代码、看Diff、做常规提交切换分支、合并、处理冲突时用命令行工具推送到远程之前先在命令行看一遍git log和git status另外Xcode项目文件.xcodeproj是结构化目录Git合并时经常出现项目文件冲突。团队协作时最好约定一个规则同一时间段内尽量不要多人同时修改项目配置比如签名配置、Target设置这些能避免大量无意义的冲突。4. Android本地与云端开发环境Android Studio、Gradle与CodeHub的三角组合4.1 JDK与Android Studio安装的版本匹配问题Android端的本地环境搭建第一个坑就是JDK版本。Android Studio新版本如Koala及以后内置了JBRJetBrains Runtime但Gradle构建时仍需要Java环境。常见的匹配关系大致如下Gradle版本JDK版本要求AGP版本建议7.xJDK 11或177.x8.xJDK 178.x8.5JDK 17或218.5如果不匹配最常见的就是Unsupported class file major version这类报错。根本原因是Gradle运行时的JDK和编译字节码的JDK不一致。Android Studio自带JBR但命令行构建时比如在CI环境里系统默认的java可能是Oracle JDK或者OpenJDK的某个版本。现在大部分企业项目的实践经验是在项目根目录的gradle.properties或.java-version文件里固定JDK版本然后确保本地的JAVA_HOME指向正确的路径。Android Studio安装完成后还要通过SDK Manager下载对应版本的Android SDK Platform、Build Tools和NDK如果你的项目用C/C代码。SDK的路径配置很重要Android Studio默认会写到用户目录下的Android/Sdk这个路径务必记下来后面配置云端构建时还要用到。4.2 Gradle初始化与项目依赖同步Android项目的构建核心是Gradle。新建项目或从CodeHub拉取项目后Android Studio会自动同步Gradle依赖。但如果是从仓库拉的老项目大概率会遇到两个问题Gradle wrapper版本和本地已安装的Gradle版本不匹配依赖源拉取超时第一个问题的解决办法是修改gradle/wrapper/gradle-wrapper.properties里的distributionUrl或者直接在Android Studio里调整Gradle JDK版本。第二个问题在实际中更常见经常是国内网络环境下默认的Google Maven仓库拉取慢。常用的做法是在项目级build.gradle里配置阿里云镜像仓库buildscript { repositories { maven { url https://maven.aliyun.com/repository/google } maven { url https://maven.aliyun.com/repository/public } maven { url https://maven.aliyun.com/repository/gradle-plugin } } }这个配置我一般建议只在本地开发环境加提交代码时通过git update-index --skip-worktree build.gradle的方式避免误提交或者干脆在CI环境里用环境变量控制镜像源。原因也很简单如果所有团队成员都用自己的镜像配置可能会出现依赖源不一致、构建结果不一致的情况。4.3 Android Studio的VCS配置与从CodeHub拉取项目Android Studio内置了Git支持首次打开项目后通过VCS菜单可以把本地仓库切换到CodeHub远程。操作路径是VCS Git Remotes添加CodeHub的SSH地址。这里有一个重要的操作习惯Android Studio里右键项目文件时会看到很多Git相关的操作但不要用Android Studio的Git去处理项目文件的冲突。Android Studio在合并多个模块的Gradle脚本时自动合并策略有时候会把两个不相关的改动强行合并到一起产生逻辑层面的错误。一般认为最稳妥的Android Git操作顺序是在Android Studio里开发编码切换到命令行执行git pull --rebase拉取远端最新代码手动处理冲突后再回Android Studio刷新项目本地编译通过后再push到CodeHub这样看似多了一步实际能避免很多Git操作造成的问题。4.4 Android云端构建环境的认知本质上就是一台预装SDK的Linux机器DevCloud的Android构建机本质上是一台预装了JDK、Android SDK、Gradle的Linux虚拟机。你在本地能跑通的构建理论上云端也能跑通前提是环境对齐。这里最容易出问题的点有三个SDK版本本地装的是API 34云端构建机可能只预装了API 33编译时就会报SDK component platforms;android-34 was not found。解决办法是在流水线构建任务里加上SDK安装步骤或者通过脚本自动下载对应版本Gradle缓存云端构建机每次构建时如果不是同一台机器Gradle的依赖缓存可能为空构建耗时明显拉长。DevCloud构建任务支持配置缓存策略建议开启签名配置release包的签名文件.jks不要放进仓库本地构建时用local.properties引用签名路径云端构建时通过DevCloud的私密参数下发我在初期的项目里吃过亏本地release构建一直正常云端一跑就报Key was created with errors排查后发现是签名文件被加密后云端构建机上解密生成的临时文件权限不对。这种问题很隐蔽写在流水线配置里要注意文件的加密与解密顺序。5. 云的流水线配置从代码提交到自动化构建的核心链路5.1 在DevCloud里创建编译构建任务DevCloud的CI/CD核心是流水线Pipeline构建任务可以单独配置也可以放在流水线里串联。以Android为例最基本的构建任务是从CodeHub拉取代码执行./gradlew assembleDebug产出APK。流程上先在DevCloud控制台进入编译构建新建构建任务选择代码源为CodeHub选中对应的仓库和分支选择构建模板Android有现成的模板会帮你填充Gradle命令和SDK路径配置构建机类型一般选Linux Docker保存之后手动执行一次看构建日志这里有一个很关键的点构建任务拉取代码时用的凭证。DevCloud的构建任务默认使用你创建任务时关联的账号权限但它拉取代码的凭证是独立的。如果构建日志里出现Authentication failed不要慌去构建任务的代码源配置里检查是否选择了正确的CodeHub仓库访问权限。另一种路径是你在自己的流水线里写自定义脚本用git clone命令手动拉取代码然后执行构建命令。这种方式的灵活度最高但你必须自己管理SSH密钥或HTTPS凭证在构建机上的存放位置稍有不慎就会把密钥泄露到构建日志里。我建议新手优先用DevCloud自带代码源配置不要在脚本里手动处理认证。5.2 iOS云端构建的证书管理与描述文件策略iOS云端构建相对Android更繁琐核心在于证书和描述文件不能像Android那样简单用密钥参数。DevCloud提供证书管理功能把.p12证书文件和.mobileprovision上传到云端构建时绑定到对应任务。实操中我发现以下几个环节是坑点高发区证书导出在钥匙串访问里导出.p12时注意勾选包含私钥并设置导出密码。这个密码在云端构建配置时要用到描述文件选择确保描述文件包含的设备列表包含运行真机的设备或者使用App Store类型描述文件。如果描述文件不匹配签名阶段会直接报错构建命令的选择xcodebuild的-exportArchive阶段要指定ExportOptions.plist这个文件里写的teamID、method要和证书匹配。我们在实际项目中维护了一个ExportOptions.plist模板放在仓库里避免每个人本地手写导出配置构建日志里常见的errSecInternalComponent错误大多是证书导入到云端Keychain时权限问题。DevCloud的文档里会提到构建机钥匙串权限设置建议仔细阅读这里不再展开。5.3 流水线串联提交触发、静态检查与产物归档当两端构建任务都跑通后就可以把它们串到一条流水线里。DevCloud里创建流水线经过这几个阶段代码提交时自动触发在仓库配置Webhook或者流水线的代码源绑定CodeHub仓库每次push自动启动流水线并行执行iOS构建和Android构建在逻辑上相互独立可以配置成并行阶段节省总耗时静态检查可选DevCloud集成了代码检查服务可以加在构建前拦截明显的编码规范问题产物归档把生成的.ipa和.apk文件归档到DevCloud的软件发布库或制品库方便测试同学直接下载这里分享一下我对自动化程度的建议不是流水线越复杂越好。早期阶段两端各一条简单的构建任务加上手动触发已经比人工打包进步一大截。等团队稳定了再逐步加自动化触发、代码检查、自动部署到测试环境。一上来就配置全自动链路维护成本会很高而且出现问题后排查难度大。5.4 云端构建机与本地环境的一致性维护清单这是一个我强烈建议做成文档的清单。我们在实际运营中总结出来的一致性维护项包括检查项本地云端构建机Xcode版本Xcode 15.xXcode 15.xAndroid SDK平台API 34构建脚本中动态安装JDK版本JDK 17JDK 17Gradle版本由wrapper指定使用wrapper签名方式本地jks文件云端证书管理依赖源海外或镜像源与本地保持一致这个清单不是一劳永逸的。每次系统升级、工具链更新都要重新对齐一轮。特别是Xcode大版本更新后SDK特性变化很大本地一升级云端立刻要跟进否则下一次云端构建就会失败。6. 环境搭建避坑实录版本、超时与权限边界的经典坑6.1 Xcode升级后xcodebuild路径错乱的处理开头提到过xcode-select的问题再展开讲一次具体案例。有一次Xcode从15.2升到15.3之后团队里几个iOS开发同时报告在终端跑xcodebuild时提示找不到这个命令。排查后发现原因是升级过程中系统把/Library/Developer/CommandLineTools激活成了默认开发者目录而xcodebuild实际上在Xcode.app内部。运行sudo xcode-select -s /Applications/Xcode.app/Contents/Developer即可解决。此外如果安装了多个Xcode版本比如Xcode_14.x和Xcode_15.x并存建议在构建脚本里显式指定DEVELOPER_DIR环境变量否则不同终端环境可能选到不同的Xcode构建结果都会不一样。这里我给的方案是在项目根目录维护一个env.sh脚本里面写好export DEVELOPER_DIR/Applications/Xcode.app/Contents/Developer export JAVA_HOME/path/to/jdk-17每次打开新终端或者进入项目目录时先source env.sh从源头避免环境错乱。6.2 Gradle依赖下载超时的排查链路Android构建最容易出现的经典坑就是依赖下载超时。表现是构建日志里出现类似Could not resolve com.android.tools.build:gradle:8.x.x或Connection timed out。这时候不要急着重试先按顺序排查确认distributionUrl对应的Gradle版本能否从网络正常下载检查仓库地址是否可访问直接在浏览器里访问一下对应URL检查本机是否有代理或防火墙拦截了相关域名如果用的是镜像源确认镜像源同步完整在实际案例里我们遇到过镜像源只同步了部分模块导致解析失败的情况这时候把缺失的仓库临时切回Google官方仓库即可。另外合理配置Gradle离线缓存也能显著缓解~/.gradle/caches目录的缓存可以复制到云端构建机的持久化磁盘避免每次构建从零下载。6.3 敏感文件入库的补救流程经常有同事在配置环境时临时改了local.properties提交代码时不小心把这个文件带进仓库。这个文件里通常含有SDK路径、本地签名文件路径等信息不应该进仓库。补救流程分两步# 第一步把文件从Git追踪中移除 git rm --cached local.properties # 第二步加入.gitignore避免再次误提交 echo local.properties .gitignore git commit -m Remove local.properties from version control但如果这个文件已经被推送到了远程仓库光这么做还不够因为历史记录里仍然存在该文件内容。为了彻底移除要用git filter-branch或git filter-repo重写历史。这个操作会导致仓库的commit hash变化如果仓库已经有多人协作重写历史前必须和团队成员确认否则其他人的本地分支全部会失联。我个人经验是在项目初期就严格把关.gitignore比事后补救成本低得多。团队里可以做一次代码评审约定凡是涉及本地环境信息的文件一律不入库。6.4 权限边界与团队成员协作的注意事项CodeHub的权限模型里代码仓库的访问权限与DevCloud的项目成员角色绑定常见角色有项目经理、开发人员、测试人员、浏览者等。开发人员默认有仓库的push权限测试人员只有只读权限这一点在配置完权限后要告知每位成员避免出现测试同学想拉代码却拉不下来的疑问。还有一个容易忽略的点成员从DevCloud项目里移除后他/她原来的SSH公钥会立即失效哪怕公钥还留在CodeHub的个人设置里。这是一个安全设计但如果项目内人员流动频繁新成员加入后一定要走加入项目的流程而不是单独添加公钥后者容易在忘却后造成权限边界混乱。7. 一个完整的实操演示从零连接CodeHub到两端构建通过这部分我以团队里真实走过的路径为蓝本整理出一份可以直接对照操作的完整流程清单。假设我们的项目叫某跨平台管理AppiOS和Android两个端的代码放在同一个CodeHub仓库里用不同目录区分也可以是两个独立仓库逻辑一致这里以单仓库为例。7.1 初始化阶段本地项目与CodeHub仓库的关联第一步在CodeHub创建一个空仓库例如mobile-app。创建时选私有初始化时不要勾选生成README和.gitignore保持仓库为空因为我们本地项目已存在。第二步在项目根目录建立.gitignore。iOS和Android双端目录结构示例# iOS Pods/ DerivedData/ *.xcuserstate xcuserdata/ # Android build/ .gradle/ local.properties .idea/ *.apk *.aab captures/ # 通用 .DS_Store *.log第三步执行本地Git初始化并连接远程git init git add . git commit -m Initial commit git remote add origin gitcodehub.devcloud.huaweicloud.com:YourGroup/mobile-app.git git push -u origin master这个阶段遇到最多的问题就是push时提示Permission to XXX denied按第2.3节的方法排查密钥配置。等push成功CodeHub网页端能看到代码就说明Git连接这一环彻底打通了。7.2 iOS本地编译验证与云端任务创建本地打开Xcode确认能直接编译运行项目。然后到DevCloud创建iOS构建任务主要内容包括代码源选择CodeHub仓库分支选择master构建机选择macOS类型构建模板选择Xcode相关模板在证书管理里导入.p12和.mobileprovision构建命令选择xcodebuild -workspace YourApp.xcworkspace -scheme YourApp -configuration Release clean archive并指定导出选项这一步容易出的问题构建机型号不同xcworkspace的Pod安装情况也不同。如果项目使用CocoaPods要确保构建前先执行pod install否则workspace无法生成构建直接失败。7.3 Android本地编译验证与云端任务创建Android端同样先确保本地能跑通./gradlew assembleDebug。然后到DevCloud创建Android构建任务代码源选择同一CodeHub仓库构建机类型选择Linux构建命令填写./gradlew clean assembleDebug配置JDK和SDK路径如果构建时下载依赖慢开启Gradle缓存这里的关键是SDK路径。DevCloud的Linux构建机预装了SDK但版本可能不是你需要的。我们的做法是在构建脚本开头动态安装SDK组件sdkmanager --install platforms;android-34 build-tools;34.0.0或者直接在Gradle配置里用android.suppressUnsupportedCompileSdk的方式控制版本兼容。7.4 两端构建通过后的验证清单构建任务创建完手动触发一次拿到构建成功的日志后做以下验证在CodeHub上修改一次代码并push确认流水线自动触发如果配置了自动触发从制品库下载iOS的.ipa和Android的APK分别安装到模拟器和真机验证让另一位同事从CodeHub重新clone代码跑一次本地编译确认新成员环境也能正常复现检查构建日志里有没有warning或非致命错误尽量消除我建议至少把这些验证做全再进行下一步的自动化集成否则环境层面埋下的雷会在后续功能迭代中反复炸。8. 写在最后的个人操作心得做完整套环境搭建我最想强调的一点是不要小看环境对齐这件事。代码托管只是把代码放到了云上真正的价值在云端构建和协作流程里而这两者的基础就是本地环境和云端环境的一致性。如果两边版本不一致你每天的工作都会在本地能跑云端报错的循环里消耗大量时间。实操了多次之后我现在的习惯是每次本地工具链一升级就在云端的构建任务、流水线配置里做一次同步更新同时更新团队文档里的环境对齐清单。不要等到下次构建失败时再想起来那时候排查成本已经上去了。另一个有价值的体会是文档比记忆靠谱。我们团队现在维护了一份标准的入职环境搭建文档内容就是这篇文章里讲到的流程压缩版。新人来了照着做基本半天内能把环境和CI链路跑通。如果你也是移动端团队的负责人我强烈建议把环境搭建规范做成文档让每个成员按同一套标准来后续省下的时间绝对值得。