創新的最終測試是客戶對發明的反應。 假設是否屬實？ 客戶是否使用解決方案？ 它是否能擴展以滿足特定比例使用者的需求？ 最重要的是，他們繼續回來嗎？ 在部署最低可行產品 （MVP） 解決方案之前，無法詢問這些問題。
在本文中，我們將著重於使用持續整合和持續部署 （CI/CD） 管線工具來強化採用能力。 持續整合是每天多次自動化整合程式碼，以便獲得持續更新的單一專案。 持續部署是將這些功能在整天中自動遞交。
減少影響採用的 CI/CD 摩擦
透過技術和程序的組合，可以最小化採用的一些障礙。 對於瞭解 CI/CD 或 DevOps 程式的讀者，將會熟悉下列 CI/CD 管線程式。 本文為雲端採用小組建立一個起點，可促進創新和意見反應迴圈。 隨著產品和小組的成熟，此起點可能會促進更健全的 CI/CD 或 DevOps 方法。
如 測量客戶影響中所述，任何假設的正向驗證都需要反覆試驗和決心。 此 CI/CD 文章旨在將 技術尖峰 降到最低，以減緩創新，同時確保您保持最佳作法。 這樣做將有助於小組設計未來成功，同時提供目前的客戶需求。
強化採用和數字發明：成熟度模型
創新方法的主要目標是建立客戶合作關係並加速意見反應迴圈，這會導致市場創新。 下圖和章節說明支援此方法的初始實作。
- 共用解決方案：為解決方案的所有層面建立集中式存放庫。
- 意見反應迴圈：請確定可透過反覆專案一致地管理意見反應迴圈。
- 持續整合：定期建置並合併解決方案。
- 可靠的測試：驗證解決方案品質和預期的變更，以確保測試計量的可靠性。
- 解決方案部署：部署解決方案，讓小組可以快速與客戶共用變更。
- 整合式測量：將學習計量新增至意見反應迴圈，以便完整小組清楚分析。
若要將技術尖峰降到最低，假設這些原則的成熟度一開始會很低。 提前規劃，配合能隨著假設越來越精細而擴展的工具和流程。 在 Azure 中， GitHub 和 Azure DevOps 可讓小型小組開始使用很少的摩擦。 這些小組可能會成長為包含數千名在規模解決方案上共同作業的開發人員，以及測試數百個客戶假設。 本文的其餘部分說明「大規劃，小起步」的方法，以推動這些原則的採用。
共用解決方案
如 測量客戶影響中所述，任何假設的正面驗證都需要反覆和決心。 在任何創新週期中，您都會經歷比獲勝更多的失敗。 這是預期的。 不過，當客戶需要、假設和解決方案大規模調整時，世界就會快速改變。
當您擴展數位發明和創新時，沒有比解決方案的共用程式代碼基礎更有價值的工具了。 不幸的是，沒有可靠的方法來預測哪一個反覆專案或哪個 MVP 會產生獲勝的組合。 這就是為什麼建立共用程式代碼基底或存放庫永遠不會太早。 這是一個不應該延遲的技術高峰。 當小組逐一查看各種 MVP 解決方案時，共用存放庫可讓您輕鬆共同作業並加速開發。 當解決方案的變更拖曳學習計量時，版本控制可讓您復原到較舊、更有效率的解決方案版本。
管理程式代碼存放庫的最廣泛採用 CI/CD 工具是 GitHub，可讓您在幾個步驟中建立共用程式代碼存放庫。 此外，Azure DevOps 的 Azure Repos 功能可用來建立 Git 或 TFVC 存放庫。
意見反應迴圈
讓客戶成為解決方案的一部分，是在創新周期期間建立客戶合作關係的關鍵。 這部分是藉由 測量客戶的影響來完成的。 它需要與客戶進行交談和直接測試。 兩者都會產生必須有效管理的意見反應。
每個意見反應點都是客戶所需的潛在解決方案。 更重要的是，每一位直接客戶意見反應都代表改善合作關係的機會。 如果意見反應將其納入 MVP 解決方案，請與客戶一起慶祝。 即使某些意見反應無法採取動作，只要決定將意見反應取消定價，就表示 成長思維 和專注於 持續學習。
Azure DevOps 包含 要求、提供和管理意見反應的方式。 這些工具會集中處理意見反應，讓小組可以採取動作，並提供透明意見反應循環的後續工作。
持續整合
持續整合是每天將程式代碼自動化多次，以擁有更新的單一專案。 隨著採用規模擴大和假設逐漸接近大規模真正的創新，需要測試的多個較小假設數量往往會迅速增加。 對於精確的意見反應迴圈和順暢的採用程式，這些假設必須整合並支援創新背後的主要假設。 這需要您快速移動以創新並成長，這需要多個開發人員來測試核心假設的變化。 針對後續階段的開發工作，您甚至可能需要多個開發人員小組，每個小組都建置為共用解決方案。 持續整合是管理所有行動元件的第一個步驟。
在持續整合中，程式代碼變更經常合併到主要分支中。 自動化建置和測試程式可確保主要分支中的程式代碼一律是生產品質。 這可確保開發人員會共同開發提供精確且可靠的意見反應迴圈的共享解決方案。
Azure DevOps 和 Azure Pipelines 僅提供 GitHub 或其他存放庫中幾個步驟的持續整合功能。 如需詳細資訊，請參閱 什麼是持續整合？ 或嘗試 持續整合實際作實驗室。 解決方案架構可供使用，可加速 透過 Azure DevOps 建立 CI/CD 管線。
可靠的測試
任何解決方案中的瑕疵都可能會產生誤報或漏報。 非預期的錯誤很容易導致用戶採用率指標的誤解。 他們也可能產生客戶的負面反饋，但這些反饋未必能準確反映出您假設的測試。
在 MVP 解決方案的早期反覆運算期間，預期會有瑕疵。 早期採用者甚至可能發現它們令人生機。 在早期版本中，驗收測試通常不存在。 不過，同理心建置的一個方面涉及對需求和假設的驗證。 這兩者都可以透過程式代碼層級的單元測試和手動驗收測試完成，再進行部署。 這些共同提供測試中一些可靠的方法。 您應該嘗試將定義完善的組建、單元和驗收測試系列自動化。 這些可確保與對假設和結果解決方案進行更精細調整相關的可靠計量。
Azure 測試計劃功能提供工具，可在手動或自動化測試執行期間開發及作測試計劃。
解決方案部署
也許授權採用最有意義的層面是控制解決方案發行給客戶的能力。 藉由提供自行或自動化流程將解決方案發佈給客戶，您將加快回饋循環。 藉由讓客戶快速與解決方案中的變更互動，您可以邀請他們參與此過程。 這種方法也會觸發更快速的假設測試，減少假設和可能的重新作業。
解決方案部署有數種方法。 最常見的三個是：
- 持續部署 是最先進的方法，因為它會自動將程式代碼變更部署到生產環境。 對於測試成熟假設的成熟小組，持續部署可能非常有價值。
- 在開發初期階段， 持續傳遞 可能更合適。 在持續傳遞中，任何程式碼變更都會自動部署到類似生產環境的環境。 小組中的開發人員、商務決策者和其他人員可以使用此環境來確認其工作已就緒。 您也可以使用此方法來測試與客戶的假設，而不會影響進行中的商務活動。
- 手動部署 是發行管理最不複雜的方法。 如其名所示，小組中的某人會手動部署最新的程式代碼變更。 這種方法容易出錯、不可靠，而且被大多數經驗豐富的工程師視為反模式。
在 MVP 解決方案的第一次反覆專案中，儘管有上述評估，但手動部署很常見。 當解決方案非常流暢且客戶意見反應未知時，重設整個解決方案（甚至核心假設）會有重大風險。 以下是手動部署的一般規則：沒有客戶證明、沒有部署自動化。
早期投資可能會導致時間損失。 更重要的是，它可能會在發行管線上建立依賴性，使團隊不易於早期進行轉變。 在前幾次迭代或客戶反饋顯示有潛在成功的跡象時，應該快速採用更進階的部署模型。
在任何假設驗證階段，Azure DevOps 和 Azure Pipelines 都會提供持續傳遞和持續部署功能。 深入瞭解 持續交付，或查看 實作實驗室。 解決方案架構也可以加速 透過 Azure DevOps 建立 CI/CD 管線。
整合式測量
當您 測量客戶影響時，請務必瞭解客戶對解決方案中變更的反應。 此數據稱為 遙測，可提供使用者（或使用者世代）在使用解決方案時所採取動作的深入解析。 從這項數據中，很容易取得假設的量化驗證。 然後，這些計量可用來調整解決方案，併產生更精細的假設。 這些細微變更有助於在稍後的反覆專案中成熟初始解決方案，最終導致大規模重複採用。
在 Azure 中， Azure 監視器 提供工具和介面，從客戶體驗收集及檢閱數據。 您可以使用 Azure Boards 來套用這些觀察和深入解析來精簡待辦專案。
後續步驟
在您了解推動採用所需的 CI/CD 管線工具和程序之後，就可以探討一個更進階的創新領域：與裝置互動。 此專業領域有助於降低實體與數位體驗之間的障礙，讓您的解決方案更容易採用。