在雲中利用開源軟體進行開發以提高創新能力

導讀	企業可以在自己的雲平臺上利用開源軟體開發應用程式以提高創新能力，而無需為創新支付更多的費用。

企業可以在自己的雲平臺上利用開源軟體開發應用程式以提高創新能力，而無需為創新支付更多的費用。

在大多數企業中，最主要的成本是人力資源。但是透過智慧地利用開源軟體，可以顯著降低成本，即擁有GitHub的使用者群能夠為企業“免費”工作。但GitHub有6500萬個註冊使用者帳戶，必須假設其中大多數成員是開發人員。如果圍繞GitHub巧妙地構建，實際上可以讓這些開發人員都成為企業的人力資源，從而使企業的工作效率遠遠超過亞馬遜、Facebook和微軟等大型公司，並顯著降低成本。首先說明這個問題，以便了解這個解決方案。

一名資深的開發人員表示，在他曾經就職的一家公司有一個這樣的案例，有人克隆了一個開源git儲存庫，然後將其程式碼新增到該公司私有企業雲的git儲存庫中，然後對這個儲存庫進行修改。而在兩年之後，該公司的開發人員花費6周的時間進行更新，以使用其他開發人員在GitHub上建立的最新版本，並嘗試在這一過程中儘可能多地保留自定義功能。行業專家並不認同這個可能降低程式碼質量的做法，因為他所在的公司要負責程式碼質量。

如果可以的話，使用他所說的“Gitless Cloud Pipelines”要好得多。也就是在使用開源專案時，通常不會建立自己的git儲存庫，這意味著直接連結到開源git儲存庫。其結果是如果主要開源維護者釋出了新的開源版本，這樣一來只要想更新自己的軟體，就可以從開源儲存庫中提取並更改，因為新的開源版本是由主要開源維護者釋出的。這允許從企業內部利用開源軟體，這樣開發人員就可以不斷地改進他們自己的軟體，當然，這對於企業是免費的。

以這名開發人員展示在其日常工作中如何使用Magic為例。其中最關鍵的一點是，他從未克隆Magic，而是建立了一個直接指向Magic的GitHub儲存庫的Azure管道，並注意到了“Get sources”部分的一些特性。

需要注意原始碼如何指向GitHub，而不是Azure儲存庫。在上面的截圖中，只是將它直接指向主分支。在實時生產環境中，可能更願意將其指向特定標籤，除非與專案維護者有非常密切的關係。只是因為即使它是“主”分支，它仍然可能包含臨時提交。其標籤基本上是在建立專案的新版本時建立的，這通常可以更好地保證專案的穩定狀態，然後是一些隨機的主提交。

由於這名開發人員是Magic的主要維護者，因此對此很熟悉，因為非常清楚當前的“主”分支在任何特定時間點有多好。此外，他還關閉了管道上的CI觸發器，為提交到主分支的每個更改構建專案。最後一部分至關重要，因為不希望任何隨機提交觸發新構建，尤其是對於生產環境來說。這使得這一過程的自動化程度較低，因為必須人工觸發管道而不是使用CI觸發器，但這也能夠100%地控制從開放原始碼儲存庫建立新構建的時間。

之後，這個管道將克隆Babel和Babelfish。這些技巧允許在特定的最終結果中使用想要的任何Magic微服務填充模組資料夾。

這允許將模組動態安裝到Magic後端，作為管道的一個整合部分。

對於這個特定的管道，想為Magic啟用Windows自動身份驗證，只需在構建後端之前將NuGet包新增到核心即可輕鬆完成。

這允許使用任何插槽動態填充Magic後端，這些插槽是需要該特定管道的C#繫結。由於Magic的模組化，這實際上會改變Magic的行為，而不需要任何程式碼更改。

在部署後端後，將不得不應用變數替換，只需在主要部署操作上啟用JSON變數替換即可輕鬆完成此操作，然後在管道的變數部分中引用想要替換的變數。

需要注意的是，出於安全原因，無法展示它們的值，但它們會在部署後端時動態交換相關的“appsettings.json”值。

前端使用類似的機制構建，在Angular專案中有一個npmrun-script部分，可以參考它來建立生產構建。

誠然，前端有點混亂，因為Angular在構建過程中將所有內容打包到隨機生成的檔案中，因此很難在這裡智慧地引用變數，除非在其程式碼中對此進行了調整。因此為了簡單起見，在構建管道階段在這裡應用變數替換。這會降低靈活性，因為必須為每個環境構建變數，當然，假設需要在每個環境中覆蓋這些變數的話。但這對於這個特定專案來說並不是什麼大問題。

也可以使用替代機制，但這包括用看起來很奇怪的#{xxx}部分散佈Angular程式碼，使其無法在開箱即用的除錯/開發環境中使用，而無需先更改一大堆無用配置值。因此，對於Magic的額外“每個環境一個構建管道”要求的代價並不高，因為它能夠保持一切儘可能通用，零開發依賴性或配置要求使其在開發環境中工作。

基本上，這隻替換了一個變數，即後端的URL，當然可以與使用後端變數類似的方式建立這一變數，除了這發生在構建步驟中，而不是在部署步驟中。

也可以部署任何認為合適的方式。在日常工作的DEV環境中，只是在虛擬機器上使用IIS伺服器，因為這允許在一臺機器上部署30/50個Web應用程式，從而顯著降低了成本。當然，可能需要考慮採用其他應用程式，例如Azure WebApps等。

透過建立這樣的“Gitless雲系統”，直接指向開源GitHub儲存庫，可以不斷利用新增到這些專案中的任何創新，而不必採用人工進行合併更改。

然而，並非所有專案都可以使用這種方法，例如因為它們需要修改程式碼才能在環境中工作，不允許透過配置設定重寫其行為等。或者它們需要附加功能，並且不提供外掛架構，允許像Magic那樣動態注入動態功能。因此，該專案在其核心架構中必須是“超級敏捷”的，允許可能需要的任何方式攔截並新增到其核心。很少有GitHub專案在本質上像Magic一樣“敏捷”，所以這可能是一個挑戰。

如果放棄了對核心專案的所有控制權，這對於像Magic這樣的專案來說可能意義不大，因為它的靈活性和外掛架構。但是，不能再像控制在自己的git儲存庫中擁有原始碼的專案那樣“控制”專案。然而，大多數GitHub專案的開發人員和維護人員都非常願意接受提供給他們的變更請求。

或者，可以激勵專案背後的開發人員，以加快專案開發，並讓維護人員優先考慮問題。如果企業可以免費利用6500萬開發人員以及他們所有的創新，那麼在專案的開發人員和企業之間建立一種共生關係，可能是一種採用更多創新並且成本極其低廉的方法。

原文來自：