作者都是各自领域经过审查的专家,并撰写他们有经验的主题. 我们所有的内容都经过同行评审,并由同一领域的Toptal专家验证.
发布管理, 顾名思义, 是管理的过程吗, 规划, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases (Humble & 法利,2011).
它本身是一个相当大的主题,并且只能通过与开发团队一起尝试不同的迭代以及匹配业务需求或功能版本来完善. 我们将尝试介绍元数据管理的行业实践, CI构建, 沙盒管理用于管理组织的 释放的火车.
但是什么是释放列车?
发布序列是一种增量的、可预测的特性交付技术. 它要求开发人员建立一个正式的流程来处理开发环境中的任何更改,并将其部署到生产环境中.
一个发布序列可以大致分为三个部分:
元数据是提供关于其他数据的信息的数据. Salesforce提供了一个丰富而强大的元数据模型 元数据API. 应用程序元数据描述并包含一组方法,这些方法提供对组织的源代码和配置的编程访问.
的 元数据API 在Salesforce中管理自定义的最佳方式是什么. 它支持 创建
, 读
, 更新
, 删除
方法. 你可以使用变更集,原力.com IDE, 以及蚂蚁迁移工具,将元数据从一个组织迁移到另一个组织, 因为它们都通过API提供迁移.
每种工具都有自己的优势,在选择一种工具时需要考虑以下几点:
变更集 | 力.com IDE | 蚂蚁迁移工具 |
---|---|---|
变更集是通过标准Salesforce UI部署组件的方式. | 力.com IDE (Eclipse)主要用于Apex开发, 但是可以用于部署目的. | Ant Migration是一个强大的命令行工具, 专门用于在环境之间迁移更改/元数据. |
通常用于少量组件的迁移. | 开发人员通常使用IDE将更改迁移到测试或登台环境. | Ant Migration用于大型负载迁移,需要具备Salesforce 元数据API的高级知识. |
各组织之间需要手动建立连接, 所以它不适合自动部署. | 它可用于部署到任何组织,但需要一些容易出错的手动步骤. | 可以非常容易地安排自动部署. |
供管理员使用. | 面向salesforce开发人员,因为开发代码是它的主要用途. | 面向DevOps工程师. |
添加依赖项非常简单且用户友好. | 添加依赖比较容易,因为它提供了一个点击式UI. | 由于缺少依赖项,部署通常会失败. |
不允许破坏性的改变. | 是否允许破坏性的更改集,但过程相当繁琐. | 允许破坏性更改集. |
当在力上开发和迁移更改时,元数据API非常适合它的用途.com平台. 但是这里有一个小问题——并不是所有的Salesforce元数据都受元数据API的支持. 官方文档提供了 列表 不受支持的组件.
如果您的组织正在进行元数据API不支持的更改, 您必须确保在目标组织中手动复制这些更改. 跟踪这些变化的最好方法是制作电子表格. 如果你不得不采取这种方法, 最好是由一个人来完成这些更改并对其进行跟踪.
这将是一个很好的通用列列表,人们可以使用它来跟踪电子表格中的这些变化:
将更改迁移到生产环境应该是一个顺利的过程, 因为它只是在测试和登台环境中应用更改的重复. 尽管如此,事情总是有可能变糟,然后你需要一个后备计划. 保持组织元数据的备份是非常重要的,这就是 版本控制 和 CI构建 是为.
版本控制对任何组织来说都是绝对必要的. 它允许开发人员以协作、高效和安全的方式工作. 在Salesforce中,管理多开发人员、多沙箱代码开发和迁移是一个挑战. Salesforce也有自己的发布和维护时间表. 这些更新提供了新功能, 但它们可能会在元数据API中引入变化,这可能会破坏您的CI构建. So, 除了开发人员相互覆盖更改的情况, 版本控制可以帮助您构建回滚策略. 当应用程序在力上运行时,必须使用回滚策略.com.
下面的流程图描述了版本控制和持续集成的实用结构. 我们将试着给你一个简短的描述,这个图表代表了什么.
您可以根据组织的需要选择添加更多分支. 但是上面的结构只适用于中级到企业级的开发结构.
充分利用组织的DevOps流程, 设置沙盒结构非常重要. 在我们深入研究之前, 让我们来讨论一下Salesforce提供给我们的不同类型的沙箱.
沙盒几乎是生产元数据的精确副本. 沙盒通常用于开发、测试、准备和培训目的. 有四种类型的沙盒,在选择沙盒时应该给予适当的考虑. 完整复制沙盒可能会花费很多钱!
下表列出了Salesforce对不同沙箱的限制.
开发人员 | 开发人员职业 | 部分复制 | 完整的复制 | |
---|---|---|---|---|
生产数据 | No | No | 是的 | 是的 |
数据存储 | 200 MB | 1 GB | 5GB(每个对象10K条记录) | 完整的数据 |
刷新周期 | 1天 | 1天 | 5天 | 29天 |
我们可以看到,价格并不是沙盒之间的唯一区别.
开发者沙箱有一天的刷新周期, 是什么让它适合开发, 但只能容纳200mb的数据, 没有生产数据. 作为两极的对立面, full copy sandboxes have an exact copy of the production data; even the record IDs are the same. 这对于测试和分级来说是非常好的, 但是29天的刷新周期使得在完整复制沙盒中获取最新的生产元数据和数据变得困难.
下表是选择沙盒的经验法则:
开发人员 | 开发人员职业 | 部分复制 | 完整的复制 | |
---|---|---|---|---|
发展 | 是的 | 是的 | No | No |
QA | 是的 | 是的 | 是的 | No |
集成测试 | No | No | 是的 | 是的 |
批量数据测试 | No | No | 是的 | 是的 |
培训 | No | No | 是的 | 是的 |
UAT | No | No | 是的 | 是的 |
负载测试 | No | No | No | 是的 |
暂存 | No | No | No | 是的 |
用户培训 | No | No | No | 是的 |
下面是中型项目采用的典型组织结构. 企业级客户端, 组织结构变得更加复杂,但大体上遵循下面的模型.
Salesforce发展 通常是在开发人员沙盒(红色)中完成的,然后将更改移动到集成沙盒(绿色),通常是开发人员专业人员或部分复制沙盒. 然后,来自多个集成沙箱的更改向上移动到滚动沙箱(黄色),它应该是一个部分复制沙箱.
如果您的组织与第三方系统有任何集成,需要执行集成测试和负载测试, 我们需要有一组稳定的数据,不会在每个版本之间发生变化. 因此,最好为它设置一个完整副本或部分副本沙盒.
然后将这些更改移动到集成测试沙箱中,在那里执行测试. 然后将更改移动到暂存沙盒,它应该是一个完整复制沙盒. 所有的测试类都在部署之前运行. 应该执行部署验证,以确保部署没有任何问题.
这个过程帮助我们确保这些变化经过多轮测试和双眼睛. 它的一个严重缺点是需要大量的时间来开发、测试和部署更改.
通常情况下,迫切需要执行错误修复或补丁. 为了快速处理这些问题, 开发者应该保留一个开发者沙盒, 哪一种方法可以将小补丁直接推送到卷起的沙盒中.
如前所述, 沙盒几乎是生产元数据的精确副本, 但也不完全是. 有一个 官方名单 在沙盒中禁用的组件/特性.
刷新沙盒时要考虑的另一件事是,它只复制生产元数据和数据. 没有办法将元数据从一个沙箱复制到另一个沙箱, 或者甚至创建一个没有任何元数据配置的空沙箱(像免费的开发人员组织). 这在现实生活中有时会成为一个挑战. Salesforce计划解决这个问题 功能 可能很快就会普遍可用.
另外, 如果您在生产中有一些敏感数据, 您认为您的开发或测试团队不应该访问哪些内容, 你可以创建 沙箱模板 对于完全和部分复制的沙盒.
我们已经介绍了Salesforce生态系统中应用程序生命周期管理的行业实践. 元数据和沙箱管理在创建部署包和有效负载方面起着非常重要的作用. 对于大型和复杂的 Salesforce的应用程序, 版本控制有助于确保跟踪元数据更改,同时还有助于创建回滚策略.
沙盒管理对于大型或复杂的项目是至关重要的. 但在Salesforce生态系统中,沙箱的成本很高, 无论是财力还是时间. 制定沙盒管理的策略对于发布管理过程总是至关重要的.
我们将给你留下一些额外的要点,这些要点在你下次部署时应该牢记在心:
请求超时
错误,尝试从包中删除对象、自定义字段和配置文件. 这些组件需要更长的时间来部署.希望这篇概述能在您的下一个Salesforce版本中对您有所帮助.
Ajinkya是Salesforce的高级开发人员和架构师. 他精通高级Apex编程、Visualforce和Lightning开发.
世界级的文章,每周发一次.
世界级的文章,每周发一次.