雲計算託管：用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伺服器的安全風險，或者通過和具體供應商的合同來進行。

好的管理的必要基礎是什麼：文檔化企業具體SCC需求、成本以及不同替代的好處，每一種工作採用哪種災害復原，並明確決策。 SCC被標記為一種必要工具，這種工具的應用在企業中覆蓋廣泛的範圍和角色，然後你不能為不同的團隊假設正確的決定，而且自動化地應用於你的環境中。

最後，要意識到，通過正確的準備，ALM中的SCC部分很可能成功。 原始程式碼和現代伺服器功能相對比如此小，你可以輕鬆地實驗或者混合不同的解決方案。 你的程式師最需要你來定義SCC計畫，以便他們可以開展工作，增加價值。 他們想知道如何得到「HEAD」(SCC技術術語)並快速採納，無論是在雲端還是自己企業內部。

(責任編輯：蒙遺善)