以數位發明實現採用Empower adoption with digital invention

最終的創新測試是客戶對您發明的反應。The ultimate test of innovation is customer reaction to your invention. 假設是否證明真?Did the hypothesis prove true? 客戶使用解決方案嗎?Do customers use the solution? 它是否可調整以符合所需的使用者百分比需求?Does it scale to meet the needs of the desired percentage of users? 最重要的是,他們是否持續回來?Most importantly, do they keep coming back? 在部署最小可行產品 (MVP) 解決方案之前,都不會詢問這些問題。None of these questions can be asked until the minimum viable product (MVP) solution has been deployed.

在本文中,我們將著重于採用持續整合和持續部署 (CI/CD) 管線工具的採用。In this article, we'll focus on empowering adoption with continuous integration and continuous deployment (CI/CD) pipeline tools. 持續整合是每天自動執行一次程式碼,以便擁有更新的單一專案。Continuous integration is the automating of code multiple times per day in order to have an updated single project. 持續部署是指在一天內自動傳遞這些函式的功能。Continuous deployment is the automatic delivery of those functions throughout the day.

減少影響採用的 CI/CD 摩擦Reduce CI/CD friction that affects adoption

有一些阻礙可透過技術和流程的組合來最小化。Some obstacles to adoption can be minimized through a combination of technology and processes. 針對具備 CI/CD 或 DevOps 流程知識的讀者,將會熟悉下列 CI/CD 管線程式。For readers with knowledge of CI/CD or DevOps processes, the following CI/CD pipeline processes will be familiar. 本文為雲端採用小組建立了燃料創新和意見反應迴圈的起點。This article establishes a starting point for cloud adoption teams that fuels innovation and feedback loops. 此起點可能會促進更健全的 CI/CD 或 DevOps 方法,因為產品和團隊成熟。This starting point might foster more robust CI/CD or DevOps approaches as the products and teams mature.

對客戶的影響進行測量所述,任何假設的正面驗證都需要反復專案和判斷。As described in Measure for customer impact, positive validation of any hypothesis requires iteration and determination. 此 CI/CD 文章的目標是將 技術尖峰 降至最低,以降低創新,同時確保您保持最佳做法。This CI/CD article aims to minimize technical spikes that slow innovation, while making sure you keep best practices in place. 這樣做將有助於團隊設計未來的成功,同時提供目前客戶的需求。Doing so will help the team design for future success while delivering on current customer needs.

強化採用和數位發明:成熟度模型Empower adoption and digital invention: The maturity model

創新方法的主要目標是建立客戶合作關係並加速意見反應迴圈,這會導致市場創新。The primary goal of the Innovate methodology is to build customer partnerships and accelerate feedback loops, which lead to market innovations. 下圖和章節說明支援此方法的初始支援。The following image and sections describe initial implementations that support this methodology.

顯示「強化採用成熟度」模型的圖表。

  • 共用解決方案:為解決方案的所有層面建立集中式存放庫。Shared solution: Establish a centralized repository for all aspects of the solution.
  • 意見反應迴圈:確定可以透過反覆運算一致地管理意見反應迴圈。Feedback loops: Make sure that feedback loops can be managed consistently through iterations.
  • 持續整合:定期建立和合併解決方案。Continuous integration: Regularly build and consolidate the solution.
  • 可靠的測試:驗證解決方案品質和預期的變更,以確保測試計量的可靠性。Reliable testing: Validate solution quality and expected changes to ensure the reliability of your testing metrics.
  • 解決方案部署:部署解決方案,讓小組能夠快速地與客戶共用變更。Solution deployment: Deploy solutions so that the team can quickly share changes with customers.
  • 整合式測量:將學習計量新增至意見反應迴圈,以供完整的小組進行清楚的分析。Integrated measurement: Add learning metrics to the feedback loop for clear analysis by the full team.

若要將技術尖峰降至最低,請假設在每個原則中的成熟度一開始都很低。To minimize technical spikes, assume that maturity will initially be low across each of these principles. 藉由與可隨著假設進行調整的工具和程式,更精細地進行規劃。Plan ahead by aligning to tools and processes that can scale as hypotheses become more fine-grained. 在 Azure 中, GitHubAzure DevOps 可讓小型團隊開始使用一些小小的部分。In Azure, GitHub and Azure DevOps allow small teams to get started with little friction. 這些小組可能會成長,包括數千位開發人員,這些開發人員會共同處理規模的解決方案,並測試上百個客戶假設。These teams might grow to include thousands of developers who collaborate on scale solutions and test hundreds of customer hypotheses. 本文的其餘部分將說明如何在每個原則中採用「全計畫」、「開始小型」的方法。The rest of this article illustrates the "plan big, start small" approach to empowering adoption across each of these principles.

