關于DevOps的10個"最佳實踐"
在2015年6月，Gartner預測，“到2017年底，手機APP開發服務的市場需求將比內部IT組織提供的能力要快至少五倍。”事實上，企業已經看到他們的app工作量飆升。因此，更多的組織采用DevOps - 一種通過讓app開發人員和運維專家在端到端的應用程序開發和部署過程中進行協作來加快應用程序開發和交付的方法。這里有在組織中得到認可的10個DevOps“***實踐”。
1. 打破IT中的壁壘
打破IT職能間的功能壁壘必須來自上級管理層，因為IT已經被組織成職能豎井幾十年了。在這種環境下，應用程序開發工作歷來是采用裝配線方法(瀑布流模式)，其中一個部門構建app，然后將應用程序發送到運維組集成，接著app由QA組進行測試，之后該app回到運維組部署。
這種功能分離限制了協作，帶來了延遲部署應用程序的問題。為了更快地交付今天的app，IT經理已經開始將IT重組為DevOps團隊，這些團隊是所有IT方法論的組合，每個團隊都會對特定類別的app負責。
2. 調整績效評估
當IT文化需要“脫軌”時，通過團隊績效和個人參與的團隊績效評估，可以大步走進這個過程。為開發人員和運營人員提供更多的績效評估，使他們的團隊能夠滿足app開發和部署目標。
3. 構建項目的實時可見性
當前項目管理軟件現在已經具有內置的自動化功能，可以減輕項目更新的麻煩。項目管理工具可以提供對應用程序的實時可見性，以及提供開發部署過程中的準確位置。它還可以顯示當前任務的人員和任務關鍵資源(看板)。項目管理軟件可以作為跨職能IT團隊的“單一版本”(對所有可見，統一理解)，使項目協調工作變得更加容易。
4. 隨時隨地使用軟件自動化
您可以通過選擇與IT環境兼容的應用程序自動化工具集來縮短時間，錯誤和成本。這種自動化可以擴展到應用程序源代碼開發，系統和中間件配置，甚至數據庫和網絡更改。在部署前的重要的類生產測試，如回歸測試和負載測試也可以自動化。這樣可以節省開發人員和運維人員的時間和精力。
5. 選擇相互兼容的工具
DevOps使用工具和自動化的另一個注意事項是工具在應用程序和系統兩個級別上產生的狀態信息不會沖突。從單一供應商選擇工具通常更為有效，因為這些工具已經彼此緊密集成。這樣可以改善app開發人員在應用程序的健康狀況下收到的狀態，與運維人員在其app中看到的內容一致。
6. 從小而成功的項目開始
CIO希望IT文化脫離壁壘，就需要確保新整合的DevOps工作團隊能夠取得一些快速的成功。這樣會建立了他們對新方法的信念和合作。切忌貪大求全，需要有單點突破的能力，甚至說構建完整的持續交付流水線都是錯誤的。這個地方的方法是整體設計，分塊構建，對于每個角色來說以高頻交互場景為優先切入點。
7. 別忘了用戶!
您正在開發的應用程序是最終業務。沒有業務利益相關者的關鍵支持，您的DevOps工作將會面臨失敗。從您坐下來與他們定義應用程序需求的那一刻，原型開發，單元測試集成/回歸測試，培訓和部署整個DevOps進程都要包含最終用戶。這種包含是以用戶的價值為依歸，從用戶的角度出發，考慮其在業務連續性、可用性、用戶體驗、滿意度等多方面的要求。今天看來，讓用戶參與設計，是一種detailed 設計方式，可以借助一些輕量級的技術手段，比如說A/B測試來減輕和加速這個過程。
8. 協同管理變更
當多方合作開展快速發展的開發工作時，其中涉及原型設計和其他工具，app的更改即將發生。這就是為什么一個有效的變更管理過程對每個DevOps項目至關重要。當app需要更改的那一刻，這個請求應該面向團隊中的每個人，無論他們工作在哪個IT環節上。這種溝通也應該指向最終用戶利益相關者。分布式研發管理模式下，工具非常重要，采用一個分布式管理工具、自動化構建和測試工具都是為了提高協同的效率。
9. 持續部署應用程序
DevOps在持續應用部署模式中最有效，其中網站不要等待將各種增強功能捆綁到獨立的軟件版本中，而是選擇不斷修改和交付修訂的應用程序(基于MVP，增量迭代式的開發模式)。一個具有強大變更管理系統的app持續交付模式使得新的app功能更快速的交付業務。變更管理平臺需要有灰度發布、A/B測試的能力，而不是更多的靠人為來保證。
10. 在公司內創建一個服務環境
IT溫室時代已經結束了。 為了做好面向業務的交付，IT部門必須牢記業務用戶需求，并交付滿足或超過功能和上市時間預期的app。 如果改變文化可以強調團隊精神的價值，開放式溝通和客戶滿意度的承諾，即使客戶駐留在相鄰的辦公室也可以這樣做。總而言之，要把自己的服務意識放在離客戶最近的地方。
【本文是51CTO專欄作者“王津銀”的原創稿件，轉載請注明出處】
