【发布时间】：2019-04-03 10:36:13
【问题描述】：
我在搞乱一些 FAKE 和 Paket（在 F# 上）和 Jenkins，我不太确定我知道自己在做什么，但我知道我想做什么。
简短的描述是我希望构建服务器针对引用的包构建整个系列的相关服务，但包有不同的风格（但共享相同的基本命名空间/模块名称）。
详细说明； 我有一系列服务，位于外部 API。 IE。 它们都是引用一些外部包并通过模块等访问它。
例如
ServiceA.fsprj
...
let f (x : ExternalApi.Foo) = ....
---------------
ServiceB.fsprj
...
let g (x : ExternalApi.Foo) = ....
开发人员可能会针对最常见的风格进行开发，比如说 ExternalApiVanilla。 开发人员将使用 Paket、Fake 作为构建工具以及 Jenkins。
当代码被签入时，虽然我希望构建服务尝试构建它来对抗香草味......但也对抗巧克力、草莓和香蕉。
风味不是版本号意义上的“版本”，它们是不同的产品，具有自己的 nuget 包。所以我想（不知何故）我想用 api 包的名称参数化一个包含所有作业的 jenkins 文件夹，将其传递到构建脚本中，然后让构建脚本换出工程师引用的任何内容并引用参数.
当然有些编译会失败，我们必须开发不同的服务变体来处理 API 的一些变体，但是我们 90% 的东西都适用于所有版本，我们只需要一种自动化的方式来检查构建，然后创建服务和作业的新变体来处理它们。
顺便说一句，我们正在用 C# 和 cake/nuget 做一些事情，但是通过将 nuget 文件夹传入并强制构建找到 1 种风味的特定版本来控制版本控制...虽然我不会可以写，但我想更进一步，将引用本身替换为不同的。
——————-
我将尝试查看构建脚本中的 paket.dependencies/paket 引用文件，删除现有引用，并从 shell 和 paket 添加 jenkins 定义的文件，然后 aee 会发生什么，不特别喜欢它，我依赖关于这些文件的格式，我希望这会成为主流
【问题讨论】：
-
您是否考虑过拥有几个不同的项目文件？
-
是的......但这需要重复 100 多个项目来添加对某些东西的引用，而这几乎总是不必要的
-
如果我有 100 个项目和 5 种不同的风格，我最终会得到 500 个项目，而我实际上只需要大约 150 个
-
我认为如果你有一百个项目一起构建，你就会遇到更大的问题。
-
?我不认为这特别奇怪......我不会声称 emporers 是微服务的新衣服，但这种架构相当普遍
标签： f# continuous-integration f#-fake paket