\
在這個定義下，我們就必須將執行環境的軟體解構，並以包的形式匯入到公司的整個專案資源庫中，比如apache將作為乙個包被匯入，而apache依賴的其它包也將依次被匯入，並建立起正確的依賴關係。而且，在匯入的過程中還必須做些相應的調整，如，環境變數的讀取和設定，必須來自於環境配置模組，而不要修改系統的環境變數，防止不同環境在系統環境配置上相互影響和依賴。
\ 部署，一次部署可能會產生乙個環境例項。一系列部署將產生對應於環境目標的多個環境例項，除去當前起作用的環境例項外（最新的），其它的是歷史環境例項。通過在歷史環境例項中切換，我們自然而然的就可以使整個環境回滾，因為專案所依賴的一切都已經成為的環境中的軟體包，而且環境依賴的包的版本會隨著部署具體確定下來。
\ 建立邏輯軟體包版本和版本庫中軟體包版本間的關係；為相互依賴的包編譯並打上統一的標籤；簡化執行時包依賴關係的生產；簡化執行時包依賴的指定（可參考apt-get和rubygem，環境只需指定直接依賴的包，間接依賴的包從執行時依賴樹中自動匯入）
\
Coolblue的持續部署
coolblue 的技術開拓者paul de raaij提出，持續部署會得到更強的責任感和更好的部署質量。規範預防 庫混亂，自動化檢查很合適完成冗長而無聊的檢查，人工檢查很合適去檢查 的邏輯和用法實際上是否成立。de raaij 寫了一篇博文 我們軟體的持續部署 在文章中他解釋了coolblue是如...
Instgram的持續部署
我們每天都要在instagram改進後台 30到50次，但工程師們只在極少數的情況下需要將這些修改上傳到主伺服器上進行部署，但大部分情況下 可以自我改進以達到預期的效果，無須人為干涉。這可能聽起來不可思議，但持續部署早已開始應用。這篇文章將講述我們是如何實現持續部署，並讓它協調地執行。為什麼這麼做？...
持續整合 持續交付 持續部署
持續整合 持續整合強調開發人員提交了新 之後，立刻進行構建 單元 測試。根據測試結果，我們可以確定新 和原有 能否正確地整合在一起。持續交付 持續交付在持續整合的基礎上，將整合後的 部署到更貼近真實執行環境的 類生產環境 production like environments 中。比如，我們完成單...