云计算托管：用SaaS控制源码

关于源码控制(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服务器的安全风险，或者通过和具体提供商的合同来进行。