一千萬個為什麽

搜索

如何向非技術人員解釋十二個因素?



The Twelve Factors is a sort of manifesto seen as a road-map for developers to follow when building modern web-based.

你如何用不到三句話向隨機人解釋12個因素中的每一個?

轉載註明原文: 如何向非技術人員解釋十二個因素?

一共有 2 個回答:

<�強>予。代碼庫</強>

     

在版本控制中跟蹤了一個代碼庫,許多部署

版本控制系統(VCS)

<�強> II。依賴</強>

     

明確聲明並隔離依賴項

使用包管理器工具

<�強> III。配置</強>

     

在環境中存儲配置

環境變量

<�強> IV。支持服務

     

將支持服務視為附加資源

如果數據庫之類的其他服務發生更改,則代碼不應更改。

<�強>訴構建,發布,運行

     

嚴格分開構建和運行階段

  • 唯一版本ID
  • 必須為每次更改創建新版本

<�強> VI。過程</強>

     

將應用程序作為一個或多個無狀態進程執行

...

<�強> VII。端口綁定

     

通過端口綁定導出服務

...

<�強> VIII。並發</強>

     

通過流程模型擴展

...

<�強> IX。處理性</強>

     

通過快速啟動和正常關閉來最大化穩健性

一次性的。服務是否下降並不重要。如果服務中斷,則由多個服務組成的平臺能夠繼續,例如,數據不會丟失。重新啟動服務後,平臺可以繼續運行而不會丟失數據。

<�強> X。開發/生產平價

     

使開發,舞臺和制作盡可能相似

  • 節省時間:您不必考慮,驗收數據庫駐留在哪裏或此應用程序在測試環境中的位置。如果對dev,test和acc中的系統應用相同的結構,則每次使用這樣的環境時都不必考慮這將節省時間

  • 減少錯誤數量:如果開發環境與生產類似,錯誤數量將減少,因為錯誤主動在錯誤階段解決錯誤的可能性更高

<�強> XI。日誌</強>

     

將日誌視為事件流

  • 標準輸出
  • 將所有日誌存儲在日誌管理器中,例如splunk

<�強> XII。管理流程

     

將管理/管理任務作為一次性流程運行

...


討論</強>

我們是6個開發者的創業公司,我們的老板是前運動員

...

誰應該閱讀此文檔?

     

任何開發人員構建作為服務運行的應用程序。行動   部署或管理此類應用程序的工程師。

...

https://en.wikipedia.org/wiki/Software_rot

軟件隨著時間的推移逐漸惡化,最終會導致   它變得有缺陷[或]無法使用“而且,重要的是,”軟件   實際上並沒有腐爛,而是缺乏存在   根據其所處的不斷變化的環境進行了更新。

...

Manager: Why do you want to apply 12factor?

Team: The 12factor prevents software rot, i.e. more bugs, unstable software resulting in less customer satisfaction, less revenue.


結論</強>

而不是解釋12因子,最好解釋如果不應用12因子將會發生什麽,即軟件腐爛。 12因子適用於開發者和行動者,而非管理者。


<�強>參考</強>

  1. http://www.clearlytech。 COM/2014/03/04/12因子應用-通俗英語/
  2. https://12factor.net/
  3. https://thenewstack.io/12-factor-app-簡化的應用程序的開發/

據我所知,您希望您的高層管理人員支持您為您公司的軟件開發引入12因素方法。

在這方面,你想要向他們解釋12個因素中的每一個。如果他們真的對此感興趣,那麽您可以將他們在您的問題中鏈接的12因素網站發送給他們 - 它已經有一句話摘要。

我會回答你在標題中寫的問題:

如何向非技術人員解釋十二個因素?

十二個因素不是一個軟的“文化”。它是一組具體,實用且相當低級的技術,用於解決與配置管理,部署和應用程序高可用性相關的問題。而不是“文化”或“方法論”,我寧願稱之為模式,或者是開發人員的一種手冊。它顯然與DevOps,雲和類似的流行語有關,但不一定如此 - 如果你只有一個開發人員做他自己的事情,你也可以使用這些技術,即使沒有雲或其他“現代”環境。

甚至沒有必要讓管理層參與是否采用12個因素中提到的部分或全部技術。其中許多只是最佳實踐,每個開發(“服務”式)軟件的人都會在這些年裏結束。這在 I中非常明顯。代碼庫III。配置XI。日誌。沒有經理人需要開綠燈來采用這些做法。

其他原則,即 II。依賴性IV。支持服務VI。流程VII。端口綁定VIII。並發IX。可處理性整齊地組合到關鍵字“microservices”中。不要向您的管理層解釋這些細節,但要告訴他們您將從之前可能的單片應用程序架構遷移到基於微服務的架構。在管理層面,這可以通過圖形表示充分完成(一方面是一大堆復雜的軟件 - 另一方面是幾個單獨的小塊軟件)。你可以用非技術術語解釋為什麽後者可以更好地完成手頭的工作;每個經理都可以理解將大量復雜的代碼劃分為更小的部分的概念,這些部分可以更容易地處理(和縮放)。

您的管理層想知道它的成本和需要多長時間。 12因素告訴你什麽都沒有。雖然某些因素涉及一些成本(例如,建立中央日誌存儲),但成本很低,以後很容易被節省。其他成本可能是開發人員接受一些更難處理的部分所需的時間(即II,VII,IX,具體取決於您已有的軟件數量)。

非常重要:在具有大型單片應用程序的環境中工作非常簡單,只需使用完整的12因子方法添加 new 內容,或者隨時轉換原始軟件中的碎片。如果您有時間或金錢限制,這可能更明智。