一千萬個為什麽

搜索

更進一步的DevOps操作模式是什麽?



似乎很多人嘗試使用DevOps工具模型來定義軟件開發過程,但沒有對齊;我仍然認為這是一個更成熟/一致的問題,而不是品味問題。

Question: What are further known DevOps operation models?

我在可用的熱門資源中看到了一些例子:

  • 計劃,開發,測試,發布,操作

  • 計劃,代碼,構建,測試,發布,部署,操作,監控

  • 需求,開發,構建,測試,部署,執行

以下是維基百科頁面中 DevOps工具鏈的引用:

DevOps工具鏈是一組或多種工具的組合,有助於貫穿整個軟件開發生命周期,由使用 DevOps 練習。     通常,DevOps工具適用於一項或多項支持特定DevOps計劃的活動:計劃,創建,驗證,預生產,發布,配置和監控。     另一個提議的工具鏈模型在2014年被引用為來自“未知來源”的計劃,代碼,構建,測試,發布,部署,操作和監控。

但是,同一個維基百科頁面也包含一個看起來像這樣的圖像:

Devops Toolchain stages on Wikipedia

此圖像IMO與該頁面上的文字不相關。

DevOps維基百科上的工具鏈階段,作者:Kharnagy - 自己的作品,CC BY- SA 4.0維基百科

Sources: https://devops.com/devops-2017-cdos-care/

轉載註明原文: 更進一步的DevOps操作模式是什麽?

一共有 2 個回答:

你的問題似乎沒有對它所涉及的平臺/操作系統做任何假設。這就是為什麽在大型機環境中添加有關這種工具鏈的一部分的解答的原因。我的回答是基於使用我最熟悉的SCM產品(不知道是否需要公開產品名稱)。

關於“計劃,代碼,構建,測試,發布,部署,操作,監控”的示例似乎缺少以下關鍵階段:

  1. Enforce predictable problems in production to be addressed before they actually have an impact in production (sounds like sales talk, no?). You might think this is just "impact analysis", but that is not it:

    • Impact analysis is what you do in the plan-phase (we all know that, right?).
    • Audit (= name of the phase we use for it), is around the time that the developer thinks/claims to be ready. Something like "unless there is anything else that may have happened in production while I was working on my change, I'm done and recommend to move forward". Think of things like "version regression issues". Eg because last night a fix was applied to production and you didn't retrofit that fix, so if you move forward with your change, you'll wipe out the fix again ... bad luck if you do!
  2. Give me a red button, so that if anything else fails (and production is impacted), I just have to push a magic button, be patient (for a few secs) and be 100% sure a rollback completed with 0 rebuilds of any kind (= Backout is the name of the phase we use for it).

    This boils down to "component level backups" of any files/components you will be updating by your change in production, whereas these backups are made at the very moment the change is going to be applied. and this for any type of artifacts included in the change.

    If later on (5 mins, 2 days or 1 week later) something goes wrong in production, and it turns out to be caused by your change, all you have to do is to have an automated procedure (the red button!) in place that you can launch, and which simply restores the backup you should have available.

    Attention, if there were database updates involved, this backout may not be an option anymore. While things like "backups overlaid" (because of concurrent changes/fixes got applied to production) is another scenario where the red button is no longer available.

Easy, no?

PS:如果我的回答是肯定或不符合DevOps標準,我將根據每個人的判斷進行判斷。

我不認為你提到的圖像真的與相應的文字相矛盾。從同一頁面上的 Preprod 部分(重點介紹):

<�強> Preprod </強>

     試生產或“preprod”是指涉及的活動   發布已準備好部署,通常也稱為分段或   的包裝</強>