SOA中的持續交付

-1

持續交付如何饋送到SOA體系結構中？SOA中的持續交付

由於每個SOA服務應該是獨立的，這是否意味着我們需要每個服務的單獨管道？當有100多種服務時，這會如何影響？

我們可以將服務分組爲可部署單元來分組服務。

我看到的最大問題是在測試100年代的不同版本配置設置。

有沒有一個模型基於此？

2015-02-23 IanWatson

這真的取決於我的猜測。在一個組織中，他們擁有不同的測試方法，具體取決於這些服務在SOA目錄中的位置。例如，技術服務（如發送郵件服務）已經進行了獨立測試，帳戶級服務和SAP級服務通常作爲一組進行測試以減輕負載。這完全取決於您的SOA治理策略。如果沒有這些地方......它會變得凌亂。 – Namphibian 2015-02-24 21:56:13

如果您有一個微服務架構，其中服務是鬆散耦合的，您應該理想地進行集成測試，可以「黑盒」測試已更改的單個服務。在這種情況下，您可以輕鬆爲每個服務構建一個單獨的管道。每次更改1個或2個組件時，您確實不希望部署100個不同的組件。
通過單獨的管道，我並不是指每個服務的單獨部署代碼庫。您可以概括您的容器和服務，以便自動部署代碼。
即將到來的配置，你應該使用restful框架分離出SOA。在這種情況下，組件之間沒有緊密耦合，而且煙霧測試可以輕鬆確定特定服務的prod部署是否成功。

來源

2015-03-31 03:27:34

我看不到100個獨立管道是如何管理的。尤其是在服務之間存在依賴關係的情況下，如編排服務。 – IanWatson 2015-03-31 11:42:07

我們有40個不同的服務，我們的部署是動態的，以處理個別服務部署。訣竅是擁有一個通用的部署代碼，這樣你只需要傳入一個服務名稱作爲參數，其餘的流程就會自動完成。您甚至可以使用基於容器（例如docker）的部署來實現此目的 – 2015-03-31 14:30:57

就持續交付而言，當我想推送發行版時，可能會在不同服務上進行多項更改。說我們有＃1 - 服務A更新＃2 - 服務B更新＃3 - 服務C更新我想在點擊按鈕，釋放從以前版本的所有變化。例如，如果以前的版本是＃1，並且＃2和＃3可用。我想單擊包含＃2和＃3的「build＃3」（自上次發佈以來的所有更改）我不明白這是不同管道的「可用」。 – IanWatson 2015-03-31 20:16:00

SOA中的持續交付

回答

相關問題