一个第三方开发者(ISV) 需要开发Managed Package让消费者使用，而在这个ISV组织内部，软件开发又要经历 Dev -> QA测试 -> UAT测试 -> 上线 等步骤，而且Dev还要跟源码版本控制工具(如CVS)结合起来。
最佳模式是什么？
首先，应该利用SalesForce的Migration Tool把Package中的所有Metadata 变成文件，然后把这些文件纳入到CVS中进行管理。在Dev时，这些文件应该放在一个“开发源码分支”中。 文件修改后，可以利用Migration Tool把它们作为MetaData塞回SalesForce服务器，最后开发人员可以登录SalesForce网站进行功能测试。
那QA环境怎么办？ 是否应该把“开发源码分支”中的文件集成到一个“QA源码分支”，然后再把这些文件塞回SalesForce，最后在SalesForce网站中测试？ 答案是不行。因为namespace会冲突。 我们知道Dev和QA各有一个SalesForce实例，Managed Package在Dev分支中建立后，这个package对应的namespace已经被Dev实例独占了； 如果你想用Migration Tool把这个Package下的Metadata送到QA实例，则意味着QA实例也需要使用这个namespace. 但这是不可能的，因为一个namespace只能属于一个SalesForce实例。
那不同的实例用不同的namespace行不行？ 不行。因为namespace会被直接硬编码到Apex代码中，它不是一个可以放在配置项里的东西。
所以，我们只能在Dev实例中手动打包，然后以publisher/subscriber的方式将这个包发布到QA实例中。 不过，QA实例的“安装pakcage”这种行为无法让某种配置管理工具自动记录下来。这是一个问题。
（未完待续）