Artifactory、Chef 和 Chocolatey 如何协同工作？

Question

我们正在实施 CI/CD 管道，并使用 TFS 作为我们的代码存储库以及构建和发布工具。我有以下具体问题：

1. 目前，我们将构建过程中所需的库和第三方工具存储在代码存储库中。我们想分析存储和访问第三方工具和库的其他方式。
   • Artifactory 是存储它们的合适工具吗？据我了解，Artifactory 应该只用于存储可以丢弃和重新创建的构建工件。
   • 或者使用 Chocolatey 是更好的选择吗？据我了解，我们需要从我们的第三方工具和库创建 Chocolatey 包。哪里做：
     • 这些软件包的源代码（例如（.exe、.dll、.zip、.msi））通常位于何处？
       • 在 UNC 文件位置？
       • 或者在像 Artifactory 这样的二进制存储库中？
       • 使用二进制存储库来存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，并且每个新版本都会增加存储库的大小。
     • Chocolatey 包本身位于何处？
       • 在 UNC 文件位置？
       • 或者在像 Artifactory 这样的二进制存储库中？
       • 使用二进制存储库来存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，并且每个新版本都会增加存储库的大小。
2. 如果我们将第三方工具和库存储在我们的代码存储库之外
   • 我们需要使用 Chef 和 Chocolatey 来访问它们吗？
   • 或者我们可以使用 Chocolatey 直接从 TFS 访问它们，而无需在构建过程中使用 Chef？
3. 我是否正确地认为 Chef 主要用于在开始构建过程之前使用所需的软件和环境变量设置构建环境？

Answer 1

Let's see if I can break this down for you.

1. 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?

Yes, Artifactory and other package repository servers typically have a binary/raw repository that would be a good option. Think of Artifactory as a place to put your production use artifacts. So those libraries, 3rd party tools, 3rd party software, modules, etc could all be stored in different types of repositories in Artifactory. Artifactory would be an enterprise level package repository manager, optimized to do that, handle High Available, and more. You store, secure, and deploy binaries, packages, software, etc here. That can be to Dev, Test, Stage, and Production environments.

• As far as I understand Artifactory should only be used for storing build artifacts that can be thrown away and recreated.

I think this is a bit off - it's close. You could possibly store build artifacts that could be thrown away and recreated, but you can store so much more there as well. Stating it in this way doesn't really do enough justice into what it actually can do.

• OR is using Chocolatey a better option?

This is not a competing option to Artifactory. Chocolatey packages can be stored in Artifactory (Pro) in a NuGet type repository. The binaries would either be IN the Chocolatey packages or could be in a binary/raw repository.

Artifactory is a package repository store, where Chocolatey is a package manager (software management and deployment) for 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?

You forgot the often most used and recommended approach:

• In the package itself

In the Chocolatey package itself is the most recommended place to keep the binaries that a package represents. It's the most deterministic and reliable method for packages.

The problem is you may be looking at the community package repository as an example of packaging - we'd recommend NOT doing that as it doesn't represent but maybe 5% of packages out there. We don't recommend following that approach as it is not a reliable approach.

• It would need to reside there permanently and every new version is going to add to the repository size.

This is true, however Artifactory does have a culling approach (I believe) and it is optimized for these types of scenarios. We go over system requirements recommendations for different commercial repository solutions at https://chocolatey.org/docs/how-to-host-feed#commercial-repository-system-requirements.

• the Chocolatey packages themselves reside?

  • In an UNC file location?

They absolutely could, but do keep in mind how permissions work with file shares and Windows permissions - https://chocolatey.org/docs/how-to-host-feed#local-folder-permissions

• Or in a binary repository like Artifactory?

不，那将是 Artifactory Pro 中提供的 NuGet OData 存储库。是的，NuGet Artifactory 存储库将是一个好地方，并且可以针对不同的环境、权限等使用多个存储库。无论对您的环境有意义什么。

• 使用二进制存储库来存储构建时依赖项是正确的方法吗？它需要永久驻留在那里，并且每个新版本都会增加存储库的大小。

我认为这是在其他地方处理的。

2. 如果我们将第三方工具和库存储在我们的代码存储库之外

   • 我们需要使用 Chef 和 Chocolatey 来访问它们吗？
   • 或者我们可以使用 Chocolatey 直接从 TFS 访问它们，而无需在构建过程中使用 Chef？

通常您可以选择其中之一。如果您确实将第 3 方工具放入软件部署包（又名 Chocolatey 包）中，您将需要 Chocolatey 来管理部署。

3. 我是否正确地认为 Chef 主要用于在开始构建过程之前使用所需的软件和环境变量设置构建环境？

我想说你误解了 Chef - 它是一个配置管理解决方案。它可以设置构建环境并将其保持在所需的状态，但这限制了功能。Chef（和其他配置管理器）用于为您的基础设施（基础设施即代码）编写期望状态（期望状态），您可以在部署之前检查源代码控制并测试整个基础设施更改，可能使用持续集成（CI） ）像 Jenkins、TeamCity、TFS 这样的服务器（这会测试您的基础设施、测试驱动的基础设施等）等。对于开发人员来说，这有点直观，但对于操作方面的人员来说，这都是较新的将这些开发实践应用到运营中。我称之为现代自动化，但有些人将这种转变称为 DevOps。

推荐

您可以使用 Chef + Chocolatey + Artifactory 解决方案来管理整个组织的软件和机器配置，而不仅仅是开发环境。我认为您可能会从开发人员类型职位的参考框架中接触所有这些工具，因此只是在配置的背景下思考，而不是操作/系统管理员可能需要的部署、配置等的长期管理。看着。这些工具肯定会增加一些东西，但它们都是互补的，而不是任何竞争的解决方案。对于许多大型组织来说，将这些或类似的组件放置到位会产生一个可以满足当今组织的关键基础设施需求的体系结构。