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