共用解決方案Shared solution

對客戶的影響進行測量所述,任何假設的正面驗證都需要反復專案和判斷。As described in Measure for customer impact, positive validation of any hypothesis requires iteration and determination. 在任何創新週期期間,您將會遇到比 wins 更多的失敗。You'll experience far more failures than wins during any innovation cycle. 這是預期行為。This is expected. 不過,當客戶需要、假設和解決方案大規模調整時,世界會快速變更。However, when a customer need, hypothesis, and solution align at scale, the world changes quickly.

當您調整數位發明和創新時,不會有比解決方案的共用程式碼基底更有價值的工具。When you're scaling digital invention and innovation, there's no more valuable tool than a shared code base for the solution. 可惜的是,沒有可靠的方式可以預測哪個反復專案或哪些 MVP 會產生獲獎的組合。Unfortunately, there's no reliable way of predicting which iteration or which MVP will yield the winning combination. 這就是為什麼建立共用程式碼基底或存放庫絕對不太早的原因。That's why it's never too early to establish a shared code base or repository. 這是一項不應該延遲的 技術尖峰This is the one technical spike that shouldn't be delayed. 當小組逐一查看各種 MVP 解決方案時,共用存放庫可讓您輕鬆地共同作業和加速開發。As the team iterates through various MVP solutions, a shared repo enables easy collaboration and accelerated development. 當解決方案的變更向下拖曳學習計量時,版本控制可讓您回復為較早、更有效的解決方案版本。When changes to the solution drag down learning metrics, version control lets you roll back to an earlier, more effective version of the solution.

最廣泛採用的 CI/CD 工具來管理程式碼存放庫是 GitHub,可讓您只需幾個步驟,就能建立共用的程式碼存放庫。The most widely adopted CI/CD tool for managing code repositories is GitHub, which lets you create a shared code repository in just a few steps. 此外,Azure DevOps 的 Azure Repos 功能可以用來建立 GitTFVC 存放庫。Additionally, the Azure Repos feature of Azure DevOps can be used to create a Git or TFVC repository.

意見反應迴圈Feedback loops

讓客戶的解決方案成為解決方案的一部分,是在創新週期內建立客戶合作關係的關鍵。Making the customer part of the solution is the key to building customer partnerships during innovation cycles. 這是透過 測量客戶的影響來完成。That's accomplished, in part, by measuring customer impact. 它需要與客戶進行交談和直接測試。It requires conversations and direct testing with the customer. 兩者都會產生必須有效管理的意見反應。Both generate feedback that must be managed effectively.

每個意見反應都是客戶需求的潛在解決方案。Every point of feedback is a potential solution to the customer need. 更重要的是,每位直接客戶的意見反應都代表提升合作關係的機會。More importantly, every bit of direct customer feedback represents an opportunity to improve the partnership. 如果意見反應成為 MVP 解決方案,請與客戶一起慶祝。If feedback makes it into an MVP solution, celebrate that with the customer. 即使有些意見反應無法採取行動,但推遲意見反應的決策也會示範 成長思維 ,並著重于 持續學習Even if some feedback isn't actionable, simply being transparent with the decision to deprioritize the feedback demonstrates a growth mindset and a focus on continuous learning.

Azure DevOps 包括 要求、提供和管理意見反應的方式。Azure DevOps includes ways to request, provide, and manage feedback. 這些工具每一個都會將意見反應集中,讓小組可以採取行動,並提供透明回饋迴圈的後續服務。Each of these tools centralizes feedback so that the team can take action and provide follow-up in service of a transparent feedback loop.

持續整合Continuous integration

