...或者您是否必须通过其他人（管理服务器的人）来部署代码？
我理解不让所有人登录到实时生产服务器的政策，但我希望能够在我们的代码，数据库和文件生效后访问它们。
其他人怎么样？
答案 0 :(得分：1)
每个环境都略有不同。相比之下，你必须决定什么对你有用。例如亚马逊让他们的开发人员拥有他们自己的代码，而一些开发人员讨厌这些代码，但是这个环境的一个特性是让bug数量很少（你最后一次看到amazon.com上的bug是什么时候？）。
其他人想要更严格的质量保证流程，所以创建一个运营部门来照顾部署，但我发现他们倾向于在公司中创造一种消极的氛围：他们通过证明自己的角色来获得奖励，这需要指出和支持世界上的坏事。如果开发人员擅长工作，那么如果他们的工资与绩效有任何关系，那么怨恨就会蔓延。
就个人而言，我倾向于选择整个堆栈，但越来越多地转向允许我越来越担心硬件（EC2，Heroku等）的供应商，并更多地关注应用程序中的功能。我个人喜欢拥有代码和错误，因为这意味着我明显有动力保持错误票价 - 每张打开的票证都是我想要处理的新功能的延迟。
各自为自己。
答案 1 :(得分：0)
这完全取决于公司的程序。有些比其他更灵活。我们的组织正逐渐远离可以访问生产环境的开发人员。现在一切都必须遵循QA和操作（负责代码的部署和维护）的过程。我认为你最终会减少事件，但会有更长的错误修复时间。
答案 2 :(得分：0)
在我签约的最后一个地方，有一组特定人员负责生产服务器上的部署和配置。
您的所有代码都必须签入vcs，这是他们获得部署代码的地方。因此，一旦它生效，您就无法“访问”对代码进行更改。他们每周两次部署新的/更改的代码，除非是紧急部署。
答案 3 :(得分：0)
我今天刚刚在现场环境中部署了一些内容。我也可以访问实时数据库。
众所周知，这会导致一些史诗般的失败。有时有人会在生产环境而不是开发环境中放弃一个表。但是，我认为另一个人在发布时没有什么优势，特别是当他不熟悉软件时。
答案 4 :(得分：0)
理想的发布程序流程如下（在我的小世界中）：
根据您公司的严格程度，开发人员可能会或可能不会访问实时发布，特别是如果它是一家大公司。
答案 5 :(得分：0)
让配置管理组或开发组以外的其他人将代码部署到生产环境中具有优势。其中大部分都有助于强制执行发布的严格和审计跟踪。理想的配置管理团队应该通过脚本发布代码。该脚本从代码存储库中提取某个标记，并释放到某个服务器。这样做可以最大限度地减少错误。
我认为开发团队应该只具有生产数据的权限，并且能够查看任何日志文件。这样可以更轻松地调试问题。如果新版本的代码也需要数据库更新，那么配置管理团队当然也应该按脚本部署这些更改。
答案 6 :(得分：0)
回答上面提到的开发和测试环境。拥有不用于开发的专用独立构建服务器也非常重要。它从存储库中提取源代码，编译并创建分发（在Java world EAR或WAR文件中），然后将其部署到测试环境等。
此构建服务器还可以托管CI环境并执行定期自动日常构建。