什麼是 DevOps 開發維運？

DevOps 開發維運是一種不斷進化的理念與架構，可鼓勵客戶更快、更妥善地開發應用程式，更快地發行新的或修改過的軟體功能或產品。

DevOps 實務做法可促進更順暢且持續的通訊、協同作業、整合、可見度，以及應用程式開發團隊 (Dev) 與 IT 營運團隊 (Ops) 之間的透明度。

「Dev」（開發）與「Ops」（營運）之間的密切關係貫穿於 DevOps 生命週期的每個階段：從初始軟體規劃到程式碼編寫，建置、測試與發行階段，再到部署、營運與持續監控。這種關係推動了客戶持續的意見回饋循環，進一步改善、開發、測試及部署。這些努力的成果之一，即是可以更快且持續地發佈必要的功能變更或新增項目。

有些人將 DevOps 目標分為四大類：文化、自動化、測量和共享（CAMS），而 DevOps 工具可在這些領域提供輔助。這些工具可讓開發與營運工作流程更精簡、更具協同合作性，將先前耗時、手動或靜態的工作自動化，這些都是涉及整合、開發、測試、部署或監控的工作。

除了努力打破障礙，讓開發與 IT 營運團隊之間的溝通與協同作業順利之外，DevOps 的核心價值就在於客戶滿意度和更快創造價值。DevOps 也設計為助推商業創新，推動流程持續改善。

DevOps 實務可讓企業組織的終端客戶更快、更好、更安全地創造商業價值，該價值可能表現在更頻繁推出產品版本、功能或更新的形式上。這可能涉及產品版本或新功能多快送達客戶手中，而且具有適當的品質和安全性。或者，它可能著重於多快可以找出問題或錯誤，然後解決並重新發佈發行。

底層基礎架構也支援 DevOps，確保軟體在初步開發和測試後正式投入生產時，具有順暢的效能、可用度和可靠性。

有幾種常見的 DevOps 方法，組織可以運用來加速及改善開發與產品版本。這些方法採取軟體開發方法學和實務做法的形式，其中最受歡迎的是 Scrum、Kanban（看板）、Agile（敏捷）：

• Scrum：Scrum 定義團隊成員應如何合作，以加速開發與 QA 專案。Scrum 實務做法包括關鍵工作流程和特定術語（衝刺、時間方塊、每日 Scrum [會議]），以及指定角色（Scrum Master、產品擁有者）。
• 看板：Kanban（看板）源自豐田車廠用於提高效率的生產方式。看板方法規定應在看板上追蹤軟體專案在製品 (WIP) 的狀態。
• 敏捷：早期 Agile（敏捷）的軟體開發方法仍持續嚴重影響著 DevOps 開發維運的實務做法和工具。許多 DevOps 開發維運方法（包括 Scrum 和 Kanban）都納入了靈活程式設計的元素，例如這些靈活的實務做法可能是關於更快回應瞬息萬變的需求和要求、將要求記錄為使用者案例、執行每日例行工作，以及納入持續的客戶意見回饋。Agile 的實務做法也規定了較短的軟體開發生命週期，而非冗長的傳統「瀑布式」開發方法。

DevOps 實務做法的追隨者通常會將某些 DevOps 友善的工具當成 DevOps「工具鏈」的一部分。這些工具的目標是進一步簡化、縮短及自動化軟體交付工作流程的各個階段（或稱「管道」）。許多這類工具也推廣自動化、協同作業，以及促進與營運團隊之間整合等核心 DevOps 原則。以下是各種 DevOps 生命週期階段所使用的工具範例。

• 規劃：此階段協助定義商業價值和要求。範例工具包括 Jira 或 Git，用於協助追蹤已知問題並執行專案管理。
• 程式碼：此階段涉及軟體設計和軟體程式碼的建立。範例工具包括 GitHub、GitLab、BitBucket 或 Stash。
• 建置：在這個階段，您可以管理軟體版本，並使用自動化工具來協助編譯及封裝程式碼，以便日後發佈到正式生產環境。您可以使用來源程式碼儲存庫或套件儲存庫，也就是產品發行所需的「套件」基礎架構。範例工具包括 Docker、Ansible、Puppet、Chef、Gradle、Maven 或 JFrog Artifactory。
• 測試：此階段包括持續測試（手動或自動化），以確保最佳程式碼品質。範例工具包括 JUnit、Codeception、Selenium、Vassenium、TestNG 或 BlazeMeter。
• 部署：此階段可能包含協助管理、協調、排程及自動化產品發佈至正式作業環境的工具。範例工具包括 Puppet、Chef、Ansible、Jenkins、Kubernetes、OpenShift、OpenStack、Docker 或 Jira。
• 營運：此階段管理正式作業期間的軟體。範例工具包括 Ansible、Puppet、PowerShell、Chef、Salt 或 Otter。
• 監控：此階段涉及從正式作業中的特定軟體版本找出問題並收集相關資訊。範例工具包括 New Relic、Datadog、Grafana、Wireshark、Splunk、Nagios 或 Slack。

