Artifactory、Chef 和 Chocolatey 如何协同工作？
How does Artifactory, Chef and Chocolatey work together?
我们正在实施 CI/CD 管道并使用 TFS 作为我们的代码存储库和构建和发布工具。我有以下具体问题：
- 我们目前将构建期间所需的库和第 3 方工具存储在我们的代码存储库中。我们想分析存储和访问 3rd 方工具和库的其他方式。
- Artifactory 是存储它们的正确工具吗？据我了解，Artifactory 应该只用于存储可以丢弃和重新创建的构建工件。
- 或者使用 Chocolatey 是更好的选择吗？据我了解，我们需要从我们的第 3 方工具和库中创建 Chocolatey 包。在哪里：
- 这些包的来源，例如(.exe, .dll, .zip, .msi) 通常驻留？
- 在 UNC 文件位置？
- 或者像 Artifactory 这样的二进制存储库？
- 使用二进制存储库存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，每个新版本都会增加存储库的大小。
- Chocolatey 包本身位于何处？
- 在 UNC 文件位置？
- 或者像 Artifactory 这样的二进制存储库？
- 使用二进制存储库存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，每个新版本都会增加存储库的大小。
- 如果我们将第 3 方工具和库存储在我们的代码存储库之外
- 我们需要使用 Chef 和 Chocolatey 来访问它们吗？
- 或者我们可以使用 Chocolatey 直接从 TFS 访问它们，而不必在构建过程中使用 Chef 吗？
- 我是否正确地认为 Chef 主要用于在开始构建过程之前使用所需的软件和环境变量设置构建环境？
让我们看看我能否为您分解一下。
We currently store the libraries and 3rd party tools that we require during our build in our code repository. We would like to analyze other ways of storing and accessing 3rd party tools and libraries.
- Would Artifactory be a right tool to store them into?
是的，Artifactory 和其他包存储库服务器通常有一个 binary/raw 存储库，这将是一个不错的选择。将 Artifactory 视为放置生产使用工件的地方。因此，这些库、第 3 方工具、第 3 方软件、模块等都可以存储在 Artifactory 中不同类型的存储库中。 Artifactory 将是一个企业级包存储库管理器，经过优化可以处理高可用性等。您可以在此处存储、保护和部署二进制文件、程序包、软件等。这可以是开发、测试、阶段和生产环境。
- As far as I understand Artifactory should only be used for storing build artifacts that can be thrown away and recreated.
我认为这有点不对劲 - 很接近了。您可能会存储可以丢弃并重新创建的构建工件，但您也可以在那里存储更多的东西。以这种方式陈述它并没有真正充分说明它实际可以做的事情。
- OR is using Chocolatey a better option?
这不是 Artifactory 的竞争选项。 Chocolatey 包可以存储在 Artifactory (Pro) 中的 NuGet 类型存储库中。二进制文件要么是 IN Chocolatey 包，要么可能在 binary/raw 存储库中。
Artifactory 是包存储库存储，其中 Chocolatey 是 Windows 的包管理器（软件管理和部署）。
As far as I understand we would need to create Chocolatey packages from our 3rd party tools and libraries. Where does:
the source of those packages e.g. (.exe, .dll, .zip, .msi) usually reside?
- In an UNC file location?
- Or in a binary repository like Artifactory?
- Is using a binary repository to store build-time dependencies the correct approach?
您忘记了最常用和推荐的方法：
- 在包本身中
Chocolatey 包本身是保存包所代表的二进制文件的最推荐位置。这是包的最确定性和最可靠的方法。
问题是您可能正在查看社区包存储库作为打包的示例 - 我们建议不要这样做，因为它不代表但可能有 5% 的包在那里。我们不建议采用该方法，因为它不是可靠的方法。
- It would need to reside there permanently and every new version is going to add to the repository size.
这是事实，但是 Artifactory 确实有一种剔除方法（我相信）并且它针对这些类型的场景进行了优化。我们在 https://chocolatey.org/docs/how-to-host-feed#commercial-repository-system-requirements.
查看了针对不同商业存储库解决方案的系统要求建议
- the Chocolatey packages themselves reside?
- In an UNC file location?
他们绝对可以，但请记住权限如何与文件共享和 Windows 权限一起使用 - https://chocolatey.org/docs/how-to-host-feed#local-folder-permissions
- Or in a binary repository like Artifactory?
不，那将是 Artifactory Pro 中可用的 NuGet OData 存储库。是的，NuGet Artifactory 存储库将是一个好地方，并且可以针对不同的环境、权限等使用多个存储库。任何对您的环境有意义的东西。
- Is using a binary repository to store build-time dependencies the correct approach? It would need to reside there permanently and every new version is going to add to the repository size.
我认为这是在别处处理的。
- If we store the 3rd party tools and libraries outside of our code repository
- Do we need to use Chef and Chocolatey to access them?
- OR can we access them directly from TFS using Chocolatey without having to use Chef in the build process?
你通常可以做任何一个。如果您确实将第 3 方工具放入软件部署包（又名 Chocolatey 包），您将需要 Chocolatey 来管理部署。
- Am I correct into thinking that Chef is primarily used to setup build environments with the required software and environment variables before starting a build process?
我会说你误解了 Chef - 它是一个配置管理解决方案。它可以设置构建环境并将它们保持在所需状态，但这限制了功能。 Chef（和其他配置管理器）用于为您的基础架构（基础架构即代码）编写期望状态（期望状态）的脚本，您可以在部署之前检查源代码控制并测试整个基础架构更改可能使用持续集成（CI) Jenkins、TeamCity、TFS 等服务器来执行此操作（这会带来测试基础设施、测试驱动的基础设施等）等。对于开发人员来说，这有点直观，但对于房屋运营方面的人来说，这是将这些开发实践带入运营的全新方式。我称之为现代自动化，但有些人将这些转变称为 DevOps。
推荐
您可以使用 Chef + Chocolatey + Artifactory 解决方案来管理整个组织的软件和机器配置，而不仅仅是开发环境。我认为您有可能从开发人员类型职位的参考框架中接触所有这些工具，因此只是在供应的背景下思考，而不是运营/系统管理员可能对部署、配置等进行长期管理看着。这些工具当然都会增加一些东西，但它们都是免费的，根本不是竞争解决方案。对于许多较大的组织，将这些或类似的组件放在适当的位置会产生一种架构，可以处理当今组织的关键基础设施需求。
我们正在实施 CI/CD 管道并使用 TFS 作为我们的代码存储库和构建和发布工具。我有以下具体问题：
- 我们目前将构建期间所需的库和第 3 方工具存储在我们的代码存储库中。我们想分析存储和访问 3rd 方工具和库的其他方式。
- Artifactory 是存储它们的正确工具吗？据我了解，Artifactory 应该只用于存储可以丢弃和重新创建的构建工件。
- 或者使用 Chocolatey 是更好的选择吗？据我了解，我们需要从我们的第 3 方工具和库中创建 Chocolatey 包。在哪里：
- 这些包的来源，例如(.exe, .dll, .zip, .msi) 通常驻留？
- 在 UNC 文件位置？
- 或者像 Artifactory 这样的二进制存储库？
- 使用二进制存储库存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，每个新版本都会增加存储库的大小。
- Chocolatey 包本身位于何处？
- 在 UNC 文件位置？
- 或者像 Artifactory 这样的二进制存储库？
- 使用二进制存储库存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，每个新版本都会增加存储库的大小。
- 这些包的来源，例如(.exe, .dll, .zip, .msi) 通常驻留？
- 如果我们将第 3 方工具和库存储在我们的代码存储库之外
- 我们需要使用 Chef 和 Chocolatey 来访问它们吗？
- 或者我们可以使用 Chocolatey 直接从 TFS 访问它们，而不必在构建过程中使用 Chef 吗？
- 我是否正确地认为 Chef 主要用于在开始构建过程之前使用所需的软件和环境变量设置构建环境？
让我们看看我能否为您分解一下。
We currently store the libraries and 3rd party tools that we require during our build in our code repository. We would like to analyze other ways of storing and accessing 3rd party tools and libraries.
- Would Artifactory be a right tool to store them into?
是的，Artifactory 和其他包存储库服务器通常有一个 binary/raw 存储库，这将是一个不错的选择。将 Artifactory 视为放置生产使用工件的地方。因此，这些库、第 3 方工具、第 3 方软件、模块等都可以存储在 Artifactory 中不同类型的存储库中。 Artifactory 将是一个企业级包存储库管理器，经过优化可以处理高可用性等。您可以在此处存储、保护和部署二进制文件、程序包、软件等。这可以是开发、测试、阶段和生产环境。
- As far as I understand Artifactory should only be used for storing build artifacts that can be thrown away and recreated.
我认为这有点不对劲 - 很接近了。您可能会存储可以丢弃并重新创建的构建工件，但您也可以在那里存储更多的东西。以这种方式陈述它并没有真正充分说明它实际可以做的事情。
- OR is using Chocolatey a better option?
这不是 Artifactory 的竞争选项。 Chocolatey 包可以存储在 Artifactory (Pro) 中的 NuGet 类型存储库中。二进制文件要么是 IN Chocolatey 包，要么可能在 binary/raw 存储库中。
Artifactory 是包存储库存储，其中 Chocolatey 是 Windows 的包管理器（软件管理和部署）。
As far as I understand we would need to create Chocolatey packages from our 3rd party tools and libraries. Where does: the source of those packages e.g. (.exe, .dll, .zip, .msi) usually reside?
- In an UNC file location?
- Or in a binary repository like Artifactory?
- Is using a binary repository to store build-time dependencies the correct approach?
您忘记了最常用和推荐的方法：
- 在包本身中
Chocolatey 包本身是保存包所代表的二进制文件的最推荐位置。这是包的最确定性和最可靠的方法。
问题是您可能正在查看社区包存储库作为打包的示例 - 我们建议不要这样做，因为它不代表但可能有 5% 的包在那里。我们不建议采用该方法，因为它不是可靠的方法。
- It would need to reside there permanently and every new version is going to add to the repository size.
这是事实，但是 Artifactory 确实有一种剔除方法（我相信）并且它针对这些类型的场景进行了优化。我们在 https://chocolatey.org/docs/how-to-host-feed#commercial-repository-system-requirements.
查看了针对不同商业存储库解决方案的系统要求建议
- the Chocolatey packages themselves reside?
- In an UNC file location?
他们绝对可以，但请记住权限如何与文件共享和 Windows 权限一起使用 - https://chocolatey.org/docs/how-to-host-feed#local-folder-permissions
- Or in a binary repository like Artifactory?
不，那将是 Artifactory Pro 中可用的 NuGet OData 存储库。是的，NuGet Artifactory 存储库将是一个好地方，并且可以针对不同的环境、权限等使用多个存储库。任何对您的环境有意义的东西。
- Is using a binary repository to store build-time dependencies the correct approach? It would need to reside there permanently and every new version is going to add to the repository size.
我认为这是在别处处理的。
- If we store the 3rd party tools and libraries outside of our code repository
- Do we need to use Chef and Chocolatey to access them?
- OR can we access them directly from TFS using Chocolatey without having to use Chef in the build process?
你通常可以做任何一个。如果您确实将第 3 方工具放入软件部署包（又名 Chocolatey 包），您将需要 Chocolatey 来管理部署。
- Am I correct into thinking that Chef is primarily used to setup build environments with the required software and environment variables before starting a build process?
我会说你误解了 Chef - 它是一个配置管理解决方案。它可以设置构建环境并将它们保持在所需状态，但这限制了功能。 Chef（和其他配置管理器）用于为您的基础架构（基础架构即代码）编写期望状态（期望状态）的脚本，您可以在部署之前检查源代码控制并测试整个基础架构更改可能使用持续集成（CI) Jenkins、TeamCity、TFS 等服务器来执行此操作（这会带来测试基础设施、测试驱动的基础设施等）等。对于开发人员来说，这有点直观，但对于房屋运营方面的人来说，这是将这些开发实践带入运营的全新方式。我称之为现代自动化，但有些人将这些转变称为 DevOps。
推荐
您可以使用 Chef + Chocolatey + Artifactory 解决方案来管理整个组织的软件和机器配置，而不仅仅是开发环境。我认为您有可能从开发人员类型职位的参考框架中接触所有这些工具，因此只是在供应的背景下思考，而不是运营/系统管理员可能对部署、配置等进行长期管理看着。这些工具当然都会增加一些东西，但它们都是免费的，根本不是竞争解决方案。对于许多较大的组织，将这些或类似的组件放在适当的位置会产生一种架构，可以处理当今组织的关键基础设施需求。