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:

• Release-feed: 程序集的稳定发布质量版本.
• 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?

如果这些定义是由开发人员在依赖文件中进行的(这也必须是版本控制的)，那么当源提交到 repo 时，该设置将被引入开发提要(同样关注作为开发人员构建，只是与他人共享).这对于开发提要可能是正确的，也可能不是?

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-branch 时，依赖项中定义的提要仍然是开发人员制作的，可能从开发提要中获取程序集.对于 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 和发布构建时，Feed 应仅限于发布 Feed.

附带说明，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)的原因，但我预计这将在一年后让您感到痛苦.我希望您希望在软件包从 Dev 到 QA 再到 Release 的过程中提高对软件包稳定性/质量的信心——这是一个完全合理的要求.但是，许多人认为，针对 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.

我建议您不要使用您概述的模式:

Instead of the pattern you outline, I would recommend that you:

1. 使用允许您为部署管道建模的 CI 工具em>: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屋！