最近和一位朋友討論持續整合、持續交付在企業的具體價值，和具體執行時的崗位要求，比較值得讓我們思考。
我看的持續交付（continuous delivery），主要實現一套自動化的軟體生產線，在生產線的開端，是程式設計師提交**，而生產線的產出物就是要交付的東西：
能在整個交付的流水線的自動化，我們普遍相信能提高軟體的質量，因為在中間的生產過程，都已經標準化了，不存在中間過程會因為某種人為的誤操作而導致錯誤，而往往這些錯誤都是非常嚴重而不容易發覺的。通常在開源專案裡，開發者人員流動是不能控制的，一套自動化的交付體系相當重要，它能大大降低入門的門檻。放在企業上，也應當如此。期望的結果是：乙個開發者能以低成本的進入專案，能盡快為企業創造價值。
把交付過程中一切能自動化的步驟都做到自動化，是整個持續交付的核心重點。
對於什麼崗位能完成這個自動化的生產線？因為要完成一條自動化的軟體生產線，大概需要以下要求：
要單獨完成生產線自動化，需要有全面技術知識的全棧工程師，否則就需要乙個devops團隊協作來完成。但是團隊協作相信沒有乙個全棧工程師來做來的有效率。若要用乙個團隊來做，也需要有個擁有多方面知識的協調牽頭的人領導才會成功。
這樣涉及到另外的問題：如何找到這樣的人？在我的經驗裡，企業中人員的跨領域性是不夠的，我們通常看到的問題是 「這個不應該是我負責」 之類的回應，內部提拔艱難重重。社會招聘，又因為全棧工程師往往被標籤為 「什麼都會、什麼都不會」，招聘對於面試考官的考驗更大。
面對老闆，自動化生產線沒有立即的回報，還有完成建立了自動化生產線後，這個人的價值是否就減退，甚至沒有價值了，成為疑問。但是，工廠的生產流水線也會因著不同情況來改造，同樣我相信軟體交付會因著不同新的技術情況而有所調整，達到持續改進的境地。
以上說的是對持續交付流程建設上的人員要求。
我們也需要討論的是，是否所有系統架構都能做持續交付？怎樣的系統架構能更好的支援持續交付的模式呢？
舉個極端例子：如果系統架構是依賴關係模糊不清，乙個簡單改動有可能導致系統崩潰的情況，這樣就算做了完美的持續交付流程，相信開發團隊也不會超過5人，因為這樣造成了另外一種入門門檻，真正的創新和創造價值的部分，達不到規模效益。但是，運帷團隊就可能有幾十人，因為要比較多的人手去救火。企業如果出現這種現象，相信距離死亡不遠了。
持續整合 部署 交付
持續整合是一種軟體開發實踐，即團隊開發成員經常整合它們的工作，通過每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建 包括編譯，發布，自動化測試 來驗證，從而盡早地發現整合錯誤 整合是指軟體個人研發的部分向軟體整體部分交付，以便盡早發現個人開發部分的問題 部署是 ...
持續整合 持續交付 持續部署
持續整合 持續整合強調開發人員提交了新 之後，立刻進行構建 單元 測試。根據測試結果，我們可以確定新 和原有 能否正確地整合在一起。持續交付 持續交付在持續整合的基礎上，將整合後的 部署到更貼近真實執行環境的 類生產環境 production like environments 中。比如，我們完成單...
持續整合 持續交付 持續部署
參考 1 continuous integration 持續整合 持續整合強調對於開發人員的每個提交，立刻進行構建 單元 測試。根據測試結果，我們可以確定新 和原有 能否正確地整合在一起。2 continuous delivery 持續交付 持續交付在持續整合的基礎上，將整合後的 部署到更貼近真實執...