In the typical package development cycle, you build packages on one machine, the development machine. After you get all the settings right and the package is performing to your requirements, you move it to a test machine. After testing is complete, you move the package to the production machine. Although the stages and names might differ, most environments have similar testing and deployment requirements that seem at odds with the very nature of packages. Packages are by necessity tightly bound to the environment in which they run. They reference folders and files on certain drives by name, connect to specific servers by name, and perform other environmentally dependent functions. This is what is called the location-dependent problem. Although it's fairly easy to create a simple package that accomplishes substantial work, it can be a challenge to write the package in such a way that when you deploy it to another machine or when the environment in which the package runs changes, the package will continue to execute without modification or errors. This is one of the most common challenges Integration Services users face and is the primary reason Microsoft created the Integration Services configuration and deployment tools. Although the tools are helpful in addressing these issues, they're only part of the solution. The other part is the practices you use when building packages. This chapter explains both the tools and the approaches to building packages that address the location dependent package problem so that moving packages from the development environment through your testing processes and onto the production server will be as painless as possible. |