關鍵要點
- 無論你目前使用什麼樣的技術棧，DevOps都是值得一試的。
- 閉源、專有軟件和構建過程與DevOps實踐不兼容。
- .NET Core是開源的，是基於DevOps構思和構建的。
- .NET Core CLI和Roslyn API讓整個交付流程變得更加開放，且具有更強的適應性強。
- 自動化是DevOps的重要組成部分，.NET Core從一開始就支持自動化構建和部署。
隨着.NET Core 2.0的發佈（最初發佈於2016年），微軟擁有了一個通用、模塊化、跨平臺和開源的平臺最新主要版本。.NET Core在當前版本的.NET Framework中提供了很多API。它最初是作爲下一代ASP.NET解決方案而創建的，但現在成爲很多其他場景的基礎，包括物聯網、雲計算和下一代移動解決方案。在這篇文章中，我們將探討.NET Core的更多優勢，以及它如何在爲傳統的.NET開發人員帶來好處的同時，還能讓所有需要爲市場帶來強大、高性能和經濟的解決方案的技術人員受益。
從.NET 1.0推出測試版開始，我就在開發軟件。我還記得當時使用.NET感覺就像在作弊一樣。我當時想，“這不是應該很難嗎？我的malloc在哪裏？我不需要轉換指針了嗎？這個框架類庫用來做什麼的？”
快進到2018年，我們仍然很樂意在.NET Framework上編寫代碼，不必爲內存分配問題而煩惱。System.Thread爲我們處理線程問題，然後是BackgroundWorker，現在是Task。原先不是線程安全的FCL類現在被標記爲線程安全的。想開發一個Web應用程序？它就是一個完整的框架，包含了所有必需的組件。.NET爲我們提供了很多原本需要手動完成的東西。作爲開發人員，我們把更多的時間花在編寫業務邏輯代碼上。彙編/C/C++擁護者可能會唏噓現在的一般開發人員都不需要硬核系統編程知識，但我不會這麼抱怨！
從第一個Beta版開始，.NET經歷了多次迭代，其中包括了四個主要版本。最近的迭代.NET Core是最重要的。.NET Core帶來了真正的跨平臺、現代CLI、構建系統和開源庫，等等。這些東西都很重要，但.NET Core的承諾不止於此，它還涉及了軟件的開發和交付方式。
我開發軟件已經有二十多年了，所以我還記得源碼控制是爲“大型”團隊而保留的。“自動化”並沒有真正出現在我們的詞典中——除了我們爲客戶自動化業務流程。說得具體一點，就是構建/編譯軟件是由人類完成的。“構建經歷”會在她自己的計算機上生成二進制文件（所以生成的文件在她自己的計算機上總能正常運行）！
將軟件部署到它要運行的環境中是一個脆弱的拜占庭式過程，因爲需要共享驅動器、FTP和進行手動文件複製粘貼。整合開發團隊的工作是一場悲慘的死亡遊行，一次又一次的回退就像玩打地鼠遊戲一樣。是否可以投入生產？誰知道呢？
軟件正在迅速建立起對世界的興趣，但開發、部署和運營基於軟件的系統的過程卻停留在圖靈和Hopper時代。2008年左右發生了一場革命，這場革命被稱爲DevOps。
從那時起到現在，這些年我們已經看到一場運動的興起。DevOps非常重要，它包含並可能取代之前出現的敏捷運動。我在2014年開始接觸DevOps，當時我在一次大會上拿到了《鳳凰項目》這本書。當我開始如飢似渴地閱讀那本書時，我的會議計劃被我拋到腦後。這本書講的東西太多了。如果你正處在IT行業，即使是很短的時間，你也一定扮演過那些角色。你可以試着自己代入角色。從那以後，DevOps成了我職業生涯的焦點。
DevOps通常被認爲有三個主要的“支柱”：文化、流程和技術。本文是關於DevOps的技術部分。具體地說，是關於.NET Core爲現代DevOps實踐帶來的技術。.NET Core是在DevOps興起期間構思出來的。微軟顯然有明確的目標，就是讓.NET Core成爲DevOps時代的平臺。本文將介紹.NET Core和DevOps的三個主要主題：
- .NET Core框架和SDK；
- 構建自動化；
- 應用程序監控。
.NET Core框架和SDK
DevOps並不是孤立存在的。用於生成和交付基於軟件的系統的技術可能可以支持或者阻礙DevOps實踐。無論你的技術棧是怎樣的，DevOps都是值得一試的。話雖如此，你選擇的技術棧將對你的DevOps實踐產生重大影響。
閉源、專有構建系統對DevOps來說並不友好。.NET Core是完全開源的，用於表示項目和解決方案的文件格式也有完整的文檔化。現代語言和框架（如Node/JavaScript、Ruby和Python）已經具有一些常見特性：
- 緊湊的開源框架；
- 命令行界面（CLI）；
- 記錄良好的開放式構建系統；
- 支持所有主要操作系統。
這些特性和其他更多功能在DevOps時代變得越來越流行，因爲它們具有很強的適用性和自動化能力。.NET Core的CLI命令dotnet是.NET Core應用程序構建過程的單一入口點。無論是什麼平臺，開發人員都可以在工作站上使用dotnet，用於構建代理。也就是說：我將在後續展示的所有本地開發工作都可以在MacBook Pro上進行。試着想象一下，這在三年前是不可能的事情！
使用.NET Core的第一步是下載它。你可以在這裏下載SDK。在我的MBP上有171MB。安裝完畢後，打開你最喜歡的終端窗口（在Windows上我偏愛Powershell，但在Mac上我使用iTerm2）。
如果你已經很熟悉.NET開發，那麼可能已經習慣了安裝大型框架。你習慣使用Visual Studio來完成開發工作。如果你是.NET Core新手，可能會覺得有點奇怪。在使用IDE之前，我們可以使用這171兆字節的東西完成很多事情。
執行：
dotnet
這是一個新的CLI命令，用於與.NET Core SDK發生交互。讓我們來看一下。
執行：
dotnet help
這將列出CLI支持的所有命令，這個清單並不長，也沒必要很長。你可能在查找哪些是與.NET Core框架構建過程進行交互所需的，從一個新項目到已部署的應用程序。
第一步是創建一個新的應用程序。讓我們來看看我們的選項。
執行：
dotnet new
輸出的信息將列出可用的模板。在Visual Studio中你可以單擊File-New Project來創建項目，但在這裏我們使用命令行。我們有很多模板可選擇。我偏愛Angular，所以讓我們從那裏開始吧。
執行：
dotnet new angular -o dotnet-angular
這將在新目錄dotnet-angular中創建一個新的Angular項目。如果你願意，可以手動創建目錄，只是在執行dotnet new之前不要忘記更改目錄，否則將在當前目錄中創建項目。
如果你已經做過Angular開發，那麼可能已經安裝了Node。如果沒有，請花點時間下載並安裝它。如果確實需要安裝Node，請在安裝後關閉並重新打開終端。
執行：
dotnet run
這個命令將編譯並運行應用程序（也可以通過執行dotnet build直接完成編譯，而無需運行應用程序來）。這可能需要一兩分鐘時間，然後你將得到一些包含URL的輸出：
Content root path: /Users/dswersky/dotnet-angular Now listening on: https://localhost:5001
將URL複製到Web瀏覽器中，然後等一會兒。你現在應該能看到一個在後臺運行ASP.NET Core、在前端運行Angular的簡單應用程序。那麼，這種體驗與昔日的.NET開發體驗有何不同？
你在幾分鐘內就創建並運行了一個.NET Core應用程序（即使包括安裝.NET Core和Node），你可能會想到這幾個問題：
我的IDE呢？
到目前爲止，我們還不需要IDE，對嗎？很顯然，如果你想編輯這段代碼，你需要使用某些工具。你可能希望使用與.NET和Angular相關的工具。“沒問題”，你可能會想，“我啓動Visual Studio Professional就可以了”。你可以這樣做…或者你也可以下載Visual Studio Code，它提供了很多功能，而且是免費的。你可以使用Visual Studio Community，它也是免費的。關鍵在於，不再需要花費數百美元就可以開始基於.NET Core的開發。
IIS呢？
這是“遺留”.NET Web應用程序開發和ASP.NET Core之間的主要區別。你可以在IIS中運行ASP.NET Core應用程序，但也可不必這麼做。.NET Core是跨平臺的，所以將ASP.NET Core與IIS分離也是顯而易見的。我在這裏列出的命令，包括dotnet run，在Windows、Mac和Linux上同樣運行良好，且效果完全相同（甚至還有一個可以在Raspberry Pi上運行的ARM構建命令）。這個Angular應用程序是“編寫一次，到處運行”的一個很好的示例。
不使用IIS來託管.NET應用程序已經有一段時間了。.NET Open Web Interface（OWIN）多年來一直支持“自託管”ASP.NET應用程序。這是通過代碼和基礎設施（通常稱爲“Project Katana”）來實現的。.NET Core使用了一個叫作Kestrel的HTTPS服務器。Kestrel是一款用於.NET應用程序的快速、高性能、開源的HTTPS服務器。Kestrel爲ASP.NET Core網站和RESTful服務提供HTTPS，讓它們可以運行在任何地方，包括Windows、Linux和容器協調器。Kestrel使ASP.NET Core應用程序變得完全獨立，在基於Windows的HTTPS服務器上沒有外部依賴性。
這與DevOps有什麼關係？
自動化是DevOps的核心原則和實踐。.NET Core提供的可移植性、CLI和開源構建系統對於DevOps實踐來說至關重要。最重要的是，它們可以輕鬆實現構建和部署過程的自動化。可以通過編寫CLI腳本來實現自動化，也可以通過編程方式直接自動化構建系統。.NET Core的這些功能使其不僅可以實現自動化，而且可以相對輕鬆地自動執行復雜的構建過程。我們因此能夠建立自動化和持續集成。
.NET Core構建自動化
回到Visual SourceSafe時代，團隊提交到存儲庫的代碼就在那裏，隨時準備好進行編譯。我的腦海裏浮現出一個想法——“爲什麼我要在我的系統上構建部署，因爲構建原本可以在存儲庫中進行？”我不是唯一一個有這種想法的人，但卻沒有對此採取什麼行動。真正採取行動的是那些開始着手開發持續集成（CI）系統的勇士們。
CI的目標說起來很簡單，但實現起來並不那麼容易：
始終有一個可部署的構建。
軟件開發是一項團隊運動。Agile/Scrum團隊平均有三到五名全職開發人員負責貢獻代碼。爲了提升效率，他們之間進行了分工。然後他們開發的代碼必須作爲一個整體進行組合、構建和測試，而且必須使用未安裝開發人員工具的系統進行自動化測試。理想情況下，在每次將新代碼合併到指定分支時都應該進行構建和測試。CI系統通常直接與源碼控制系統集成，每次分支發生變更時觸發新構建。
Roslyn是一款開源的.NET編譯器，提供了大量可直接訪問的API。CI系統開發人員使用這些編譯器API來構建插件，從而自動化.NET構建過程。.NET Core構建工具提供了對構建過程的細粒度控制。開發人員可以使用它們來調整和擴展現有的CI系統功能，以涵蓋幾乎任何可以想象的構建管道用例。你可以不是CI系統開發人員，但你可以構建插件。CI系統的維護者和供應商竭盡全力使他們的系統易於擴展。
現在有很多CI系統。以下是一個簡短的示例列表：
- Jenkins；
- TFS/Visual Studio Team Services；
- CircleCI；
- TeamCity；
- GitLab。
.NET Core提供的靈活性讓它可以與任何CI系統集成，這就像使用CLI腳本或者使用編譯器API開發的插件直接自動化構建一樣簡單。
如果你目前擁有自己喜歡的CI系統，可以嘗試一下我的示例項目。這與我們之前使用CLI創建的項目是一樣的，只是多了一點東西。存儲庫包含了一個Dockerfile，我花了大約十分鐘來創建一個VSTS構建管道、從Github中拉取代碼、構建鏡像，然後將其推送到Azure容器註冊表。這與AWS或Google Cloud中的Jenkinsfile或GitLab管道一樣好用。正如他們所說，一切皆有可能。
使用.NET Core進行應用程序監控
軟件系統的運維是一項全職工作，可以讓Ops團隊的同事來負責。這些系統就像嬰兒一樣——它們不斷地叫啼，需要獲得父母的關注。Ops工作人員通常就像陷入困惑的父母一樣，不知道爲什麼系統會發生這樣那樣的問題。系統如何引起人們注意？這取決於你是如何照看它們的！
最糟糕的系統監控方式就是不進行監控。無論你是否或者以某種方式進行監控，在它們出現故障時都會被注意到。當你的客戶瘋狂地打進客服電話或者完全棄用你的服務時，你會發現已經太晚了。應用程序監控的目標是搶在客戶或最終用戶之前檢測出問題。很多公司做出錯誤的經濟判斷，他們認爲應用程序監控過於昂貴，或者認爲“好的系統不需要監控”。
即使是最穩定的系統離災難性事故也只有一步之遙。DevOps實踐嘗試在安全性和速度之間做出平衡——同時讓公司可以通過快速移動進行創新。我們通過密切關注系統的運行參數來維持這種平衡。
.NET Core的設計和架構非常適用進行應用程序監控。ASP.NET Core是一個很好的例子。我們可以使用HTTP模塊自定義在IIS上運行的ASP.NET 3.x/4.x應用程序的內部請求和響應行爲。ASP.NET Core使用中間件改進了這種模型，中間件概念類似於HTTP模塊，但在實現方面卻非常不一樣。中間件類通過代碼進行集成，並且配置起來要簡單得多。它們形成了一個請求/響應管道鏈。
將中間件注入ASP.NET Core應用程序是非常容易的。我將演示一個Azure Application Insights示例。我在Azure Portal中創建了一個Application Insights資源，然後在我的存儲庫中編輯了三個文件來啓用Application Insights監控：
dotnet-angular.csproj
添加了一行來引用Application Insights資源（之所以需要這個手動步驟，是因爲我使用的是Visual Studio for Mac，詳細信息請參見這裏）。
appsettings.json
添加了我的Application Insights密鑰。
Startup.cs
Startup.cs是配置中間件的地方。我在這裏添加了Application Insights中間件。
完成這些工作後，我就能夠在本地進行調試，並收集來自Application Insights的監控數據。你可以自己嘗試一下，只需要用你的密鑰替換appsettings.json中的示例密鑰即可。
當然，Application Insights並不是監控應用程序的唯一選擇。AppMetrics是一個開源監控庫，可與Grafana等可視化工具集成。一些供應商也提供了付費選項。
所有這些監控方案都提供了能夠在運行時環境中查看應用程序行爲的透明度，這對於DevOps實踐來說至關重要，因爲它可以在不影響系統性能的情況下讓你驗證對系統所做的更改。然後，你可以添加新功能，並確信快速變更不會破壞已有的東西。
結論
.NET Core是在考慮DevOps實踐的情況下構思和開發出來的。CLI和開放式構建系統和庫讓軟件交付過程自動化變得可能。如果你願意，可以通過CLI腳本或更深入的編程集成來實現構建自動化和持續集成。使用開源或付費企業工具進行應用程序監控可將你的系統從黑匣子轉變爲透明的玻璃窗格。基於DevOps實踐的.NET Core是現代軟件系統的一個非常具有吸引力的平臺。
關於作者
Dave Swersky，從事IT工作已超過20年，從支持工程師到軟件開發人員，再到企業架構師。他是一個有抱負的多面手，並且對DevOps充滿熱情。他曾在很多與DevOps相關的大會上做過演講，包括DevOps企業峯會、CodeMash、Stir Trek以及KC的本地聚會。Dave還寫了一本關於DevOps的書：DevOps Katas: Hands-On DevOps。可以通過Twitter賬號@dswersky找到Dave。
查看英文原文：.NET Core and DevOps