使用數位發明來強化採用
最終的創新測試是客戶對發明的反應。 假設是否成立？ 客戶是否使用解決方案？ 其是否可調整以符合所需的使用者百分比需求？ 最重要的是，使用者是否持續回來？ 在部署最小可行產品 (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 Test Plans 功能，提供開發和執行測試計劃的工具，您可在手動或自動化測試執行期間使用這些工具。
解決方案部署
加強採用時最有意義的層面，或許是您能控制將解決方案發行給客戶的能力。 您可以透過提供自助或自動化管線，將解決方案發行給客戶，進而加速意見反應迴圈。 藉由讓客戶快速與解決方案中的變更內容互動，您可以邀請他們加入流程。 這種方法也會觸發較快速的假設測試，減少假設和潛在的修改作業。
有幾種適用於解決方案部署的方法。 下列為最常見的三種方法：
- 持續部署是最先進的方法，因為其會自動將程式碼的變更內容部署至實際執行環境。 對測試成熟度假設的成熟團隊而言，持續部署意義非凡。
- 持續部署可能更適合在開發的初期階段中使用。 在持續傳遞中，任何程式碼的變更內容都會自動部署至類似實際執行的環境。 開發人員、商務決策者和小組的其他人員都可以使用此環境，來確認其工作是否已準備用於實際執行環境。 您也可以使用此方法與客戶測試假設，而不會影響進行中的商務活動。
- 手動部署是最簡易的發行管理方法。 顧名思義，小組的某位人員會手動部署最新的程式碼變更內容。 這種方法既容易出錯也不可靠，且許多資深工程師將其視為反模式。
即便先前進行評量，在 MVP 解決方案的初次反覆運算期間，手動部署作業仍相當常見。 當解決方案非常流暢，且客戶的意見反應不明時，重設整個解決方案 (甚至是核心假設) 會產生重大風險。 以下是手動部署的一般規則：無客戶證明，無部署自動化。
過早投資可能會失去時間。 更重要的是，其可建立發行管線的相依性，讓小組具有抵抗早期樞紐的能力。 在執行前幾個反復運算後，或當客戶意見反應指出潛在的成功機會時，您應快速採用更先進的部署模型。
在假設驗證的任何階段，Azure DevOps 和 Azure Pipelines 皆可提供持續傳遞和持續部署的功能。 深入瞭解持續傳遞，或查看實作教室。 解決方案架構也可以透過 Azure DevOps 加快 CI/CD 管線的建立速度。
整合式測量
當您評量客戶所受影響時，請務必瞭解客戶對解決方案中的變更內容有何反應。 這項資料 (稱為遙測資料) 可提供使用者在使用解決方案時，所採取動作 (或使用者世代) 的深入解析。 您可輕鬆從此資料中取得假設的量化驗證。 然後可以使用這些計量來調整解決方案，並產生更精細的假設。 這些細微的變更內容，可讓稍後反覆運算中的初始解決方案更加成熟，最終促使大規模的重複採用情形。
在 Azure 中，Azure 監視器可提供工具和介面，以從客戶體驗中收集並檢閱資料。 您可以使用 Azure Boards 來套用這些觀察和深入解析，以精簡代辦項目。
後續步驟
在您瞭解加強採用所需的 CI/CD 管線工具和流程後，可檢視更進階的創新專業領域：與裝置互動。 此專業領域有助於減少實體和數位體驗之間的阻礙，讓您可更輕鬆採用解決方案。