我帮助在澳大利亚的一个大型游戏网站。 我们从当地时间上午7点到第二天凌晨1点，每周的每一天都进行比赛。 自该网站发布以来，我们一天都没有跳过。 当然，这使得维护非常困难，我们发现我们的临时服务器在我们的生产分支之前多达50次提交。 通常情况下，主开发人员必须非常早地合并分支机构，确保一切正常。
我们一直在试图使我们的中转站点与我们能够到达的生产站点类似，但是我们只能使其类似。
我们的网站是基于Laravel实时Node.JS服务器。 我们正在使用Laravel Forge。
有没有人有任何build议，我们如何推动更新更频繁？ 我们对任何事情都开放。
有很多事情可以做，以改善您的部署过程。 其中一些是：
确保你的代码已经过很好的testing
理想情况下，您应该有100％的unit testing覆盖率，以及对每个可能的情况进行集成testing。
如果你没有这个，你应该放弃一切，并得到这个照顾。
研究行为驱动的发展。
有一个完整的testing套件将允许您…
运行持续集成。
每当有人提交更改，CI就会自动运行testing套件。 如果testing套件通过，则可以立即进行部署（或者安排部署）。 对于不需要对数据库进行任何重大更改的更改，仅凭这一项就可以为您节省大量时间和头痛。
如果出现问题，CI还可以给你一个单击回滚。
如果你的testing套件不完整和正确，那么CI是非常有用的，因为整个前提是能够以自动方式validation你的代码。
进行primefaces更新。
理想情况下，您不应该在生产服务器上复制旧文件。 相反，使用capistrano这样的工具将每个文件复制到新的位置，然后使用符号链接指向所需的部署。 回滚是瞬间的，因为它涉及到简单地改变符号链接指向以前的部署。 （虽然这不一定涵盖您的数据库迁移。）
还要看看Docker等容器是否可以帮助您。
进行更小，更频繁的更改。
无论你有testing，CI还是没有，只有这一点可以显着帮助你。 每个变化都应该有自己的git分支，部署应该尽可能less的变化。 由于更改较小，因此在部署期间可能会出错。
在这个笔记上，尽可能地让变化更加孤立。 如果你已经改变了奥马哈游戏，并且不影响德州扑克，5卡牌或其他任何东西，那么这是唯一需要暂停维护的游戏。
分析任何长时间运行。
您提到了部署的一些部分需要很长时间。 这可能是数据库模式更改。 有一个DBA看看你的数据库，以及每个模式的变化，看看有什么更好的performance是非常值得的。
让主题专家查看占用大量时间的部署的任何其他部分。
几个小时工作。
你可能已经在做这个了，但是它提到了。 不应期望开发人员（和系统pipe理员）能够“9到5”地工作，特别是对于全天候的操作。 如果有人需要花费整夜的时间来保留部署，修复任何问题，然后保持白天的时间表，那么你的期望是不现实的，并且你正在设置这个人的倦怠。
从你说的话看来，你每天从凌晨1点到早上7点有一个维修时间，问题不是时间，而是方便。 这是正常的，很多人只是把它作为业务的一部分来处理。
你可以有一个2（或更多的后端）系统，前端将stream量引导至当前正在运行的任何一个。 一旦你感到高兴的是一个发行版将会起作用，你可以告诉前端切换到新的系统。 这应该是一个简短的脚本需要很短的时间。
现在，您可以select退出旧系统，以便退出或使其保持最新状态，以便可以将其用作实时系统的备用，直到构build/testing下一个更新为止。
修改其他答案：您应该遵循蓝绿色的部署模型 。 当你想发布一个新版本的时候，你需要把它部署到一个内部的分段网站上。 然后，您可以在下一个版本的生产站点上运行自动化testing。 当testing通过时，您指向负载均衡器以使用新网站。
这有助于以下方面：
当你和其他人提到的所有其他问题，你可以在任何时候以无压力的方式进行部署，就不那么严重了。 蓝绿色部署模式是部署问题的完整解决scheme。
如果您的主数据中心出现故障，您会怎么做？ 您可能会接受停机时间，您可能会故障切换到另一个数据中心，您可能一直在多个数据中心中以主动 – 主动模式运行，也可能有其他计划。 无论是哪个版本，都可以在发布时执行，然后在发布期间将主数据中心closures。 如果您准备在数据中心停机的时候发生停机，那么您已经准备好了停机时间，所以在发布期间这不应该成为问题。
要添加到以前的答案：
使用允许回滚和即时切换的部署策略，Capistrano或几乎任何其他部署系统都可以帮助解决这个问题。 您可以使用数据库快照和代码符号链接等function，以便能够快速恢复到以前的状态。
使用完整的configurationpipe理，不要留下任何手动pipe理。 SaltStack，Ansible和Puppet等系统就是例子。 它们也可以应用于Docker容器configuration和stream浪箱。
使用HA确保在升级节点时切换请求。 如果升级失败，只需简单地closures节点，并在回滚时将其恢复，HA解决scheme将会注意到并再次向所述节点推送请求。 HAProxy就是一个例子，但是nginx也可以正常工作。
确保应用程序可以处理并发实例，将中央版本化数据存储库用于需要存储在磁盘上的非代码数据（如caching）。 这样，您将永远不会将已升级的应用程序运行到不同版本的caching文件中。 这将在清除caching和做caching热身之上完成。 （caching的东西只是一个例子）
我通常设置工作stream程，团队经理可以批准合并请求到一个特殊的分支，完成所有正常的CI工作，但是最后一步也是开始推送到生产节点。 你基本上做的是手动CI部署到生产实例。 如果该实例不会生成无效响应，中断或对您的数据产生奇怪的影响，则可以使用您的CI解决scheme大规模升级所有节点。 这样，如果一个部署工作，你知道所有的部署将工作的特定标签/提交。
现在，听起来好像您正在单个节点上运行生产应用程序，只有一个部署stream程，一个来源和一个目标。 这实际上意味着工作stream程中的每一步都是一个本身可以破坏网站的故障点。 确保这样的事情不可能发生是所有CI，HA和故障转移过程的基础。 不要只运行一个节点，不要只运行一个HA进程，不要只运行一个IP地址，不要只运行一个CDN等。这可能听起来很昂贵，但是重复你已经拥有的在具有自己的连接的服务器上的机架中，通常在商业站点上的停机时间不到一个小时。
我全世界都同意Michael的观点（ https://serverfault.com/a/739449/309477 ）。
在我看来，你应该做的第一个改进就是使用部署工具（Capistrano）。
它可以让你和平部署，然后立即切换到新版本。 如果出现任何问题，您可以立即切换回工作版本，只需将当前符号链接更改为正常工作版本即可。
和Capistrano相当快，首先处理（相比之下，开始使用testing和CI将是一个更大的时间投资）。
其次，如果钱不是你的主要问题，你应该有一个iso-prod开发服务器来testing你的应用程序，然后部署在生产环境中。 使用工业解决scheme（Ansible，Chef，Puppet）来pipe理VPS实例。