持續整合是每天自動執行程式碼,以取得更新的單一專案。Continuous integration is the automating of code multiple times per day to have an updated single project. 隨著採用規模和假設更接近真正的大規模創新,要測試的較小假設數目通常會快速成長。As adoptions scale and a hypothesis gets closer to true innovation at scale, the number of smaller hypotheses to be tested tends to grow rapidly. 為了取得準確的意見反應迴圈和順利採用流程,請務必將這些假設整合,並支援創新背後的主要假設。For accurate feedback loops and smooth adoption processes, it's important that each of those hypotheses is integrated and supportive of the primary hypothesis behind the innovation. 這需要您快速移動以創新和成長,因此需要多位開發人員測試核心假設的變化。This requires you to move quickly to innovate and grow, which requires multiple developers for testing variations of the core hypothesis. 針對稍後的階段開發工作,您可能甚至需要多個開發人員小組,而每個開發人員都在共用方案中打造。For later stage development efforts, you might even need multiple teams of developers, each building toward a shared solution. 持續整合是管理所有移動元件的第一步。Continuous integration is the first step toward management of all the moving parts.

在持續整合中,程式碼變更經常會合並到主要分支中。In continuous integration, code changes are frequently merged into the main branch. 自動化的組建和測試程式可確保主要分支中的程式碼一律為生產環境品質。Automated build and test processes make sure that code in the main branch is always production quality. 這可確保開發人員共同作業,以開發提供準確且可靠的意見反應迴圈的共用解決方案。This ensures that developers are working together to develop shared solutions that provide accurate and reliable feedback loops.

Azure DevOps 和 Azure Pipelines 只需在 GitHub 或其他存放庫中執行幾個步驟,就能提供持續整合功能。Azure DevOps and Azure Pipelines provide continuous integration capabilities with just a few steps in GitHub or other repositories. 如需詳細資訊,請參閱 什麼是持續整合? 或查看 實際操作實驗室For more information, see What is continuous integration? or check out the hands-on lab. 解決方案架構可透過 Azure DevOps 加快 CI/CD 管線的建立速度。Solution architectures are available that can accelerate creation of your CI/CD pipelines via Azure DevOps.

可靠的測試Reliable testing

任何解決方案中的瑕疵都可能會產生誤報或誤否定。Defects in any solution can create false positives or false negatives. 非預期的錯誤很容易就會導致使用者採用計量的解釋。Unexpected errors can easily lead to misinterpretation of user adoption metrics. 他們也會產生負面的意見反應,讓客戶無法精確地表示您的假設測試。They can also generate negative feedback from customers that doesn't accurately represent the test of your hypothesis.

在 MVP 解決方案的早期反復專案中,預期會發生瑕疵。During early iterations of an MVP solution, defects are expected. 早期採用者甚至可能會發現它們可愛。Early adopters might even find them endearing. 在早期版本中,接受度測試通常不存在。In early releases, acceptance testing is typically nonexistent. 但是,其中一個建立的層面會理解需要和假設的驗證。However, one aspect of building with empathy concerns the validation of the need and hypothesis. 兩者都可以透過程式碼層級的單元測試完成,並在部署前手動接受測試。Both can be completed through unit tests at a code level and manual acceptance tests before deployment. 這些都是在測試時提供一些可靠性的方法。Together, these provide some means of reliability in testing. 您應該嘗試自動化一系列定義完善的組建、單元和接受度測試。You should try to automate a well-defined series of build, unit, and acceptance tests. 這些可確保可靠的計量,與對假設和產生的解決方案進行更細微的調整。These will ensure reliable metrics related to finer tweaks to the hypothesis and the resulting solution.

Azure Test Plans功能提供在手動或自動化測試執行期間開發和操作測試計劃的工具。The Azure Test Plans feature provides tooling to develop and operate test plans during manual or automated test execution.

解決方案部署Solution deployment

可能是讓採用的最有意義層面,就是您可以控制將解決方案發行給客戶的能力。Perhaps the most meaningful aspect of empowering adoption is your ability to control the release of a solution to customers. 藉由提供自助或自動化管線來將解決方案發行給客戶,您將會加速意見反應迴圈。By providing a self-service or automated pipeline for releasing a solution to customers, you'll accelerate the feedback loop. 藉由讓客戶快速與解決方案中的變更互動,您可以邀請他們進入流程。By allowing customers to quickly interact with changes in the solution, you invite them into the process. 這種方法也會觸發較快速的假設測試,減少假設和可能的修改。This approach also triggers quicker testing of hypotheses, reducing assumptions and potential rework.

