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

Question

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

我了解不让所有人登录到实时生产服务器的政策，但我希望能够在我的代码，数据库和文件生效后访问我的代码。

对其他人来说如何？

Answer 1

拥有配置管理组或开发组以外的其他人将代码部署到生产环境具有优势。其中大部分有助于强化版本的严格和审计跟踪。理想的配置管理团队应该通过脚本释放代码。该脚本从代码存储库中取出某个标记，并释放到某个服务器。这样做可以减少一路上的错误。

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

Answer 2

这一切都取决于公司有什么程序。有些比其他更灵活。我们的组织正在摆脱有权访问生产环境的开发人员。现在，所有事情都必须遵循QA过程，然后是操作（负责部署和维护代码）。我想你会以较少的事件结束，但是会延长bug修复时间。

Answer 3

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

你所有的代码都必须签入到vcs中，这是他们获得部署代码的地方。因此，只要代码生效，您就无法“访问”对代码进行更改。除非是紧急部署，否则他们每周部署两次新/更改的代码。

Answer 4

我今天刚刚部署了一些活动环境。我也可以访问实时数据库。

这已被认为会导致过去史诗般的失败。有时候，有人在生产环境而不是开发环境中放了一张表。但是，我发现另一个人在发布时没有什么优势，特别是当他不熟悉这个软件的时候。

Answer 5

理想的释放过程流程如下（在我的小世界）：

1. 发展信封，其中测试人员进行测试（你上的代码，并做你的测试）
2. 测试信封（实时数据 - 也可能是你）
3. 在这个阶段，它可以直接生活，或释放到另一个测试场，你可以让用户测试它。

取决于你的公司有多严格，开发者可能会或可能不能访问实时版本，特别是如果它是一家大公司。

Answer 6

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

其他人希望获得更严格的QA流程，以便创建一个运营部门来照顾部署，但我发现他们倾向于在公司中营造一种消极气氛：他们通过证明他们的角色而获得奖励，这需要指出支持世界上的坏事。如果开发者擅长工作，如果他们的薪酬与绩效有任何关系，怨恨就会蔓延开来。个人而言，我倾向于照顾整个堆栈，但越来越多地转向提供商，这让我越来越不用担心硬件（EC2，Heroku等），并更多地关注功能。应用。我个人喜欢拥有代码和错误，因为这意味着我明显有动机去保持错误票 - 每张开放票都是延迟我想要工作的新功能。

各自为妙。

Answer 7

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

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