是否有最佳实践流程来更新生产中的xpages应用程序？ 目前（在对开发服务器进行测试之后）我会......
如果我遵循该流程，生成系统将在使用＆＃34; HTTP Web服务器：命令未处理异常错误进行复制响应后停机约20分钟。＆＃34;它最终会自行回归，反映出新的变化。
所以问题是：
如果没有，任何想法服务器可以为这20分钟做些什么？没有应用程序范围bean重新初始化，只有sessionScope。在日志中有很多这些错误...
2014年5月13日下午3:55：异常抛出 显示java.lang.NullPointerException 在com.ibm.xsp.webapp.FacesServletEx.service（FacesServletEx.java:88） 在com.ibm.xsp.webapp.DesignerFacesServlet.service（DesignerFacesServlet.java:103） 在com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet（ComponentModule.java:576） 在com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet（NSFComponentModule.java:1335） 在com.ibm.designer.runtime.domino.adapter.ComponentModule $ AdapterInvoker.invokeServlet（ComponentModule.java:853） 在com.ibm.designer.runtime.domino.adapter.ComponentModule $ ServletInvoker.doService（ComponentModule.java:796） 在com.ibm.designer.runtime.domino.adapter.ComponentModule.doService（ComponentModule.java:565） 在com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService（NSFComponentModule.java:1319） 在com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal（NSFService.java:662） 在com.ibm.domino.xsp.module.nsf.NSFService.doService（NSFService.java:482） 在com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService（LCDEnvironment.java:350） 在com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service（LCDEnvironment.java:306） 在com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service（XspCmdManager.java:272）
答案 0 :(得分：1)
以下是我的想法。 我永远不会在开发和生产之间进行任何复制。这在我看来风险太大而不是最佳实践。也许这不是你正在做的事我不确定。
以下是我的工作，据我所知，我的团队中的每个人都是：
我们的Dev服务器有一个测试数据库。这是生产中的COPY。我个人不时刷新它，所以它基本上是一个快照。
我们有一个适用于所有开发工作的本地模板。我们在模板中编程并刷新测试数据库。通常我们不需要做重启任务http＆＃34;作为刷新过程的一部分，除非我们对托管bean进行更改或正在使用SXD。然后是的，我们刷新开发应用程序并重启服务器并进行测试。
在OLD时代，我会在生产服务器上拥有一个生产模板。这不是任何东西的复制品，但它继承了DEV模板的设计。因此，为了促进对生产的更新，我首先从开发版本中刷新生产模板。然后从生产模板中刷新生产应用程序。
在源代码控制领域和拥有功能分支的SourceTree中，开发分支和默认/生产分支，这样就无需生产模板。我并不喜欢它，但它就是它的本质。因此，我们从本地模板刷新生产，并依靠SourceTree确保它在我们刷新时是正确的分支。我认为它风险更大，但这样可以实现真正的修补程序和内容。
从历史上看，我不需要执行重启任务http，但我没有推广任何使用SXD的东西，甚至我的托管bean促销也仅限于此。但我想我需要重新启动http任务。
答案 1 :(得分：1)
在我的正常使用中，我在生产服务器上使用替换设计路线。这仍然需要一些停机时间，可以根据设计的大小和与服务器的连接速度进行扩展，但这并不算太糟糕。如果您将设计替换为在服务器上运行的客户端，那么可以缩短这一点。
我还没有这样做，但我的猜测是，绝对最少的停机时间是让生产数据库跟随服务器上的命名NTF。在NTF上替换设计，然后运行＆＃34; load design -f proddb.nsf＆＃34;在服务器上 - 我认为这将是设计元素的最快方式。
至于等待半小时＆＃34;问题，我不确定原因是什么。我在本周运行8.5.2的客户端服务器上看到了类似的东西，但延迟时间大约为一分钟。我的服务器上没有看到类似的东西。一个不太明显的猜测：也许它与设计变更的刷新应用程序相关＆＃34;属性添加到8.5.3中的xsp.properties（我之后使用过）。这可以解释＆＃34;在半小时内修复自己＆＃34;事情：应用程序可以在该时间段内自动卸载，而打开该选项会导致它立即执行此操作。