测试手机采购方案设计_加强内部采购案例研究-CSDN博客

测试手机采购方案设计

When your team charter is to support the infrastructure needs of many internal teams that are innovating quickly and releasing changes multiple times a day, it’s crucial to deliver as efficiently as possible. This team is tasked with providing trusted representative environments for testing to other teams in order to perform functional, integration, and performance validations that meet their product release timelines. This is done via a platform layer that promotes an automated, self-service capability for the teams that rely on it. But when you’re working to support an ever-moving target, some common pitfalls can occur.

如果您的团队章程要支持许多内部团队的基础架构需求，而这些团队正在快速创新并每天多次发布变更，则至关重要的是要尽可能高效地交付。该团队的任务是为其他团队提供可信赖的代表性测试环境，以执行符合其产品发布时间表的功能，集成和性能验证。这是通过平台层完成的，该平台层为依赖它的团队提升了自动化的自助服务功能。但是，当您为支持不断变化的目标而努力时，可能会遇到一些常见的陷阱。

The fast pace of work can lead to duplication of efforts, because teams are working in isolation and only doing the work that they need to benefit their own development. These teams may be implementing the same behavior in slightly different ways. Onboarding new team members becomes challenging, and developer productivity is impacted by the constant context switching required when there’s no set standard for contributing to different repos. A pitfall of such an effort is that, when a new feature is needed team wide, if each repository maintains its own implementation of the functionality, then the same feature change has to be propagated to each different repository. Imagine if, out of the 10 repositories owned by your team, the functionality is propagated to all repositories except the one repository that delivers artifacts to production!

快速的工作节奏可能导致工作重复，因为团队处于孤立状态，仅做自己需要的工作，以使自己的发展受益。这些团队可能以略有不同的方式实施相同的行为。新团队成员的入职变得充满挑战，并且在没有针对不同回购协议做出贡献的固定标准时，开发人员的工作效率会受到不断不断的上下文切换的影响。这种工作的一个陷阱是，当需要在团队范围内使用新功能时，如果每个存储库都维护自己的功能实现，则必须将相同的功能更改传播到每个不同的存储库。想象一下，如果在您团队拥有的10个存储库中，该功能会传播到所有存储库，除了将一个工件交付生产的一个存储库！

That’s where inner sourcing comes in. Inner sourcing is the use of open source practices for software development inside the confines of a single organization. It can be a great tool to help break down silos, encourage internal collaboration, accelerate new engineer onboarding, and even identify opportunities to contribute code back to the open source world. Let’s look at a small case study of how inner sourcing is helping the team at Salesforce that’s responsible for providing a test environment platform for other teams across the company.

那就是内部采购的来源。内部采购是在单个组织范围内使用开源实践进行软件开发的方法。它可能是一个很好的工具，可以帮助您打破各自为政的局面，鼓励内部协作，加快新工程师的入职时间，甚至可以找到机会将代码贡献给开源世界。让我们看一下内部采购如何帮助Salesforce团队的小案例研究，该团队负责为公司中其他团队提供测试环境平台。

To work within our continuous delivery system, teams generate a deployment manifest file that tells the system what version of their service to deploy and and where to deploy it. Teams all have their own ways of doing this, and the manifest may be either a JSON or a YAML file, depending on their configuration. But since the creation of this file is a common need, why not standardize it?

为了在我们的持续交付系统中工作，团队会生成一个部署清单文件，该文件告知系统要部署的服务版本以及在何处进行部署。团队都有各自的方式，清单可能是JSON或YAML文件，具体取决于他们的配置。但是由于创建此文件是普遍需要，为什么不对其进行标准化？

Another similar requirement we have been seeing across our organization is having to interact with Git, since our tools need to trigger a multitude of interactions with Git. To name a few, our tools need to create PRs and add review comments to existing PRs for visibility automatically. With multiple projects needing this same set of functionalities, this is another strong contender to be moved to a common project, with all different teams simply consuming and building on top of it rather than reinventing the exact functionality in different ways. If a new interaction with Git is required, the consumer can contribute back to the common repository, adding this functionality across the teams and organizations.

