關于源碼控制(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技術術語)并快速采納，無論是在云端還是自己企業內部。