什麼是持續傳遞？
在這裡，您將遵循 Tailspin 小組討論持續傳遞 (CD) 管線如何協助他們處理即將推出的版本。
Tailspin 小組覺得其建置流程開始漸入佳境。 他們在 Azure Pipelines 上執行自動化流程，因此建置環境很穩定。 Amita 會在第一時間知道何時需要測試成品。 錯誤 (bug)她發現的錯誤 (bug) 較少，因為 Andy 和 Mara 已展開單元測試和程式碼品質測試。 情況看來滿順利的。 我們來看看小組的討論。
晨會
小組成員在會議室等待產品經理 Irwin 加入，他想和大家談談。 成員們迫不及待地想向他報告進度。 但 Irwin 進來時，看起來不太高興。 他馬上開始說話。
Irwin：我早上和管理小組開過會。 他們想知道我們要發行的遊戲和網站為何要準備這麼久。 我們最大的競爭同業早已推出新功能和新遊戲了。 我們得加緊腳步了。 我不只是提醒各位， 而是提醒所有小組。 我們要如何協助您的小組加速部署？
Andy：雖有點突然，但我們早就想到了。 我們一直採用自動化的方式在建置網站。 或許現在是將自動化方式延伸到發行流程的時候了。
Irwin：你打算怎麼做？
Mara：我們使用 Azure Pipelines 將組建管線自動化， 這樣就會建置成品，讓 Amita 測試。 我們也可組建持續傳遞 (或簡稱 CD) 管線。
Irwin：什麼是 CD 管線？
Mara 開始說明，但被 Irwin 的手機提示聲打斷。 Irwin 看了簡訊，嘀咕了幾句。
Irwin：很抱歉，但這事很緊急。 我得走了。 你們趕快把這個 CD 業務搞定，給我答覆，可以嗎？
Andy 看了看他的小組成員。
Andy：要喝咖啡嗎？
Andy 和小組的其他成員到咖啡廳討論計劃。
什麼是持續傳遞？
小組正在喝咖啡開會，以瞭解如何設定持續傳遞工作流程。
Andy：您可以告訴我們您對持續傳遞的瞭解嗎？
Mara：我知道 CD 和 DevOps 是分不開的。 別忘了，DevOps 的定義統合人員、流程與產品，以持續向終端使用者傳遞價值。
CD 本身是一組流程、工具和技術，可用來快速、可靠且持續地傳遞軟體。 因此，CD 並非單指設定管線，當然這也很重要。 CD 也牽涉到設定如下的工作環境：
- 我們有可靠且可重複的流程，以利發行和部署軟體。
- 我們的工作盡可能自動化。
- 我們不會拖延做一些困難或麻煩的事；相反地，我們會更頻繁地這樣做，以便了解如何使其成為例行的動作。
- 一切都要進行原始程式碼控制。
- 我們都同意，完成就是已發行。
- 我們在過程中就會追求品質。 品質無法事後彌補。
- 發行流程是我們所有人的責任。 我們不再各行其是。
- 我們要力求改進。
其中有許多想法我們都已付諸實行，而大家也都認同這改善我們的工作方式， CD 只是進一步延伸。
我們為何需要持續傳遞？
CD 可協助軟體小組頻繁將可靠的軟體更新傳遞給客戶。 CD 也有助於確保客戶和專案關係人都能快速取得最新功能和修正程式。
小組仍在討論，我們接著往下聽。
Andy：謝謝，Mara。 我們需要 CD，原因我們都很清楚，世界已經改變了。 新功能的發行愈來愈快。 更新和錯誤 (bug) 修正都必須立即到位。 不只是管理階層要我們加快發行速度， 因為他們只是回應客戶需求。 如果我們無法滿足客戶需求，他們就會離開。
Tim：同意！ 我迫不及待要開始。
Andy：謝了，各位。 我提議由 Mara 和我簡單做一份概念證明 (POC)。 我想如果各位可以看到實際運作的 CD 管線，將更容易理解一切。
Amita：祝你們好運，兩位。
小組成員離開 Andy 和 Mara 去處理細節問題。
持續傳遞與滑鼠右鍵發佈有何不同？
許多開發工具可讓您直接將應用程式發佈至某個目標環境，例如 Microsoft Internet Information Services (IIS) 或 Azure。 例如，您可以使用 Visual Studio 將 ASP.NET Core 應用程式發佈至 Azure。 此流程有時稱為滑鼠右鍵發佈。
滑鼠右鍵發佈是快速建置原型的絕佳方式。 例如，您可以按一下滑鼠右鍵將應用程式發佈至 Azure，以便與小組成員分享新的想法。 不過，這項技術有一些限制。
持續傳遞可讓您和小組成員在您每次簽入程式碼時穩定持續測試、部署及監視應用程式。 當您按一下滑鼠右鍵以發佈應用程式時，並不保證程式碼已經過適當測試，也不保證實際使用會如預期運作。
在這段短片中，Microsoft 雲端大使 Abel Wang 將進一步說明。
持續傳遞與持續部署有何不同？
在 DevOps 社群中，您可能會聽到持續傳遞和持續部署這兩個詞彙。 這兩個詞彙的意思是相同的嗎？ 在這段短片中，Abel 會說明其差異。
我可以使用哪些持續傳遞工具？
會議結束後，Andy 和 Mara 規劃後續步驟。 他們使用 Azure Pipelines 建置其軟體。 他們想思考有助於發行流程的可用工具 (包括 Azure Pipelines)。
Mara：你要從何處著手？
Andy：首先，我們必須在發行管理工具上取得共識。 來確認一下我們選擇的工具：
- 支援我們的版本控制系統。
- 可以部署至多個環境，以便我們測試及驗證工作。
- 可方便我們定義部署工作。
- 易於擴充。
Mara：Azure DevOps 整合數個其他持續整合 (CI) 和 CD 解決方案。 市面上的解決方案那麼多，但我們並未投資於任何一個。 研究後應該能找到適合的一個吧。 熱門的 CI 和 CD 系統包括 Jenkins、Circle CI、GitLab、Travis CI 和 Azure Pipelines。
這些工具雖相似，但也各有特殊優勢。 其中一些工具是開放原始碼，有些是免費的，有些則必須付費。 各項工具也都提供與其他軟體工具的內建整合。
例如，Jenkins 是開放原始碼。 此工具有許多外掛程式，許多公司都在使用。 您可以在雲端或內部部署環境中執行 Circle CI。 我認為我們有必要加以自訂。 GitLab 是整個軟體開發生命週期的單一應用程式。 其能力可能比我們目前需要的還強大。 我們可以繼續使用 Azure Pipelines。
在以下這段短片中，Abel 會談到如何使用 DevOps 最佳做法將程式碼部署至 Azure。
Mara：我贊成繼續使用 Azure Pipelines。
Andy：我同意。 Azure Pipelines 到目前為止的效益極佳，我們不需要學習另一項新技術。
Mara：太棒了。 我們開始討論管線的細節吧。
Andy 和 Mara 移到會議室來規劃 CD 管線。