Production Deployment Process

同学们好，今天我们来聊聊如何把写好的 Apex 代码从你本地的编辑器里，真正部署到 Salesforce 的组织中去。这个话题很实用，因为我们写代码，最终是要让它跑在服务器上的。 首先，我们现在最常用的本地开发工具就是 Visual Studio Code，你可以在里面安装 Salesforce 提供的官方扩展包。装好之后，就能直接在 VS Code 里连接你的 Salesforce 组织，然后把 Apex 类、触发器这些源文件一键部署上去。这套体验在 Salesforce 后来推出的 Code Builder 这个在线的开发环境里也是一样的，因为它背后用的也是和 VS Code 一样的扩展。所以你只需要记住：当你在 VS Code 或 Code Builder 里开发完，想发布时，直接在扩展的面板里操作部署就行，很方便。 那除了用这些现代的开发工具，Salesforce 还提供了一种更传统的方式，就是通过用户界面里的“变更集”。变更集是什么呢？你可以把它想象成一个包裹，你把写好的 Apex 类、触发器、字段、对象等等组成一个集合，然后把它从一个环境，比如沙盒，上传到另一个环境，比如生产环境。这个方式不需要安装任何外部工具，完全在浏览器里点一点就能完成。只是它相对慢一些，适合比较小的、不太频繁的发布场景。 当然，不管是用哪种部署方式，在正式把代码推到组织之前，有一组硬性要求你必须遵守。这些可不是建议，是 Salesforce 平台强制检查的。最重要的第一条，就是代码的整体测试覆盖率要超过 75%。也就是说，你写完 Apex 类之后，必须编写对应的测试类，执行这些测试后，被覆盖到的代码行数要占到所有代码行的 75% 以上。这个规则是为了保证你部署上去的逻辑是经过验证的，不会轻易出问题。 第二条是，所有的测试都要能通过，不能有任何一个测试报错或者断言失败。哪怕覆盖率够了，如果有一个测试没跑通，部署也会被直接拒绝。 第三个检查点专门针对触发器，每一个你写的触发器都必须要有相应的测试覆盖。你不能写了一个触发器，却从来没测试过它，这是不行的。 最后，也是最基础的，你所有的 Apex 类和触发器必须能成功编译，不能有任何语法错误或者编译报错。如果代码本身编译都过不去，那部署自然不可能成功。 总结一下，今天这个知识点告诉我们两点：一是部署的常见途径——用 VS Code 加上 Salesforce 扩展是最现代的，用变更集是界面化、传统的做法；二是部署前必须通过的四个关卡：75% 以上的测试覆盖率、全部测试通过、每个触发器都有测试覆盖、以及代码编译零错误。记住这些，你的部署就会非常顺畅。 好，这节课就到这里，大家课后可以打开自己的开发环境，试着写一个简单的类和测试类，然后亲手执行一次部署，感受一下这些规则是怎么运作的。