您负责将代码部署到实际环境中吗？
...或者您是否必须通过其他人（管理服务器的人）来部署您的代码？
我了解不让每个人登录实时生产服务器的政策，但我希望能够在代码、数据库和文件上线后访问它们。
其他人怎么样？
...or do you have to go through someone else (a person who manages the servers) to get your code deployed?
I understand the policy of not letting everyone log onto a live production server but I would like the ability to have access to my code, database and files once they are live.
How is it for everyone else?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
每个环境都略有不同。相比之下，你必须决定什么对你有用。例如，亚马逊让他们的开发人员拥有自己的代码，这是一些开发人员讨厌的，但它是该环境的一个功能，可以保持错误数量较低（您最后一次在 amazon.com 上看到错误是什么时候？）。
其他人想要更严格的质量保证流程，因此创建一个运营部门来负责部署，但我发现他们往往会在公司中营造一种消极的氛围：他们通过证明自己的角色合理性来获得奖励，这需要指出并支持不好的事情在世界上。如果开发人员擅长他们的工作，如果他们的薪酬与绩效有任何关系，怨恨可能会蔓延。
就我个人而言，我倾向于照顾整个堆栈，但越来越多地转向那些让我越来越不用担心硬件（EC2、Heroku 等）并更多地关注应用程序功能的提供商。我个人喜欢拥有代码和错误，因为这意味着我明显有动力减少错误票 - 每一张开放票都会延迟我想要开发的新功能。
每个人都有自己的。
Every environment is slightly different. In comparison, you have to decide what works for you. Amazon for example makes their developers own their own code, which some developers hate, but it is a feature of that environment that keeps bug counts low (when was the last time you saw a bug on amazon.com?).
Others want a tighter QA process so create an operations department to look after deploys, but I've found they tend to create an atmosphere of negativity in the company: they are rewarded by justifying their role, which entails pointing out and supporting the bad things in the World. If the devs are good at their job, resentment can creep in if their pay is in any way performance-related.
Personally, I tend to prefer to look after the whole stack, but increasingly am moving to providers that allow me to worry less and less about hardware (EC2, Heroku, etc.), and to focus more on functionality in the apps. I personally like owning the code and the bugs, as it means I am demonstrably motivated to keeping bug tickets down - every open ticket is a delay to the new functionality I want to work on.
Each to their own.
让配置管理组或开发组以外的其他人将代码部署到生产环境有其优势。其中大部分有助于加强发布的严格性和审计跟踪。理想情况下，配置管理团队应该通过脚本发布代码。该脚本从代码存储库中提取某个标签，并发布到某个服务器。这样做可以最大限度地减少过程中的错误。
我认为开发团队应该对生产数据拥有只读权限，并且能够查看任何日志文件。这可以更轻松地调试问题。如果新版本的代码还需要数据库更新，那么配置管理团队当然也应该通过脚本来部署这些更改。
Having a configuration management group, or someone other than the development group deploy code to the production environment have it's advantages. Most of which help enforce a rigor and audit trail of releases. Ideal the configuration management team should release code by scripting. The script pulls from the code repository for a certain tag, and releases to a certain server. Doing so minimizes mistakes along the way.
I think the development team should have read only rights to production data, and ability to see any log files. This allows for easier debugging of problems. If a new version of code also requires database updates, the configuration management team should also be deploying those changes, by script of course.
这完全取决于公司制定的程序。有些比其他更灵活。我们的组织正在放弃有权访问生产环境的开发人员。现在一切都必须遵循 QA 流程，然后是运营流程（负责代码的部署和维护）。我认为最终事件会减少，但错误修复时间会更长。
It all depends on what procedures the company has in place. Some are more flexible than others. Our organization is moving away from developers having access to the production environment. Now everything has to follow the process of QA and then operations (who take care of the deployment and maintenance of the code). I think you'll end up with less incidents, but a longer bug fix time.
在我签约的最后一个地方，有一组特定的人员负责生产服务器上的部署和配置。
您的所有代码都必须签入 vcs，这是他们获取要部署的代码的地方。因此，一旦代码上线，您就没有“访问权限”来对其进行更改。除非是紧急部署，否则他们每周部署两次新的/更改的代码。
At the last place I contracted for, there is a specific group of people responsible for deployment and configuration on the production servers.
All your code had to be checked in to the vcs and this is where they got the code to deploy. So you don't have "access" to make changes to the code once it goes live. They deployed new/changed code twice a week unless it was an emergency deployment.
我今天刚刚将一些东西部署到实际环境中。我还可以访问实时数据库。
众所周知，这在过去会导致一些史诗般的失败。有时有人在生产环境而不是开发环境中删除了一个表。然而，我认为由另一个人进行发布没有什么优势，特别是当他不太熟悉该软件时。
I just deployed something to a live environment today. I also have access to the live database.
This has been known to cause some epic failures in the past. Sometimes somebody dropped a table on the production environment instead of a development environment. However, I see little advantage in another person doing the releasing, especially when he is not that acquainted with the software.
理想的发布流程如下（在我的小世界中）：
根据您公司的严格程度，开发人员可能有权也可能无法访问实时版本，特别是如果它是一家大公司。
The ideal release procedure flow is as follows (in my little world):
Depending on how strict your company is, the developer may or may not have access to the live release, especially if it's a big company.
回答上面提到的开发和测试环境。拥有不用于开发的专用、独立的构建服务器也非常重要。它从存储库中提取源代码，编译并创建分发（在 Java 世界中的 EAR 或 WAR 文件中），然后将其部署到测试环境等。
该构建服务器还可以托管 CI 环境并执行定期的自动化日常构建。
Answers above mentioned development and testing environment. It is also quite important to have dedicated, separate build server that is not used for development. It pulls source code from repository, compiles and creates distribution (in Java world EAR or WAR file) that is then deployed to testing environment etc.
This build server can also host CI environment and perform regular automated daily builds.