我们在组织中看到的另一个类似要求是必须与Git进行交互，因为我们的工具需要触发与Git的多种交互。仅举几例，我们的工具需要创建PR，并在现有PR中添加评论注释以自动显示。由于多个项目需要相同的功能集，因此这是要移到一个公共项目的另一个有力竞争者，所有不同的团队都只是在其中消费和构建，而不是以不同的方式重新定义确切的功能。如果需要与Git进行新的交互，则使用者可以向通用存储库做出贡献，从而在团队和组织中添加此功能。

The Test Environment Platform team consolidated these deployment functionalities — cloning repositories and creating PRs, generating deployment manifests, interacting with Slack etc. — and opened them up for consumption and collaboration. Teams are able to incorporate these centralized libraries through API calls or import statements. If a change needs to be made to the process, it can be made in the shared repo and delivered to all users at once. (To ensure regressions aren’t introduced by updates, teams are able to specify what version of the service they are using.) The shared module was created following both industry and internal best practice standards, mitigating the risk of team-specific biases getting baked in. Security policies can also be standardized when code is provided centrally. Inner sourcing this functionality frees teams up to focus on building and deploying their applications and services rather than maintaining infrastructure.

Test Environment Platform团队整合了这些部署功能-克隆存储库和创建PR，生成部署清单，与Slack交互等-并开放了它们以供使用和协作。团队能够通过API调用或导入语句来合并这些集中式库。如果需要对流程进行更改，则可以在共享存储库中进行更改并立即交付给所有用户。 (为确保更新不会引起回归，团队可以指定他们使用的服务的版本。)共享模块是根据行业和内部最佳实践标准创建的，从而减轻了因团队而异的偏见的风险。当集中提供代码时，安全策略也可以标准化。通过内部采购此功能，团队可以腾出精力来专注于构建和部署其应用程序和服务，而无需维护基础架构。

Documentation is crucial when it comes to inner sourced repositories, because it’s challenging to make sure the shared functionality is discoverable and that teams know how to implement it if they determine it will be useful for them. Documentation also helps individual engineers determine whether a piece of code they’re working on may be useful outside of their own use case and should therefore be contributed to the shared repo. Without good documentation, inner sourced projects can fizzle out if the main contributor leaves the company or moves to working on a new project.

当涉及内部源存储库时，文档至关重要。因为要确保共享功能是可发现的，并且团队知道如何确定共享功能对他们很有用，这是一个挑战。文档还可以帮助工程师确定他们正在使用的一段代码在他们自己的用例之外是否有用，因此应将其贡献给共享存储库。如果没有良好的文档，则如果主要撰稿人离开公司或着手进行新项目，则内部来源项目可能会失败。

Testing is another crucial piece of a successful inner sourced project. Complete unit and integration tests define the criteria for whether shared code is ready for consumption and help teams using it avoid issues at runtime. Having a well-defined test suite instills confidence in people absorbing the shared repository and also makes sure that addition of new features doesn’t break existing functionality. This becomes very important when multiple teams could be affected by a small error which slipped a developer’s notice. The tools we use ensure that we adhere to standard quality gates (such as minimum 80% code coverage, Sonarqube quality gates on code maintainability, etc.), thereby assuring the different teams building on top of our offerings that the repositories they are consuming are well tested. These metrics are visible publicly for transparency. When users contribute back to our projects, if benchmarks such as code coverage fall below a set minimum on the new code being added, we block the merges unless the user fixes this. This ensures that we stick to our promise of trust and customer success being delivered to our consumers.

测试是成功的内部项目的另一个关键部分。完整的单元和集成测试定义了共享代码是否准备就绪可供使用的标准，并帮助使用它的团队避免在运行时出现问题。拥有定义良好的测试套件可以使人们对使用共享存储库的信心充满信心，还可以确保添加新功能不会破坏现有功能。当多个团队可能会受到一个小错误的影响而导致开发者的注意失误时，这变得非常重要。我们使用的工具可确保我们遵守标准的质量门(例如，最低80％的代码覆盖率，代码可维护性方面的Sonarqube质量门等)，从而确保在我们产品之上构建的不同团队所使用的存储库是经过充分测试。这些指标是公开可见的，以提高透明度。当用户回馈我们的项目时，如果代码覆盖率之类的基准低于所添加新代码的设定最小值，除非用户解决此问题，否则我们将阻止合并。这确保了我们恪守对消费者的信任和客户成功的承诺。

