The experience from the development side doesn’t change and if you’re wondering about version control, this does not have to change; it’s the same development paradigm that you’re used to. The only real difference is where we deploy to – more on that in a bit.
Something else to understand about the development experience is that there is no separate version of SSIS required. If you’re building in more recent versions of SQL Server data tools within Visual Studio, you can choose to build your package in SSIS 2012, 2014 or 2017; you choose this setting at the project level.
With SSIS and Azure Data Factory, any of those versions will work. When deploying your project or packages out to the SSIS runtime in ADF, part of that deployment process is an upgrade or migration to the current version of SSIS (currently 2017). You don’t have to change your version in Visual Studio when developing, this happens automatically for you.
As I mentioned, the biggest difference is deployment. When you choose to deploy to an SSIS catalog hosted in Azure, you’ll be prompted for an authentication method. So, if you’re deploying on prem or using an older version of SQL Server data tools, we had no choice but to use Windows authentication.
But with the new tooling with Visual Studio, you now have a choice of what kind of authentication you want to use when you’re deploying your package out to the SSIS catalog in Azure.
There are many changes in the platform, but the good news is on the development and deployment side, the experience of SSIS in the cloud has not changed a whole lot. If you want more information about SSIS in the cloud or Azure Data Factory itself, we are your best resource. Click the link below or contact us—we’re here to help.