如何使多个 BizTalk 前端上部署的代码保持同步？
我们有多个 BizTalk 2006 应用程序服务器，我发现几乎不可能在它们上保持项目版本同步。部署 MSI 包、导入它们、匹配 GAC 中的文件、部署一些注册表更改是一个繁琐的过程，如果遗漏了一个步骤，或者有人将 DLL 的更新副本直接部署到一台服务器而不是另一台服务器，则不会有任何问题。简单的方法来告诉。
其他人如何确保两个服务器之间的软件副本是相同的版本？
一些背景：
我们的环境有两个（非集群）BizTalk 前端服务器和一个单独的数据库后端。直到最近，尽管我们配置了两个前端，但由于一些故障排除，第二台服务器上的主机实例已停止。它们已经被禁用几个月了，同时我们部署了一些更新的代码。
今天早上，我在 GAC 上进行了文件夹差异，以及保存我们部署的项目的 DLL 本地磁盘副本的文件夹（两台服务器上的 C:\OurProject\），并且所有内容都匹配 - 文件大小相同，相同时间戳。然而，一旦我打开第二组服务，很明显 Server2 使用的是旧版本的项目 DLL - 在接下来处理的三个文件中，两个有正常结果，一个显然已经过时。
请帮助我避免动脉瘤。
We have multiple BizTalk 2006 application servers, and I find it almost impossible to keep the versions of our projects in sync on them. It's a tedious process of deploying the MSI packages, importing them, matching up files in the GAC, deploying some registry changes, and if one step is missed or somebody deployed an updated copy of a DLL directly to one server and not another, there's no easy way to tell.
How do others ensure that copies of software between the two servers are the same version?
Some Background:
Our environment has two (non-clustered) BizTalk front end servers and a separate database back-end. Until recently, though we had both front-ends configured, the host instances were stopped on the second server because of some troubleshooting. They've been disabled for a few months, and we're deployed some updated code in the meantime.
This morning, I did a folder diff on the GAC, as well as the folder that holds the local disk copy of the DLLs for our deployed project (C:\OurProject\ on both servers), and everything matched - same file sizes, same timestamps. However, once I turned on the second set of services, it became obvious that Server2 was using an old version of the project DLL - of the next three files processed, two had normal results and one was clearly out of date.
Please help me avoid an aneurysm.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可能想要研究的一件事是 BizTalk 部署框架。
我们目前正在使用 BizTalk 2009 构建一个新环境，我从一组 MSBuild 脚本开始，这些脚本处理从 SubVersion 导出源、使用 BTSTask 构建和部署程序集。
当然，BTTSask 缺乏很多功能（启动/停止应用程序），但至少对于 BizTalk 2006 来说，有 BTSControl 。
One thing you may want to look into is the BizTalk Deployment Framework.
We are currently building up a new environment with BizTalk 2009 and I started out with a set of MSBuild scripts that handle exporting sources from SubVersion, building and deploying assemblies using BTSTask.
Of course BTSTask lacks a lot of functionality (start/stop applications) but at least for BizTalk 2006 there is BTSControl.
我们使用自动构建脚本，其最终结果是带有 Dev/Stage/Prod 绑定文件的 MSI。所有发布的绑定文件都存储在共享上，并用于手动加载 BizTalk 服务器。首先停止应用程序，在两台服务器上执行 MSI，然后导入 MSI。在导入过程中，我们指定绑定的环境，瞧。我们没有遇到过同步丢失的问题。
因此，我建议获取所有最新的 MSI，并在存在差异的服务器上重新执行它们。否则，只需尝试建立一个流程来手动创建可重复的加载流程。
We use an automated build script whose ultimate end is an MSI with binding files for Dev/Stage/Prod. All released binding files are stored on a share and used to load the BizTalk server by hand. First the App is stopped, MSI's executed on both servers and then MSI imported. During the import, we specify the environment for the bindings and voila. We've had no issues with loss of synch.
So, I'd suggest taking all of your latest MSIs and re-execute them on the servers where you have differences. Otherwise, just try to put a process in place to create a repeatable load process by hand.