一、構建工具
比較常見的有：
二、指令碼化的一些原則
1、使用恰當的技術部署應用程式（最好開發、測試、運維團隊使用相同的構建工具）
2、使用同樣的指令碼向所有環境部署（不同可以通過配置檔案來體現）
3、為部署流水線的每個階段建立指令碼（並把指令碼納入配置管理，同樣可能涉及配置資料、依賴庫、元件庫等）
4、使用作業系統自帶的包管理工具（打包的rpm、installer等）
5、確保部署流程完成結束點狀態是一致的（不論部署環境處於何種狀態）
6、指令碼化一般應增量式演進（比如，第一步是自動編譯、打包；後面增加安裝、配置；在增加冒煙測試；最後增加遠端發布）
三、指令碼化的一些最佳實踐
1、總是使用相對路徑
2、消除掉手工步驟（當然推薦是漸進式的）
3、從二進位製包到版本控制庫的內建追溯性
4、不要把二進位製包作為構建的一部分納入版本控制庫（前面說過很多次了）
5、冒煙測試的每個用例應盡量執行完，失敗的提供錯誤碼（避免冒煙測試中多個錯誤時，要乙個乙個地序列發現）
6、用整合冒煙測試來限制應用程式（對於週期性執行的內容，一定要在安裝部署時測試到，提前發現問題）
總之，對持續交付，構建指令碼是最最重要的工作成果。
談談持續整合，持續交付，持續部署之間的區別
經常會聽到持續整合，持續交付，持續部署，三者究竟是什麼，有何聯絡和區別呢？假如把開發工作流程分為以下幾個階段 編碼 構建 整合 測試 交付 部署 正如你在上圖中看到，持續整合 continuous integration 持續交付 continuous delivery 和 持續部署 continu...
持續整合 持續交付 持續部署之間的區別於聯絡
持續整合是一種軟體開發實踐，即團隊開發成員經常整合他們的工作，通常每個成員每天至少整合一次，也就是意味著每天可能發生多次整合，每次整合都通過自動化的構建 包括編譯 發布 自動化測試 來驗證，從而盡早地發現整合錯誤。1，快速發現錯誤。每完成一點更新，就整合到主幹 可以快速發現錯誤，定位錯誤也比較容易。...
持續交付的Mesos與Docker匯入篇
變革這個詞在當今的數位化時代司空見慣，it技術每過一段時間就會有一起革新，從web2.0 虛擬化 雲計算 大資料 微架構 devops再到今天的容器docker與mesos。docker的出現方便了應用的測試 部署 與公升級，其將各種應用程式和它們所依賴的執行環境打包成標準的container im...