解決方案部署有幾種方法。There are several methods for solution deployment. 最常見的三種:The three most common are:

  • 持續部署 是最先進的方法,因為它會自動將程式碼變更部署至生產環境。Continuous deployment is the most advanced method, as it automatically deploys code changes into production. 針對測試成熟假設的成熟團隊,持續部署可能非常有價值。For mature teams that are testing mature hypotheses, continuous deployment can be extremely valuable.
  • 在開發初期階段, 持續傳遞 可能更適合。During early stages of development, continuous delivery might be more appropriate. 在持續傳遞中,任何程式碼變更都會自動部署至類似生產的環境。In continuous delivery, any code changes are automatically deployed to a production-like environment. 開發人員、商務決策者和小組的其他人員都可以使用此環境來確認其工作是否已準備好用於生產環境。Developers, business decision-makers, and others on the team can use this environment to verify that their work is production-ready. 您也可以使用此方法來測試客戶的假設,而不會影響進行中的商務活動。You can also use this method to test a hypothesis with customers without affecting ongoing business activities.
  • 手動部署 是發行管理的最複雜方法。Manual deployment is the least sophisticated approach to release management. 顧名思義,小組的某個人會手動部署最新的程式碼變更。As the name suggests, someone on the team manually deploys the most recent code changes. 這種方法很容易出錯、不可靠,而且是由許多經驗豐富的工程師所考慮的反模式。This approach is error prone, unreliable, and considered an anti-pattern by most seasoned engineers.

在 MVP 解決方案的第一次反覆運算期間,即使先前的評量是手動部署也是常見的。During the first iteration of an MVP solution, manual deployment is common, despite the preceding assessment. 當解決方案非常流暢且客戶的意見反應不明時,重設整個解決方案 (甚至是核心假設) 會有很大的風險。When the solution is extremely fluid and customer feedback is unknown, there's a significant risk in resetting the entire solution (or even the core hypothesis). 以下是手動部署的一般規則:無客戶證明,無部署自動化。Here's the general rule for manual deployment: no customer proof, no deployment automation.

及早投資可能會導致遺失的時間。Investing early can lead to lost time. 更重要的是,它可以建立發行管線的相依性,讓小組更能抵抗早期的 pivot。More importantly, it can create dependencies on the release pipeline that make the team more resistant to an early pivot. 在前幾個反復專案之後,或當客戶意見反應可能成功時,應快速採用更先進的部署模型。After the first few iterations or when customer feedback suggests potential success, a more advanced model of deployment should be quickly adopted.

在假設驗證的任何階段,Azure DevOps 和 Azure Pipelines 提供持續傳遞和持續部署功能。At any stage of hypothesis validation, Azure DevOps and Azure Pipelines provide continuous delivery and continuous deployment capabilities. 深入瞭解 持續傳遞,或查看 實際操作實驗室Learn more about continuous delivery, or check out the hands-on lab. 解決方案架構也可以透過 Azure DevOps,加速建立您的 CI/CD 管線Solution architecture can also accelerate creation of your CI/CD pipelines through Azure DevOps.

整合式度量Integrated measurements

當您 測量對客戶的影響時,請務必瞭解客戶對解決方案中的變更有何反應。When you measure for customer impact, it's important to understand how customers react to changes in the solution. 這項資料(稱為 遙測 資料)提供 (使用者在使用解決方案時) 所採取之動作的深入解析。This data, known as telemetry, provides insights into the actions a user (or cohort of users) took when working with the solution. 從這項資料,很容易就能取得假設的量化驗證。From this data, it's easy to get a quantitative validation of the hypothesis. 然後可以使用這些計量來調整解決方案,並產生更精細的假設。Those metrics can then be used to adjust the solution and generate more fine-grained hypotheses. 這些細微變更有助於在稍後的反復專案中成熟初始解決方案,最終促使大規模重複採用。Those subtler changes help mature the initial solution in later iterations, ultimately driving to repeat adoption at scale.

在 Azure 中, Azure 監視器 提供工具和介面,可從客戶體驗收集和查看資料。In Azure, Azure Monitor provides the tools and interface to collect and review data from customer experiences. 您可以使用 Azure Boards來套用這些觀察和見解,以精簡待處理專案。You can apply those observations and insights to refine the backlog by using Azure Boards.

下一步Next steps

在您瞭解如何進行採用所需的 CI/CD 管線工具和程式之後,現在就可以開始檢查更先進的創新專業領域: 與裝置互動After you've gained an understanding of the CI/CD pipeline tools and processes needed to empower adoption, it's time to examine a more advanced innovation discipline: interact with devices. 此專業領域有助於降低實體和數位體驗之間的障礙,讓您的解決方案更容易採用。This discipline can help reduce the barriers between physical and digital experiences, making your solution even easier to adopt.