通过阅读整个答案，我不确定在DevOps上下文中“工件”的确切含义。
有什么建议吗？
Ps：从一个答案中，我似乎了解到，也许我想知道的是假象（困惑？）。
#1 楼
维基百科对此问题有很好的答案。工件（有时也称为派生对象）是应用于代码存储库的某些过程的产物。它们最初被称为Build Artifacts，但是随着除了build以外的更多过程被应用来创建它们，第一个单词被简单地删除。同样的过程，前提是您保留了应用该过程的环境。由于此过程可能很耗时，并且无法完全保留环境以能够以完全相同的方式重建工件，因此我们开始将它们存储在工件存储库中。在工件存储库中，是DevOps工程师会做出的设计决策。一些公司（即Perforce）建议也将其代码存储库用作工件存储库。每个存储库在访问，审核，对象大小，对象标记和可伸缩性方面都有不同的要求，因此根据情况，通常最好使用两种不同的产品。例如，Git存储库将全部复制到每台开发机，因此将工件存储在代码存储库中会超出所有原因而增加其大小，尽管最近有一些方法可以减轻这种情况。另一个决定是要存储哪些工件。一些公司甚至将中间工件存储为单独的目标文件，以加快重建速度，而另一些公司仅存储最终的二进制文件。并非所有的工件都具有相同的值。发布版本生成的工件与开发人员生成的工件可能具有不同的要求。
最常见的工件是以下过程的结果：配置，预处理，编译，链接，自动化测试，归档，打包，媒体文件创建和处理，数据文件生成，文档解析，代码分析，QA等。
评论
关于git size的句子并不完全正确，使用git lfs可以缓解此问题。 （精度不高）
–滕西拜
17 Mar 10 '17 at 16:20
有趣的是，这甚至进一步证实了我的想法（猜测）。两件事：您的perforce链接需要修复，还有一个额外的问题：您是否也同意将“跟踪测试数据”（您使用的输入以及获得的输出）也视为此类工件？顺便说一句，这个答案让我想起“软件托管”（如果您熟悉的话）中使用的“验证级别”。我开始怀疑应该将软件托管主题视为DevOps主题...也许@Tensibai也可以对此发表评论？
– Pierre.Vriens♦
17 Mar 10 '17 at 16:24
@ Pierre.Vriens用于测试数据，这很难过，如果您的测试数据是数据库，则不符合工件概念。对于托管，我不知道这样的问题，如果问题足够集中就可以了。
–滕西拜
17 Mar 10 '17 at 16:26
@ Pierre.Vriens我的意思是说，有太多东西适合“测试数据”的名称（从简单的数字到示例数据库记录中的数百万个文件），以至于没有上下文就太广泛了。
–滕西拜
17 Mar 10 '17 at 16:34
@ Pierre.Vriens（对于通知，对不起Jiri）我认为与您的提供者的合同谈判不是主题，而您所描述的只是合法的谈判。
–滕西拜
17 Mar 10 '17 at 16:36
#2 楼
“人工制品”一词有两种用法，一种使源代码成为人工制品，而第二种使源代码成为非人工制品：这的确令人困惑！相对于理想事物–这是“人类制造的物体，通常是文化或历史利益之一”一词的常见含义，而不是专业术语。这是一个技术方面的示例：调试软件时，您会了解有关该软件的知识。将这种学习转变成软件产品（例如回归测试）通常是一笔宝贵的投资。否则，这种学习将被遗忘，并且浪费在学习上的精力将被浪费掉。在这种意义上，源代码被视为人工制品。“人工制品”是由配方产生的东西–这种含义使用了炼金术士的流行形象，即使用一些深奥的配方来制造神奇的装置，通常称为一件文物。它是一种技术术语，用于区分对应于炼金术士的隐喻中的配方的源代码和源自该源代码的，对应于炼金术士的隐喻中的人工制品的任何内容。例如，我只是为我的plop-fizz程序自动化了人工制品的生产，现在只需一个命令就可以实例化源tarball，签名文件，DEB和RPM软件包！此含义不能将源代码识别为伪造品，因为该术语用于表示从该源代码产生的内容。
#3 楼
我想答案可能会因地方而异。目前我在哪里工作，人工制品是其他实体消耗的任何东西，用于开发的源代码除外-进入源代码控制。这包括产品或其他所需产品的二进制文件，库，目标文件，媒体文件或测试数据之类的测试工件。
源代码不被视为工件。除非它与“ consumed by”的定义匹配-在我们的例子中包括第三方库，用于测试或其他目的的脚本代码（但不包括开发版本本身）。
评论
嗯，很有意思，您正在确认我的猜测。您是否同意我们所讨论的平台或操作系统并不重要。例如，即使对于大型机，一个“可能”也使用此术语。如果是这样，请问您能否在回答中也包含一些有关此的内容？
– Pierre.Vriens♦
17 Mar 10 '17 at 15:58
如果使用了版本控制中的实际代码，也可以/应该将其视为工件。例如，将基于模板的HTML页面原样部署在网站上。它们是部署工件，例如，可能需要在某些临时位置中将其与其他已构建工件一起显式复制以进行实际部署。但是将它们存储在工件存储库中可能没有多大意义，因为它们始终可以从源代码存储库中获取。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 10 '17 at 16:07
@Pierre确认哪个OS与工件正交，我不确定为什么应将其包含在答案中，许多其他方面也无关紧要。
–Rsf
17年3月11日在7:01
#4 楼
在文化方面的侧面说明。虽然在DevOps中，我们将“工件存储库”的概念视为特定情况，但似乎与组织过程没有太多联系。文化问题：如果组织使用ITIL，那么经过认证的人员会说：“我们需要拥有一个定义媒体库，这样的存储库才能放置我们生产的软件配置项目。”因此，关心结构良好的IT流程的人不知道哪些工具（支持非管理工具）支持并正在使用该工具。反之亦然，如果您需要Nexus或Artifactory语言的合理性，则根据组织的不同，可能很难解释它。
进一步阅读：
https：//en.wikipedia .org / wiki / Definitive_Media_Library
评论
你好欢迎来到该网站。请在答案中添加更多信息。在当前状态下，它仅是链接，并将被标记:)
– Dawny33♦
17年3月15日在19:36
如果DevOps也是关于文化的，那么我认为与ITIL的链接很重要，因为有时它会在较高的组织级别上统治IT组织。添加了更多解释以澄清这种无知的对称性。
– Peter Muryshkin
17年3月16日在16:58
我认为它并没有真正解决什么是人工制品的问题，但至少看起来这是一种诚实的尝试。
–滕西拜
17 Mar 16 '17在17:06
我同意@Tensibai（现在），并删除了我之前的评论（不再可疑）。尽管此答案中的所有内容都说得通，但我仍然不知道此“侧注”-答案是如何解决我的问题的，我也尝试在我的问题标题中进行总结，即“什么是人工制品（或人工制品） ）？”。我欢迎新尝试，好吗？
– Pierre.Vriens♦
17年3月16日在19:17
评论
我们的英语SE朋友对“工件”与“工件”发表了看法：english.stackexchange.com/questions/37903/…