DevOps 實務做法反映了持續改善和自動化的概念。許多實務做法都聚焦在一或多個開發週期階段，這些實務做法包括：

• 持續開發：這項實務做法涵蓋 DevOps 生命週期的規劃與編碼階段，可能涉及版本控制機制。
• 持續測試：這項實務做法結合了自動化、預先排程、持續程式碼測試，因為應用程式程式碼還在撰寫或更新當中。這類測試可加快將程式碼交付至正式作業環境。
• 持續整合 (CI)：這個實務做法將組態管理 (CM) 工具與其他測試與開發工具結合在一起，藉此追蹤所開發的程式碼可投入生產的整備度。過程中會要求在測試與開發之間迅速提供意見回饋，以便快速識別及解決程式碼問題。
• 持續交付：這項實務做法可將測試後的程式碼變更自動傳送至正式作業前環境或接移環境。接著，員工可能會決定將此類程式碼變更推廣至正式作業環境。
• 持續部署 (CD)：這項實務做法與持續交付類似，可將新程式碼或變更的程式碼自動發佈至正式作業環境。執行持續部署的公司，可能每天會發佈程式碼或功能變更數次。如果使用 Docker 和 Kubernetes 等 Container 技術，將可協助維持不同部署平台和環境中程式碼的一致性，進而實現持續部署。
• 繼續監控：這項實務做法包括持續監控作業中的程式碼，以及支援該程式碼的底層基礎架構。藉由意見回饋迴圈回報錯誤或問題，然後再回到開發階段。
• 基礎架構即程式碼：這項實務做法可在各種 DevOps 階段使用，以便自動化執行軟體版本所需的基礎架構資源配置。開發人員可從現有的開發工具中新增基礎架構「程式碼」。例如，開發人員可以根據需求，從 Docker、Kubernetes 或 OpenShift 建立儲存容量。這項實務做法也可讓營運團隊監控環境組態、追蹤變更，並簡化組態的復原作業。

DevOps 的擁護者提出多項商業與技術效益，其中許多效益可能讓客戶更滿意。DevOps 的一些效益包括：

• 產品交付更快、更好
• 更快解決問題並降低複雜度
• 擴充性和可用度更高
• 作業環境更穩定
• 資源使用率更高
• 自動化程度更高
• 更清楚掌握系統成果
• 推動更偉大的創新

許多簡化軟體開發與部署的 DevOps 方法，都是敏捷軟體開發與精實程式設計的早期基礎。但 DevOps 最初是從數個基層運動進化而來，其目的是協調開發人員及其營運團隊的活動。

在 20 世紀早期，我們發現必須維持 Google 和 Flickr 等熱門網站的可用度，以因應大量的點擊。這項需求促使公司使用軟體可靠性工程師 (SRE)，讓營運人員能與開發人員密切合作，以確保在程式碼正式投入生產後，網站能持續運作。

2009 年，Flickr 工程師 John Allspaw 和 Paul Hammond 在會議上提出他們自己的 DevOps 方法。當時，他們的演講主題是「每天 10 次以上部署：Flickr 的開發與營運合作」。同年，Patrick Debois 在比利時舉辦了第一個「DevOps 日」。隨著世界各地陸陸續續舉辦更多 DevOps 日，也加入了 #DevOps 主題標籤，並獲得了強勁的發展動能。

之後幾年，產業和開放原始碼工具與架構也相繼開發並提出，進一步推動 DevOps 的目標。

NetApp 透過 DevOps 開發維運協助促進更好的業務成果：營運團隊能以更少的工程技術提供自動化的基礎架構，而開發人員則能在可靠且可預測的環境中更順暢地開創產品與服務。借助 NetApp® 技術，您就能安心地提供組織所需的服務與功能，以在內部部署與雲端環境中發揮最大的開發人員生產力。

NetApp 讓開發人員、測試、QA 和營運團隊都可以輕鬆地使用基礎架構資源（例如持續儲存 Volume）做為程式碼，而且全部可以從 DevOps 開發維運管道中的熟悉工具進行。範例包括 NetApp 儲存 API 和 IAC 與 Puppet、Ansible、Docker、Kubernetes 和 OpenShift 等工具的整合。

但 NetApp 不只讓開發人員能夠輕鬆地將儲存資源當成程式碼使用，。NetApp 技術也能讓營運團隊自信地為開發與測試人員配置並提供資源。開發人員和測試人員接著可以自行配置快照或複本等快速、省時的儲存功能資源，藉此加速程式設計與測試週期。有了這些功能，即時正式作業資料或程式碼集的複本就能在幾秒或幾分鐘內以程式碼的形式配置資源，進而加速開發和 QA 工作流程。深入瞭解為何 NetApp 是專為 DevOps 而生。

為何 NetApp 是專為 DevOps 而生

NetApp 對社群的承諾延伸至 thePub。這個開發人員社群鼓勵協同作業、分享秘訣和技巧，並就最新的 DevOps 實務做法和傳輸協定互相切磋。