SSIS 2012 Project Deployment version control for multiple environments

  • Question:

    How do we manage the different versions of the SSIS project codebase for the different environments in the IS Server Catalog?

    Question Example:

    SSIS project v1.4 is deployed to the IS Server Catalog and an Agent job executes that deployed package against Environment PROD. How can I deploy SSIS project v2.0 to the same IS Server so i can execute the project against TEST without overwriting v1.4?

    Context:

    The Project Deployment model in SSIS 2012 has been documented with many articles on the web. They often describe the use of Environments in the IS Server Catalog to configure the project and package parameters for executing a deployed SSIS package in different environments, typically DEV, TEST, PROD.

    This means the same deployed project packages can execute against a selected Environment. This is great and I understand this practice. My question is not related to how to configure the Environments, parameters, and executing the package against the selected Environment.

    Typically an application would have potentially different versions (codebases) of the same application in DEV, TEST, PROD depending on the position in the application delivery cycle. eg. Dev 3.0, Test 2.0, Prod 1.4

  • I'd like to know this as well...

  • Is it a possibility to deploy the project to different folders in the SSIS catalog?

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • That's basically the only solution. I did some more investigation, but it is not possible to assign a specific version to an environment. So the only solution is to create separate folders. But in my opinion that makes the environment functionality less interesting. Although I can understand the complexity of assigning a specific version to an environment...

  • arjan.hulshoff (2/4/2014)


    That's basically the only solution. I did some more investigation, but it is not possible to assign a specific version to an environment. So the only solution is to create separate folders. But in my opinion that makes the environment functionality less interesting. Although I can understand the complexity of assigning a specific version to an environment...

    It should be possible though. But it makes room for errors on the other hand. What if someone deploys a newer, more accurate version of a project, but they forgot to change the version in the SQL Agent job?

    It could make a nice feature and it could make the SSIS catalog environment more flexible. It also goes hand in hand with the SSIS development team's vision where you should branch projects in source control if you want multiple versions. If you can have multiple versions on the client side, why not on the server side?

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • Well, changing versions in your jobs is the least of your problems. That can be easily fixed. What is causing more problems is which parameters/variables have to be set in a specific version. This is something that can vary a lot between versions and is not so obvious to retrieve. The only solution that I can come up with is that during the deployment process these are registered and presented in the environment in a enabled/disabled manner.

    But I agree, it would be a great addition to the functionality of the environments. It would make SSIS very powerful in terms of rapid deployment of new versions.

    By the way, I think that for this you also need to store information about the version. Something like release notes. This way you can determine what the difference is between the versions and decide which version to use. Some versions are probably only suitable for development and not for production.

    Anyway, I would encourage Microsoft to implement something like this.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply