Salesforce Sandbox思考
笔者之前和一个朋友聊到Salesforce Sandbox，对方使用Unlimited 的版本，但是只有使用一个Developer Sandbox，而所有的代码开发就在这个Sandbox上进行，其他的操作就直接在生产环境上做，如新建Field，Sharing Rule。笔者非常诧异对方有Full Sandbox不用，而且缺乏有效的Sandbox策略。所以，决定今天写写文章和大家聊聊Sandbox。
什么是Sandbox？
首先要知道什么是Sandbox，根据字面理解，sand是沙子，box是盒子，如果直译的话，就是一个地方，有沙子，同时有一些一个大的盒子将其包围起来，因此通常国内翻译成为沙盒环境。如下图，Atro可以在Sandboxdbox里面搭建自己的城堡，而每一个Sandbox都不相互影响。Sandbox在Salesforce官方的定义如下：
Sandboxes are special organizations that are used to test changes or new apps without risking damage to your production data or configuration
而Sandbox的有效设计往往是实施流程/部署成功的关键。可以想象一下，一个凌乱的Sandbox，都同时部署于你的Salesforce生产环境会有什么样的重大影响。
Sandbox的类型
那么Sandbox有几种类型的呢？主要分为如下几种。
Developer Sandbox：可以做开发和unit test，也就是小的测试。同时这里可以做一些POC和一些简单的QA。
Developer Pro Sandbox：做开发大量的测试。这里有1G的存储空间。
Partial Copy： 主要用于内部培训和大规模数据测试。有时候，一些QA也会在这里进行。
Full Copy：无size限制，主要用于作为Staging环境。那么Staging又是做什么的呢？Stage中文翻译是阶段或者是筹划，有准备之意，也就是说，有新的功能准备发布或者Bbug Fix 要部署于生产环境，就要在这里进行准备。比方说，你的老板想看看新的功能，但是又不可以在Salesforce生产环境直接看，那么Staging是一个不错的选择。有时候Full Copy会用来做大规模的数据测试，由于其最接近生产环境，如果在生产环境出现了问题，也会最容易在重现出来。
几种sandbox的用途在这里罗列如下。
一般Salesforce会把不同公司的license分配不同的sandbox，如果是unlimited的类型，就会分配到一个full sandbox。
如果您需要额外的Sandbox，您需要找Salesforce额外购买。
Sandbox Template
一般在复制Sandbox时候，Metadata ，custom setting与其对应的data还有License Rype 会被复制到新的sandbox。有时候，我们需要复制一些数据，这时候就需要用到Sandbox Templat， 可以选择需要的对象 复制到你的sandbox
敏捷开发
接下来聊聊Salesforce的敏捷开发周期，请看下图。
项目可能开始始于一个想法(idea)，有可能是用户feedback或者需求。无论是bug还是美好的愿景，就会形成一个user story，这里我们叫BackLog。而这一些BackLog，会给开发团队进行开发和分析，有些地方把开发团队称之为delivery team，也就是交付团队。 在开发团队内的开发周期里，有可以简单分为开发和测试两个环节。通过不断地开发和测试，然后交付，形成整个开发流程。
接下来，基于不同的Sandbox的功能，我们来看看Salesforce的部署流程。假设您有不同的几个Sandbox，各个Developer Sandbox开发着不同的应用或者功能，需要有一个代码管理的机制去控制各个Sandbox之间的代码冲突。然后您可以在Developer Pro 和Partial Copy的 Sandbox里面进行Intergration Testing。
Sandbox 设计策略？
那么是不是每个Salesforce项目都得像上面那样有一个Full Copy Sandbox 作为一个Staging，多个Sandbox 进行测试呢？不是，这里有几个建议给到大家。
对于小型的项目实施团队，可以简单通过如下图实现。通过简单的开发–>部署至Staging，然后部署至生产环境实现整个实施流程。同时，这里保留有一个Developer Pro的Sandbox ，进行生产环境的支持。很多时候，生产环境出现问题，为了不影响用户的业务流程，需要在数个小时内解决，那么保留一个专门用于生产环境的support的Sandbox 是非常有必要的。在这里是强烈反对在生产环境进行有关support debug，而是应该在这个生产环境的support Sandbox进行。
对于中型或者大型的实施的项目，可能有多个团队进行不同模块的开发。可以参考下图的Sandbox实施策略。图中显示了，开发人员在Sratch Org上面开发然后代码同步到代码版本控制系统(version control system，业内简称VCS)，这里可以是Github，GitLab，bitbucket，然后再自动部署于developer Sandbox。但是，需要指出的是，Sratch Org在这里不是必须的，如果您的功能完全不需要通过代码实现，可以需要建立Sratch Org来实现。在开发完成之后，部署于Partial Copy进行有关测试。
对于超大型的实施的项目。可以参考如下的Sandbox设计策略。这里分为大型的实施流程和小型实施流程。对于大型的实施流程，这里需要有一个集成的Org将各个Developer Sandbox的功能集成于一处，然后再部署于Intergration Plus进行有关的测试。而对于小型的实施开放，可以直接部署于Intergration Plus Sandbox。
如上的一些建议希望可以帮到一些Salesforce Org的设计者进行有效的Sandbox设计，同时制定出符合自己公司的实施流程。有什么想法或者有补充的地方可以在下方留言给小编。