NuGet Enterprise - 不同成熟度级别的包的最佳实践 [英] NuGet Enterprise - best practices for different maturity levels of packages

问题描述

我们希望使用 NuGet 在我们组织的开发人员之间共享程序集.我们目前正在考虑设置三个 NuGet 提要，如下所示:

We want to use NuGet to share assemblies amongst developers in our organisation. We are currently looking at setting up three NuGet feeds, like this:

• 发布源:程序集的稳定发布质量版本.
• QA-feed: 在主分支(我们的集成分支)中构建的程序集.
• Development-feed: 在任何功能分支中构建的程序集(共享进度).

• Release-feed: Stable release-quality versions of the assemblies.
• QA-feed: Assemblies built in the master-branch (our integration branch).
• Development-feed: Assemblies built in any of the feature branches (sharing progress).

不应将开发人员机器上的本地构建发送到任何这些提要.只有构建服务器完成的构建才能完成这些.我们的构建服务器执行三种不同类型的构建，具体取决于分支、开发、QA 和发布分支.其中每一个都具有相应的构建配置，可在源更改时触发.在构建时，他们每个人都会将构建的 assembly-nuget-packages 推送到相应的提要.Development-builds 将在版本中添加-dev".QA 版本将在版本中添加-qa"，而 Release 版本将具有纯"版本号.

Local builds on the developers' machines should not be sent to any of these feeds. Only the builds done by the build-server is to do these. Our build server performs three different types of builds, depending on the branch, Development, QA and Release branches. Each of these with corresponding build-configurations that triggers on source changes. On build each of them will push the built assembly-nuget-packages to their corresponding feed. The Development-builds will add "-dev" to the version. The QA builds will add "-qa" to the version, while the Release builds will have a "pure" version number.

现在，问题:

1. 开发人员控制使用哪些包的最佳解决方案是什么?我猜开发人员必须手动编辑依赖源参数以明确定义从哪些源获取程序集:有时您需要发布程序集，有时需要 QA 程序集，有时您甚至需要最前沿的开发版本.

1. What would be the best solution for the dev to control what packages to use? I guess the dev manually have to edit the dependency source param to explicitly define what feeds to get the assemblies from: Sometimes you want the release assembly, sometimes the QA assembly and sometimes you even want the bleeding edge Development version.

我们还在考虑将本地构建包推送到每个开发人员自己机器上的本地私有源，以帮助加快构建速度.从哪些供稿中获取信息会有问题吗?

We are also considering pushing local build packages to a local private feed on each devs' own machine, to help speedup the builds. Would that be problematic in terms of which feed(s) to get from?

如果这些定义是由开发人员在依赖项文件(也必须是版本控制的)中进行的，那么当源提交到存储库时，该设置将被带入开发提要(与作为开发人员构建，只是与他人共享).对于开发供稿来说，这可能是也可能不是正确的做法?

If those definitions are made by the dev in the dependencies-file (which is also necessarily version controlled) then that setting would be brought into the Development feed when the source is committed to the repo (same focus for the build as the developer, just sharing with others). This may or may not be the right thing for the Development feed?

当源然后合并到一个 qa 分支时，依赖项中定义的提要仍然是开发者制作的，可能从开发提要中获取程序集.对于 QA 版本，我认为这可能不是我们想要的.QA 构建可能应该仅将提要限制为发布程序集，因为您想查看更改是否按预期与发布组件一起工作.您不想使用其他未经测试"的 QA 程序集对其进行测试.这对其他人也有意义吗?

When the source is then merged into a qa-branch the feeds defined in the dependencies would still be as the dev made them, possibly getting assemblies from Development feeds. For the QA builds I think this would probably not be what we want. QA builds should probably constraint the feeds to Release assemblies only, as you want to see if the changes works as expected with Release components. You don't want to test it with other "untested" QA assemblies. Does this make sense to others too?

在发布分支中，发布版本应该只使用发布提要程序集，我猜?我觉得可能会就此达成共识，所以也许根本不是一个真正的问题:)

In the release branch the release builds should use only release feed assemblies, I guess? I have a feeling that there might be consensus on this, so maybe not not really a question at all :).

