SSIS 配置选项其中 test &生产在同一台服务器上
我是 SSIS 新手，我的项目仍处于早期阶段，只有 dev 和 dev 。不同服务器上的测试环境。生产环境将与测试位于同一服务器上（我对此没有发言权！）。我有许多包，每个包都有一个 SQL 代理作业来安排它们，我需要一种方法来处理开发、测试和开发的包配置。生产。
我知道我可以将包的 2 个版本存储在同一服务器上 MSDB 内的不同目录中，但是实现测试和测试的最佳方法是什么？在同一台服务器上进行生产，部署到生产的手动工作量最少？
我可以将包部署到 MSDB 中的 2 个不同位置，并为每个包创建一个作业（1 个用于测试，1 个用于生产），但是如何设置包配置，以便包本身不需要在环境之间进行更改？
I'm new to SSIS, my project is still in the early stages, with only dev & test environments on separate servers. The production environment will be on the same server as test (I don't have a say in that!). I have a number of packages that each have an SQL Agent job to schedule them and I need a way to handle package configurations for dev, test & production.
I know I can store 2 versions of the packages in different directories within MSDB on the same server but what is the best way to implement test & production on the same server with the least amount of manual work to deploy to production?
I could deploy the packages to 2 different locations in MSDB and create a job for each package (1 for test, 1 for prod) but how do I set up package configuration so the package itself doesn't need to change between environments?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您有多种选择：
按照此处所述创建包配置表，以及此处。如果您在同一服务器上运行这些包，这可能会很有效。
覆盖 SQL Server 代理作业中的连接设置。这可能工作得很好，但如果每个作业都必须覆盖连接设置，则管理可能会很困难。
使用包配置 XML 文件并通过 DTEXEC 通过代理运行您的包。如果这些包位于同一服务器上，这对我来说似乎有点过分了。
使用包中的变量来检查它正在运行的存储以确定要使用的数据库。这是我没有测试过的理论。如果我是正确的，这种方法的优点是您不需要在包之外设置任何内容。缺点是它可能很难或不可能实现，特别是当您必须考虑在测试期间包如何在 BIDS 中本地运行时。
You have several options:
Create a package configuration table as described here and here. This could work well if you are running the packages on the same server.
Override the connection settings in the SQL Server Agent Job. This could work well enough, but it can be difficult to manage if every job has to override connection settings.
Use the package configuration XML file and run your packages through the agent via DTEXEC. This seems like overkill to me if the packages are on the same server.
Use a variable in the package that inspects the store it is running under to determine which database to use. This is a theory that I haven't tested. If I am correct, the advantage of this approach is that you don't need to setup anything outside of the package. The downside is that it may be difficult or impossible to implement, particularly when you have to consider how the package will run locally in BIDS during testing.