您是否负责将代码部署到实时环境？答案

【问题标题】：Are you responsible for deploying your code to a live environment?您是否负责将代码部署到实时环境？
【发布时间】：2011-03-12 10:07:42
【问题描述】：

...或者您是否必须通过其他人（管理服务器的人）来部署您的代码？

我了解不允许所有人登录实时生产服务器的政策，但我希望能够在我的代码、数据库和文件上线后访问它们。

其他人怎么样？

【问题讨论】：

我替换的那个人曾经在直播环境上开发！
为了更具体地说明我问的原因，我有一个使用几个 xml 文件的网络应用程序。我宁愿在本地编辑它们并将它们上传到服务器，而不是通过应用程序对这些文件进行更改。他们不应该经常改变。与一些网站图像相同。它们不会经常更改，但我宁愿不让用户自己维护它们。
@Ed B. 现在我不会走那么远了！

【解决方案1】：

每个环境都略有不同。相比之下，你必须决定什么对你有用。例如，亚马逊让他们的开发人员拥有自己的代码，这让一些开发人员讨厌，但这是该环境的一个功能，可以保持低错误数量（您最后一次在 amazon.com 上看到错误是什么时候？）。

其他人想要更严格的 QA 流程，因此创建了一个运营部门来负责部署，但我发现他们倾向于在公司中营造一种消极的氛围：他们通过证明自己的角色得到回报，这需要指出和支持世界上的坏事。如果开发人员擅长他们的工作，那么如果他们的薪酬与绩效有任何关系，就会产生怨恨。

就个人而言，我更倾向于关注整个堆栈，但越来越多地转向让我对硬件（EC2、Heroku 等）的担忧越来越少的供应商，并更多地关注应用程序中的功能.我个人喜欢拥有代码和错误，因为这意味着我有明显的动力来降低错误票 - 每张打开的票都是对我想要开发的新功能的延迟。

各有所长。

【讨论】：

【解决方案2】：

拥有一个配置管理组或开发组以外的其他人将代码部署到生产环境具有其优势。其中大部分有助于执行严格的发布审计跟踪。理想的配置管理团队应该通过脚本发布代码。该脚本从代码库中提取某个标签，并发布到某个服务器。这样做可以最大程度地减少错误。

我认为开发团队应该对生产数据拥有只读权限，并且能够查看任何日志文件。这允许更容易地调试问题。如果新版本的代码也需要数据库更新，配置管理团队当然也应该通过脚本部署这些更改。

【讨论】：

【解决方案3】：

这完全取决于公司有什么程序。有些比其他的更灵活。我们的组织正在远离可以访问生产环境的开发人员。现在一切都必须遵循 QA 的过程，然后是操作（负责代码的部署和维护）。我认为您最终会遇到更少的事件，但修复错误的时间会更长。

【讨论】：

我认为您更有可能以相同数量的事件和更长的错误修复时间结束。
@Brian - 这可能会也可能不会发生。它仍然是新的，所以让我们给它一个怀疑的好处。这是今天的味道。
考虑到我一直犯的愚蠢错误的数量，我认为在决定某件事是个好主意和在现场网站上尝试之间存在一个小障碍是一件好事。但小可能是那里的关键词。
@Brian - 我同意你的看法。但是有些开发人员知道如何应用有效的更改，而有些则不知道。在一个大型组织中，我见过人们覆盖生产数据库，不仅一次，而且多次。希望这个新流程能够防止/减少此类事故发生的可能性。

【解决方案4】：

在我签约的最后一个地方，有一组特定的人员负责在生产服务器上进行部署和配置。

您的所有代码都必须签入到 vcs 中，这就是他们获得要部署的代码的地方。因此，一旦代码上线，您就没有“访问权限”来更改代码。他们每周部署两次新的/更改的代码，除非是紧急部署。

【讨论】：

【解决方案5】：

我今天刚刚在实时环境中部署了一些东西。我还可以访问实时数据库。

众所周知，这在过去会导致一些史诗般的失败。有时有人在生产环境而不是开发环境中放置了一张表。但是，我认为另一个人进行发布几乎没有优势，尤其是当他对软件不太熟悉时。

【讨论】：

【解决方案6】：

理想的发布流程如下（在我的小世界里）：

根据贵公司的严格程度，开发者可能会也可能不会访问实时版本，特别是如果它是一家大公司。

【讨论】：

我很相似。 - 我在自己的机器上开发。 - 部署到内部/Intranet 服务器并让测试人员试一试。 - 准备就绪后，它会被放入部署列表（最近的概念）并部署到现场。

【解决方案7】：

回答上面提到的开发和测试环境。拥有不用于开发的专用、单独的构建服务器也非常重要。它从存储库中提取源代码，编译并创建分发（在 Java 世界 EAR 或 WAR 文件中），然后部署到测试环境等。

此构建服务器还可以托管 CI 环境并执行定期自动每日构建。

【讨论】：