关于源码控制(SCC)最重要的技术决策在于是否在机房内(on premises)或者机房外(off-premises)托管存储库。
开发者关注的的大多是SCC协议的技术细节，这就等价于争论福特VS.通用汽车，依据就是电池和燃油加入管在司机这边还是在乘客这边。同时，应用生命周期管理(ALM)著作也经常关注高级厂商性能列表，合适的账户既不是为了遗留需求也不是扩展云市场产品新的机遇。
SCC根本上是成熟的技术;尽管聪明的程序员继续创造新的便利，由于原始源码控制系统四十年前在贝尔实验室就开发了，基础还是很清晰。大多数功能可以被“网关”或者在流行的对抗SCC服务器之间翻译。有足够的动机，让中级管理员或者程序员将遗留存储库“移植”到新的服务器上。
开发者对于选择一个SCC模型充满热情，而且这些替代物之间确有技术差别的时候更是如此。同时，这个层面的操作确实一个更深问题的征兆;有些例外，开发企业频繁地运用先进的SCC性能，让工作流过于复杂。复杂改变的了需求，也包含了新兴的替代分支。
在哪里托管存储库呢?谁来维护呢?这些都是重要的战略问题。考虑到相关性，首先要考虑SCC具体的特性。
是什么让SCC如此特别?
SCC难得“增值”;即使前线编码员大部分涉及、需要，只是做一些简单的功能。SCC被认为是保守的术语;它需要可用、可预测和可靠性。不必过度扩展——成功的业务通常基于非常小的源代码部分，甚至一些和操作系统核心一样大只适用于iPod的一角。
此外，如前所述，SCC在过去的四十年中广泛地散播开。大量管理员熟悉SCC管理。
你希望他们怎么安排时间呢?虽然SCC管理员不是重要的责任，但是确实一项耗时的工作，要确保备份、登陆、释放空间等能够正确的配置。
尽管大多数ALM描述还没有考虑这种可能，新一代开发者默认就会想到：他们彻底习惯于依赖像GitHub或者Bitbucket这样的云服务。
SCC进入云端不依赖于企业其他的IT决策制定。无论你拥有内部邮件服务器，还是从厂商那购买邮件服务，对于什么是正确的SCC没有影响。源代码是核心企业资产，但是也是企业的业务文档和项目计划。即便对于一项决策安全或者可用性是最重要的，并不会鼓励确定正确的SCC。因为你仍旧必须确定是否可以更好地管理维护SCC服务器的安全风险，或者通过和具体提供商的合同来进行。
好的管理的必要基础是什么：文档化企业具体SCC需求、成本以及不同替代的好处，每一种工作采用哪种灾难恢复，并明确决策。SCC被标记为一种必要工具，这种工具的应用在企业中覆盖广泛的范围和角色，然后你不能为不同的团队假设正确的决定，而且自动化地应用于你的环境中。
最后，要意识到，通过正确的准备，ALM中的SCC部分很可能成功。源代码和现代服务器功能相对比如此小，你可以轻松地实验或者混合不同的解决方案。你的程序员最需要你来定义SCC计划，以便他们可以开展工作，增加价值。他们想知道如何得到“HEAD”(SCC技术术语)并快速采纳，无论是在云端还是自己企业内部。
