App Store裡應用程式絕大多數都從整體規劃開始，程式人員陸續將功能與操作介面製作出來，當團隊準備將程式正式推出之前，就會交付給系統維護團隊負責監控關鍵指標，偵測異常立即通知。系統規劃、程式開發、系統維護等階段結合起來就是一套流程，這項流程整合多種不同技術，也有多種不同角色參與其中。我們可以將這段描述摘要下列關鍵字:
- 規劃 (Planning)
- 開發 (Development)
- 交付 (Deliver)
- 維護 (Operation)
- 流程 (Process)
- 角色 (People)
- 技術 (Technology)
DevOps最主要目的是讓不同角色能夠進行溝通、協調和合作的方式。所以，DevOps並不是技術、也不是產品、更不是服務，它是跨團隊合作的方式或架構。DevOps許多方法與架構是為了【寫程式的人】、【管理資訊系統的人】、和【負責資訊科技安全的人】而打造。假如讓這些團隊彼此找出一起參與專案的方式，理論上就能夠創造出安全又可靠的應用程式。
什麼是應用程式的生命週期 (Lifecycle)?
當你從App Store下載一款遊戲或任何一款app，它通常經歷過以下幾個階段：
- 產品經理與開發團隊討論用戶需求與功能需求
- 規劃與建構系統架構
- 開發系統功能
- 驗證與測試已開發功能
- 需求變更討論與管理
- 開發團隊交付應用程式給IT營運團隊
- IT營運團隊監控異常訊號
- 產品經理針對用戶使用情況，向開發團隊提出開發新功能或調整既有功能需求
- 再次回到步驟1，並且持續循環；或者，停止開發或停止營運應用程式
上述9個階段可以代表一項應用程式的生命週期，你也可以參考維基百科的定義。
DevOps與應用程式生命週期的關係
上一段描述應用程式生命週期提到相關共同利益者 (stackholders)，包含開發程式的設計師、監控系統的工程師、以及管理需求與功能的產品經理。當企業決定採行DevOps方式管理專案時，無論流程進行到哪個階段，至少這三種角色都是息息相關。
下圖節錄至Microsoft網頁，定義應用程式生命週期涵蓋的四個階段，包含：
- 規劃 (PLAN)
- 開發 (DEVELOP)
- 交付 (DELIVER)
- 營運 (OPERATE)
原則上，流程從【規劃】階段開始，結束於【營運】階段，最後再回歸到【規劃】階段，階段彼此之間具有關聯性，流程持續循環不止直到應用程式消失。
無論流程進行到【開發】或是【營運】階段，三種角色都仍參與其中，並從各自角色提出觀點與建議，也付出努力與貢獻成果。並不會因為進行到【開發】階段時，營運人員就完全不參與其過程；反之亦然。
DevOps則協助三種團隊彼此合作(Collaboration)的方法，擬定一套大家可運行的工作流程(Workflow)，遵循這些流程能幫助應用程式變得更安全與符合各項要求(Security & Compliance)，也能夠讓應用程式功能根據需求持續改進(Continuous Improvement)。
採用DevOps目的是什麼?
多數企業區分產品部門、IT部門和R&D部門，三個部門工作屬性、工作流程、部門目標、使用工具都不盡相同，從管理角度採用三個部門獨立運作與管立，這是再自然不過的事情。
產品部門負責規劃、分包工作、管理專案進度；R&D部門負責系統開發、修復臭蟲；IT部門負責監控系統、回報異常情況。彼此分工明確，長久一來多數企業也都是如此運作。
這種分工機制與工作流程的概念源自於製造業產線，產線是由多個關卡組合而成，關卡之間具有順序與關聯性，每道關卡需要達成任務皆不相同，但是每道關卡的存在都是為了製造最終且完整的產品而生。生產線工作流程的概念與分工方式是否就很類似企業內部部門之間的關係，生產線是生產力極大化的象徵產物，企業為了追尋員工生產力極大化，認為可以參考與仿造生產管理，這就是過去50年來企業經營的根本核心理念。
將製造產線成功經驗帶到企業其他部門管理，遭遇最嚴重、難解的根本問題是【人】。製造產線負責完成工作責任絕大多數落在【機器設備】，再搭配少量人的協助。【機器設備】不會有情緒、每天不需要花費1/3時間休息、幾乎不會犯錯、替換新設備沒有執行結果差異過大的問題。【人】卻充滿各種可能性，好的、壞的、不好不壞的都有。模擬產線管理的方式，再套用到員工管理的情境，管理機制十分符合【人】的邏輯，但執行起來的成果卻是天差地遠。
DevOps就是以【人】為根本而設計的管理與工作方式，這也是為何企業需要評估DevOps或採用它的目的。
