团队里经常有人问：代码放码云还是别处，部署到哪儿，两边怎么接起来，才不至于每次发版都手忙脚乱。码云和阿里云经常被放在一起讨论，一个管代码和协作，一个管机器和运行环境。两边分工清楚，中间的交付链路搭好，日常会顺很多。这篇文章从实际用法出发，说说两者各自负责什么，最后用一个改造案例看看怎么落地。
码云管代码和协作
码云（Gitee）是开源中国推出的代码托管平台，基于 Git，公开仓库和私有仓库都支持，还带代码审查、任务看板、Wiki 这些协作工具。国内团队用它的一个直接好处是中文界面和文档好读，新人上手不用先跨过英文术语这一关。
日常里，码云主要做这几件事：
- 分支和合并请求放在这里，谁改了什么、什么时候合进主分支，都能查到。
- 合并前在 Pull Request 里评审，能先拦下一部分问题，不必等到线上才暴露。
- 需求拆成 Issue 挂到看板上，进度谁在做、卡在哪，一眼能看出来。
- 配置 Webhook，代码一推上来就通知外部系统，比如触发构建或发消息到群里。
有一点要记住：码云管的是代码和协作过程，它不负责把服务跑起来。合并之后服务部署到哪、用多大规格的机器、流量上来了怎么扩容，这些事归基础设施那一层。两件事混在一起，出了问题往往谁都说不清是哪个环节的事。
阿里云负责跑起来和交付
阿里云的产品线比较全，计算、存储、网络、数据库都有。和研发流程关系最直接的，通常是云服务器 ECS、对象存储 OSS、容器镜像服务 ACR、容器服务 ACK，以及持续交付相关的流水线产品。它们的作用，是把“代码在机器上跑起来”这件事变成可以重复执行的标准动作。
按需付费和弹性伸缩，是它相对自建机房的主要区别。像促销活动、月末批量报表这类流量忽高忽低的业务，临时加资源、用完释放，通常比一直养着一批服务器更划算，也省去了提前采购的等待。
两者怎么接在一起
最常见的搭法是代码留在码云，构建和部署放到阿里云。开发者合并代码后，通过 Webhook 或平台内置的流水线触发构建，产物推送到容器镜像服务，再由 ACK 或 ECS 完成发布。链路跑通之后，人需要介入的地方基本只剩评审和上线确认。
案例：二十来人的垂直电商团队
设想一个做垂直品类电商的团队，二十多名开发，代码原来放在自建的 GitLab 上，部署靠运维登录服务器手动执行脚本。一次发版要花半天，回滚全靠人凭记忆操作，前后出过两次线上事故。
他们的改造分三步走。
第一步，把仓库迁到码云，分支结构保持原样，并设置合并请求至少要一名评审人通过。这一步看起来只是换个地方放代码，但评审规则是后面所有自动化的前提。没有它，流水线会把没经过检查的代码直接送上去。
第二步，在阿里云上建测试和生产两套环境，各自有独立的 ECS 实例。镜像统一存到 ACR，镜像标签直接用码云的提交哈希。这样线上跑的是哪一次提交，一查就知道，回滚时选对应的历史镜像即可。
第三步，写好流水线配置。主分支合并后自动构建镜像并部署到测试环境，测试通过后，由负责人在界面上点一次确认，再发布到生产。做到这里，人只需要在两个关键点上做决定。
三个月后，发版时间从半天降到二十分钟左右，回滚只需选择历史镜像版本即可完成。每次上线对应哪次提交、由谁批准，都有记录，出问题时排查快了很多。这些效果来自流程本身的调整。
落地时的几条经验
- 先把分支策略定下来，再谈自动化。主分支的保护规则和合并要求写清楚，流水线才有稳定的输入。分支一乱，自动化只会更快地把乱的东西发出去。
- 镜像标签和代码版本挂钩，生产部署不要用 latest。用了 latest，过两天就说不清线上跑的是哪一版，回滚也无从下手。
- 访问密钥不要写进仓库，用平台提供的密钥管理功能存放，并安排定期轮换。有人换岗或离职，要及时回收权限。
- 测试和生产的配置尽量保持一致，只在参数文件里放差异，比如数据库地址、副本数量。两边结构越像，“测试通过、上线就挂”的情况越少。
- 测试环境在非工作时间可以停掉，或改用按量付费，避免长期空转。
几个容易走偏的地方
- 把代码托管平台当成运维平台用。码云能管代码和评审，部署和运行还要靠阿里云那一侧，两边得配合。
- 一开始就想把所有流程都自动化。维护成本会很高，团队往往坚持不下去。更实际的做法是先解决最疼的环节，比如发版慢或回滚难。
- 所有人都有生产环境的操作权限。权限一放大，误操作和泄漏的风险也跟着放大，生产部署权限应该只给少数人。
码云把代码协作和评审管清楚，阿里云把代码稳定地跑起来，中间靠一条清楚的交付链路接上。团队不必一次做完，先统一仓库和构建方式，再慢慢引入自动部署和弹性伸缩，一般比较稳妥。