Opening the shared repository up for feedback and collaboration makes it better for everyone using it. This is relatively common in open source, as well. It doesn’t have to be anything as formalized as a committee, but rather, any proposed change should be considered across all use cases by having a range of reviewers examine it before pushing the change.

打开共享存储库以进行反馈和协作，使使用它的每个人都更好。这在开放源代码中也相对常见。它不必像委员会那样正式化，而应在所有用例中考虑任何建议的更改，方法是让一系列审核员在推动更改之前对其进行检查。

Moving toward inner sourcing critical code components requires a cultural shift, but we’ve found it to be well worth the uphill climb for the benefits across productivity, standardization, and new team member onboarding. If you see a key functionality being implemented in multiple different ways as we did, or a piece of code that satisfies a common goal but is currently housed within a single team, why not try applying inner source practices to it and seeing what happens? Start small. GitHub’s introduction to inner source says,

向内部采购关键代码组件迈进需要文化上的转变，但是我们发现在生产力，标准化和新成员入职方面的收益值得进行艰苦的攀登。如果您看到像我们一样以多种不同方式实现了关键功能，或者满足了一个共同目标但当前驻留在一个团队中的一段代码，为什么不尝试将内部源代码实践应用于它并看看会发生什么呢？从小开始。 GitHub的内部源代码介绍说，

“Pilot projects can help teams experiment with more open processes, democratize access to code, and document best practices before applying innersource more widely. Small successes can help show your internal community of developers how to make the most of their code and ship better software, faster.”

“试点项目可以帮助团队尝试更开放的流程，使对代码的访问民主化，并在更广泛地应用内部资源之前记录最佳实践。小小的成功可以帮助您向内部开发人员社区展示如何充分利用他们的代码并更快地交付更好的软件。”

Inner source is also a great first step toward open source; if a project has the potential to be open sourced later, applying the same principles to it via inner source first makes it stronger.

内源也是朝向开源很大第一步骤; 如果一个项目有可能在以后开源，则首先通过内部源将相同的原理应用于该项目可以使其更强大。

For ourselves, we’ve been reaping the rewards of creating a centralized module for executing git operations from the get go. We currently have two different projects with org-wide visibility. Using a common repository that provides common functionality really accelerated our development cycle. Both projects simply imported the functionality they needed (manifest generation, creating automated PRs) and the only thing the developers had to be concerned about was building project-specific functionality on top of it without needing to worry about how to create PRs or generate manifests on their own. Our repo is also being used by other teams to now generate their manifests automatically, rather than having to generate one by themselves. And, what is even more exciting, is that we are seeing contribution requests as well, where consumers want to give back and add functionality that can benefit the tool! Inner sourcing has not only saved our team development cycles, but benefitted other teams as well, where they don’t have to spend time and effort on developing a common functionality.

对于我们自己，我们一直在收获创建一个集中式模块以从一开始就执行git操作的收获。我们目前有两个具有组织范围可见性的不同项目。使用提供通用功能的通用存储库确实加快了我们的开发周期。这两个项目都只是导入了所需的功能(清单生成，创建自动PR)，而开发人员唯一需要担心的是在其之上构建特定于项目的功能，而无需担心如何在其上创建PR或生成清单。他们自己的。其他团队现在也使用我们的仓库来自动生成清单，而不必自己生成清单。而且，更令人兴奋的是，我们也看到了贡献请求，消费者希望回馈并添加有益于该工具的功能！内部采购不仅节省了我们的团队开发周期，而且也使其他团队受益，因为他们无需花费时间和精力来开发通用功能。

There is still work to be done toward building a culture of inner source, and we’re excited to continue sharing the success of this project as an example of what can be achieved when we work together.

建立内部资源文化还需要做很多工作，我们很高兴能继续分享这个项目的成功，以此作为我们共同努力可以取得的成就的一个例子。

For a deeper dive in the what, why, and how of inner sourcing, check out this series by Demian Brecht:Inner Sourcing: What’s This?Inner Sourcing: The MechanicsInner Sourcing: The Ups and Downs

要深入了解内部采购的内容，原因和方式，请查看Demian Brecht的以下系列文章： 内部采购：这是什么？ 内部采购：力学 内部采购：起伏