<小时>

所以，总结一下建议的过程......在构建过程中，我们将:

---

So, to sum up the process suggested... During builds we are to:

• 遵循开发人员在本地和开发构建的依赖项规范中设置的源.
• 在进行 QA 和发布构建时，提要应仅限于发布提要.

作为旁注，QA 提要实际上不会被任何其他构建使用.但是，它们将由 QA 部门使用，因为他们会将这些用于测试.

推荐答案

在我看来，您建议的流程太复杂了，无论是对于您现在的团队规模还是未来一年的团队规模.

In my view, the process you suggest is too complicated, both for your team size now and for the team size a year ahead.

我理解您认为需要三个独立提要(开发、质量检查、发布)的原因，但我预测这将在一年后让您痛苦.我希望您希望在软件包从 Dev 到 QA 再到 Release 的过程中增加对稳定性/质量的信心——这是一个完全合理的要求.然而，许多人认为单独的分支，尤其是单独的构建用于开发、质量检查和发布是一种反模式.具体来说，在 Humble 和 Farley 撰写的开创性著作 Continuous Delivery 中，强烈建议只使用来自哪些构建被采用，如果测试通过，任何应该能够被提升到生产环境:只构建一次代码"是关键.

I understand the reasons why you think you need three separate feeds (Dev, QA, Release), but I predict this will become painful for you in a year's time. I expect that you want to increase the confidence in the stability/quality of the packages as they progress from Dev to QA to Release - a completely reasonable requirement. However, separate branches and especially separate builds for Dev, QA, and Release is considered by many to be an anti-pattern. Specifically, in the seminal book Continuous Delivery by Humble and Farley, it's strongly recommended to have only a single code base from which builds are taken, and any of those builds should be capable of being promoted to Production if tests pass: "Build your code only once" is the key.

我建议您:

1. 使用 CI 工具为部署管道建模:Jenkins、TeamCity、TW GO 等.这为将工件直接从初始 CI 构建一直到生产而无需重新构建提供了一个很好的先例
2. 使用语义版本控制(在 .NET 世界中称为 SemVer)来保护包消费者免受破坏性更改，并传达包更改的性质到其他团队.
3. 在 packages.config 中使用版本范围限制，这样构建就不会被新的主要版本的包(有重大更改)破坏
4. 让开发团队负责从代码提交到生产的特定包——如果他们维护的包之一出现问题，他们需要迅速提供修复，以免其他团队被阻止.团队还需要遵守纪律，以确保他们通过 SemVer 传达包更改的性质(这是重大更改?新功能?错误修复?)
5. 如果您觉得有必要，请使用 NuGet 的预发布功能从下游构建和测试中隐藏"新的包版本.这可能会让开发团队更有效地进行更改，但如果您使用允许快速制作和交付新软件包版本的部署管道，则可能没有必要.

1. Use a CI tool which allows you to model a deployment pipeline: Jenkins, TeamCity, TW GO, etc. This sets a good precedent for flowing artifacts directly from the initial CI build all the way to Production without a re-build
2. Use semantic versioning (called SemVer in the .NET world) to protect package consumers from breaking changes, and to communicate the nature of package changes to other teams.
3. Use version range constraints in packages.config so that builds are not broken by new Major versions of packages (with breaking changes)
4. Make dev teams responsible for specific packages from code commit to Production - if one of the packages they maintain has problems, they need to provide a fix rapidly so that other teams are not blocked. Teams also need discipline to ensure that they communicate the nature of package changes via SemVer (is it a breaking change? a new feature? a bug fix?)
5. If you feel it's necessary, use the Prerelease feature of NuGet to 'hide' new package versions from downstream builds and testing. This might allow dev teams to make changes more effectively, but will probably not be necessary if you use deployment pipelines which allow new package versions to be made and delivered rapidly.

简而言之，只需构建一次源代码，并设置自动化，以便可以使用部署管道快速推出对现有包的任何修复.

In short, only build your source code once, and set up automation such that any fixes to existing packages can be rolled out rapidly using the deployment pipeline.

这篇关于NuGet Enterprise - 不同成熟度级别的包的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！