devops最近成了熱詞，望文生義，你也能猜個**不離十，它就是在說\"研發團隊\"與\"運維團隊\"之間的那點事兒。那麼，到底什麼是\"devops\"呢？
\ wikipedia上說：\"devops是軟體開發、運維和質量保證三個部門之間的溝通、協作和整合所採用的流程、方法和體系的乙個集合。它是人們為了及時生產軟體產品或服務，以滿足某個業務目標，對開發與運維之間相互依存關係的一種新的理解。\"這恰好體現了精益管理中的客戶價值原則，即：以客戶的觀點來確定企業從設計到生產交付的全部過程，實現客戶需求的最大滿足。我們也可以把devops看作是一種能力，在缺乏這種能力的組織中，開發與運維之間存在著資訊\"鴻溝\"。
\ 如何獲得這種能力呢？關鍵有兩點：一是全域性觀：要從軟體交付的全域性出發，加強各角色之前的合作；二是自動化：人機互動就意味著手工操作，應選擇那些支援指令碼化、無需人機互動介面的強大管理工具，比如各種受版本控制的script，以及類似於nagios這樣的基礎設施監控工具，類似於puppet、chef這樣的基礎設施配置管理工具。
\\ 既然devops關注於價值交付的全過程，那就讓我們看看該產品線常見的交付過程吧。
\ 對於單個專案來說，它大體上是乙個典型的瀑布開發過程。首先是需求收集與整理，撰寫mrd(marketing requirement document)或總體設計後，進行評審。如果涉及到多模組，每個模組的開發人員會對各自負責的模組進行詳細設計，給出大致的開發計畫，並商定聯調時間點。之後，開發人員會從主幹上拉出專案分支，並在該分支上進行開發。當到最後聯調點時，幾個開發人員才會在將**合在一起，進行聯調。當調通之後，開發人員再申請提測。測試人員接到提測申請單後，進行測試，記錄bug，通知開發人員修復，直致質量達到標準。之後，開發人員會填寫上線申請單，經運維人員確認後，運維人員操作進行上線部署工作。如圖所示。
\ 開發的複雜性還在於：該產品線有很多並行專案，為了避免互相干擾可能帶來的衝突，每個專案啟動後都會重新在主幹上拉出分支，在上線前才進行合併。如下圖所示。
\ 另外，並行專案太多，導致每個開發人員會同時參與多個處於不同階段的專案。那些週期較長的專案雖然會被分解成多個迭代，但每個迭代內都是同樣的開發流程，只是最後僅有一次上線而已。
\ 總而言之，突出的問題表現在：
\ 同一角色多個人員的合作開發；\
各角色部門之間的協作以各自的產品物為目標，如mrd、產品**、測試用例、上線操作單；\
基於人機互動方式的內部流程管理平台。\
\ 從精益思想出發，為了盡早交付價值，必須首先找出整個流程中的浪費，並將其消除，從而提高流程效率，讓\"乙個想法從提出到實現\"可在最短時間裡完成。那麼，浪費到底表現在**呢？\
另外，該產品的乙個重要特徵是需要不斷地嘗試調整程式演算法策略，以得到最佳的流量效果，而這種調整的頻率較高（至少每週一次）。當需要調整策略時，開發人員修改**後重新進行編譯打包，由於產品**發生變化，所以測試人員仍需要進行大量的回歸測試，而運維人員在部署時也需要將對二進位制檔案包進行整體部署，整個週期比較長。
\ 從上面這些內容中，我們不難發現，流程中更傾向於將問題推遲到後面解決（比如最後整合聯調），將工具（平台、郵件、即時通訊）作為協作的基礎，而角色間的溝通幾乎完全依賴於前乙個環節的產物（比如mrd、產品**、上線步驟）。那麼我們使用哪些對策進行優化，達到消除浪費的目的呢？
\\\\
新的開發流程如下圖所示。
\ 分支開發策略變更為single branch模式。
\\ 通過以上改進措施，讓團隊的合作方式發生了重大變化，從\"碉堡防禦\"走向了\"戰線統一\"。
\ 原來，各角色僅關注於自己本身的工作，雖然大家都同處於乙個專案中，但各自劃分了\"領地\"，產品經理就應該將mrd寫得清清楚楚，如果開發人員認為不清楚，那就回去再改。開發人員只管按照mrd上的內容進行開發，很少考慮可測性和易測性問題。測試人員只管按照mrd中內容來測試，有問題通過內部工作流平台提交問題單。運維人員只管根據開發人員提交的上線操作單進行操作。似乎各角色之間的溝通介質只有各自的\"交付物\"。
\ 現在，各角色都能夠共同合作，以專案的最終交付為目標，積極討論需求，優化實現。因為角色之間的這種緊密合作讓所有人對不同角色都有了深入的了解。開發人員耐心為產品經理解釋技術實現，說明計畫安排，測試人員與開發人員共同討論驗收條件，避免遺漏需求。開發人員讓運維人員了解架構設計， 細心聽取運維人員的建議，進行技術改造，使部署工作更快捷有效。
\ 通過這些活動，大家都認識到原有內部管理平台僅是個公文流轉的支撐平台，要想提高工作效率，就要將這種\"辦公自動化工具\"進一步提公升為\"全面自動化工具\"，使所有人更關注於端到端的價值，而非各角色之間的分界點。
\\ 感謝熊節對本文的審校。
\
DevOps，不是乙個傳說！
devops，不是乙個傳說！wikipedia上說 devops是軟體開發 運維和質量保證三個部門之間的溝通 協作和整合所採用的流程 方法和體系的乙個集合。它是人們為了及時生產軟體產品或服務，以滿足某個業務目標，對開發與運維之間相互依存關係的一種新的理解。這恰好體現了精益管理中的客戶價值原則，即 以...
艾偉也談專案管理，DevOps，不是乙個傳說！
devops最近成了熱詞，望文生義，你也能猜個 不離十，它就是在說 研發團隊 與 運維團隊 之間的那點事兒。那麼，到底什麼是 devops 呢？wikipedia上說 devops是軟體開發 運維和質量保證三個部門之間的溝通 協作和整合所採用的流程 方法和體系的乙個集合。它是人們為了及時生產軟體產品...
你不是乙個前端
mentor 你不是乙個前端 我 mentor 你不要老想著自己是乙個前端，你不是乙個前端 我 可是把我招來不就是寫前端的嗎？mentor 你可以寫前端，但是你不要限制自己只作為乙個前端，不要把自己的眼光侷限在前端。你應該從整個專案 從工程的角度blablablabla.我 打斷 不，我就是一名前端...