处理术语发布与部署的模糊性

Question

DevOps术语有时起源于作者介绍的产品。

因此，有一些标准行动用模棱两可的术语来描述。在混合团队和大型异构环境中，我们需要商定条件来理解我们实际做的事情。

• 发布:特定于Ant/Ivy的术语，意思是将艺术品放入二进制存储库。另外，有些人会说“向网站发布内容更新”。
• 部署:虽然“在Maven世界”这个词描述了在二进制存储库afaik中放置一个伪物，但是更多的"opsy“用户也在没有Maven的情况下部署他们的服务器。

如何处理这种模棱两可(理想情况下，请参阅“成功的故事”)？在面向交付的有压力的环境中，探讨术语的意义并不总是受欢迎的；也许已经有更好的术语了？

有关术语定义，请参阅资料来源。

Answer 1

这些术语实际上都有很好的定义，有些作者只是在使用“发布”这样的术语来处理部署问题，比如在发布网站也构成了自己的部署过程的情况下，因为发布后没有额外的部署步骤。有时，它们使用word发布来上传和发布，因为它们的所有工件都是公共的。这造成了不必要的混乱。为了说明这一点，以下是定义：

环境定义：

• 生成环境-用于生成过程的环境设置。
• 运行时环境-用于执行过程的环境设置(测试/分期/生产)。

工件生命周期阶段：

• 在构建环境中创建工件的过程
• 将工件从构建环境上传到存储库。
• 发布-在存储库中公开制作工件。
• 下载-将工件从存储库移动到运行时环境
• 安装-将工件应用于运行时环境
• 部署-在运行时环境中使用工件
• 交付-可供客户使用的制作艺术品(效果)

注意:人们经常使用这些术语中的任何一个或多个在一起表示一个或多个以前的术语。

Answer 2

第一件事:让我们说清楚我们在说什么。我们专注于将工件存储在工件存储库中的操作。

我个人宁愿避免使用部署，因为：

• 发布意味着您使工件可供其他人使用。这个词似乎起作用了。当您将工件推到私有存储库时，它会减弱一些。然后，您将进行一次私人出版物。这是个小恶魔。它还是有意义的。
• 部署绝对不合适。在单个存储库中推送单个工件绝不是部署。部署意味着某种形式的传播，在多个环境或机器上分发工件。我们在这里处理的是部署的先决条件，而不是部署本身。

成功？

值得注意的是，上一次我面临将工件推送到工件存储库的任务命名时，我是在看板上下文中工作的。小组达成一致，决定把这项工作召集起来。

version

因为在合并请求之后构建的每个包都是潜在的发布候选程序，因此它是版本化的，然后被推送。

后思考

从今天起，我会用发表这个术语(可能是私下)来写一个更好的词。

但我还是觉得这不令人满意。请在下面的评论中留下你的想法！