最近和一位朋友討論持續集成、持續交付在企業的具體價值，和具體執行時的崗位要求，比較值得讓我們思考。
我看的持續交付（Continuous Delivery），主要實現一套自動化的軟件生產線，在生產線的開端，是程序員提交代碼，而生產線的產出物就是要交付的東西：
- 如果企業是需要運營一個平臺的，交付的就是一個更新後的平臺；
- 如果企業是交付APP的，最終交付的應該是發佈到市場上的APP；
- 如果企業是做軟件產品的，刻錄到DVD上的，最終交付的可能是一個ISO文件。
能在整個交付的流水線的自動化，我們普遍相信能提高軟件的質量，因爲在中間的生產過程，都已經標準化了，不存在中間過程會因爲某種人爲的誤操作而導致錯誤，而往往這些錯誤都是非常嚴重而不容易發覺的。通常在開源項目裏，開發者人員流動是不能控制的，一套自動化的交付體系相當重要，它能大大降低入門的門檻。放在企業上，也應當如此。期望的結果是：一個開發者能以低成本的進入項目，能儘快爲企業創造價值。
把交付過程中一切能自動化的步驟都做到自動化，是整個持續交付的核心重點。
對於什麼崗位能完成這個自動化的生產線？因爲要完成一條自動化的軟件生產線，大概需要以下要求：
- 在企業裏有一定權力調動資源
- 對軟件開發流程熟悉，知道每個環節的輸入、輸出、難點
- 熟悉產品的交付時使用的工具（maven, nexus/artifactory, scp, shell-scripting, make, msbuild之類）
- 熟悉虛擬化技術（因爲有可能需要啓動一個虛擬環境做驗收測試後纔可以上線）
- 熟悉配置管理工具，如puppet、chef、cfengine等
- 對系統安全、保安方面有一定理解和執行能力（不能因爲某員工的惡意干預導致生產線出問題）
要單獨完成生產線自動化，需要有全面技術知識的全棧工程師，否則就需要一個DevOps團隊協作來完成。但是團隊協作相信沒有一個全棧工程師來做來的有效率。若要用一個團隊來做，也需要有個擁有多方面知識的協調牽頭的人領導纔會成功。
這樣涉及到另外的問題：如何找到這樣的人？在我的經驗裏，企業中人員的跨領域性是不夠的，我們通常看到的問題是 “這個不應該是我負責” 之類的迴應，內部提拔艱難重重。社會招聘，又因爲全棧工程師往往被標籤爲 “什麼都會、什麼都不會”，招聘對於面試考官的考驗更大。
面對老闆，自動化生產線沒有立即的回報，還有完成建立了自動化生產線後，這個人的價值是否就減退，甚至沒有價值了，成爲疑問。但是，工廠的生產流水線也會因着不同情況來改造，同樣我相信軟件交付會因着不同新的技術情況而有所調整，達到持續改進的境地。
以上說的是對持續交付流程建設上的人員要求。
我們也需要討論的是，是否所有系統架構都能做持續交付？怎樣的系統架構能更好的支持持續交付的模式呢？
舉個極端例子：如果系統架構是依賴關係模糊不清，一個簡單改動有可能導致系統崩潰的情況，這樣就算做了完美的持續交付流程，相信開發團隊也不會超過5人，因爲這樣造成了另外一種入門門檻，真正的創新和創造價值的部分，達不到規模效益。但是，運帷團隊就可能有幾十人，因爲要比較多的人手去救火。企業如果出現這種現象，相信距離死亡不遠了。