I use SQL Server 2012 with Visual studio 2010 with Integration Services Catalog. I would like to know if it is possible to deploy my ssis 2012 project to only one of the three environments I have created.
I am trying to understand if this is possible or if environments are created only for different variable values (for different test scenarios etc).
So my question is if I can have deployment version 1 on my DEV environment and deployment version 2 on another environment.
Thank you
Sure it's possible. It's the opposite of what most people want, but you can create a DEV version of your package and only deploy it to your DEV environment, and then create a 2nd version of the package and only deploy it to your 2nd environment.
Note that I am talking about having two separate .dtsx packages, which will have to be maintained separately. That is what I think you are asking. If I have misunderstood, then your question wasn't clear.
Related
Working on a project to migrate SSIS 2008 projects to 2016 deployed to a File Server. Currently have the packages on the file server and prefer to keep it that way. I'm aware that the Project Deployment Model has been introduced since 2012.
Questions:
Can I change the migrated projects to Project Deployment Model and still deploy to the File System? Is changing to a Project Deployment Model a best practice?
Researching online, I can only find tutorials on how to deploy to SSISDB(Catalogue). Is the deployment to a File System still the same as previous versions ie. Build project > SSIS creates manfest file in project directory > open the manifest file to deploy?
Well, it is possible with certain limitations.
First, let's state that "deploying to File System" usually means that you store your package on a file system folder, and run it with dtexec. In that sense, deploy SSIS Project to File System is certainly possible, you can run any package from project file. For more details and examples - see MS Docs on dtexec.
However, this is not practical. By doing so, you loose a significant part of SSIS functionality introduced in 2012 version. For example, execution reports in SSIS Catalogue, and project environments which allow fine control and management of package parameters, including encryption of sensitive data like passwords. SSIS Catalogue keeps versions of deployed packages, so you can roll back to previous version easily.
Besides, SSIS Catalogue is fully supported in SSMS; on running package from project file - you are on your own to supply parameters; connection strings are usually passed from environments.
Yes, it's possible but not recommended (and not always possible). Package deployment model exists for backward compatibility. Once you convert your packages to Project Deployment Model you should deploy only to the SSISDB catalog on an instance of SQL Server.
Project Deployment Model contains packages, parameters, Connection managers and more very cool features introduced in 2012. This is the best option to work with SSIS these days.
https://learn.microsoft.com/en-us/sql/integration-services/packages/deploy-integration-services-ssis-projects-and-packages
I'm learning about the environments and machines of Octopus. I have a Web project that is packaged into a Nuget package and deployed to Azure Websites, and I also have a DB project that is packaged into a separate Nuget package to SQL Azure. When Octo picks them up and deploys, is it better to have two separate machines have tentacles for each in the same environment, or should they be on one machine (in the case that the website deployment passes and the DB doesn't)?
If you're deploying to Azure, it doesn't really matter - 1 tentacle is enough for ALL environments (regardless of project type). We do this all the time for our Azure projects. You can think of the tentacle being a PowerShell script runner against Azure; nothing really happens on the actual server itself.
You can have multiple Octopus "environments" using the same tentacle (especially for Azure) - as you can reuse the same tentacle. This will allow you to use different scopes for your variables to apply the appropriate values per each logical environment, all the while targeting just one server which does runs scripts against Azure.
I have completed my Project in VB.Net and has published my project.
But i want to come out of these things
I have Sql Server Database in my project and i want my setup to add that database to sql server on installing my project.
I want my application to automatically detect sql server 2008 r2 and if it is not instaled i want it to install for me and then atach the database.
I dont want to add the database as a Attached database in my project.
i dont want to install crystal report in my application.
I have some unused refernces in my application in my project which i want to removed, i have tried the default visual studio remove unused references but still have some references like shockwave.dll log2net.dll etc.
The first step would be to switch to an MSI-based installer. This should allow you to resolve issues 3 and 5 (you control what the MSI includes). You can use a Visual Studio setup project, WiX or a commercial setup authoring tool.
For installing your database (issue 1), the best approach depends on how you use your database. Some installers simply copy the database files, others install it using custom actions and others execute SQL scripts. You should first determine how you want to install it and then ask a more specific question if you encounter problems.
To install SQL Server when it's not found (issue 2), you can use a prerequisite. This is done differently for each setup tool, so you first need to decide on a tool and then research how it supports prerequisites.
For issue 4, I'm not sure I know what to say. An MSI package will install what you include in it. If you don't add Crystal Reports in your package, then it won't be installed.
Visit
http://www.codeproject.com/Articles/10032/Deploy-SQL-Server-databases-easily-with-an-Install
Deploy SQL Server databases easily with an Installer class
Best regards!
Elias Sant Anna
I've spent some time with new Database project in VS 2008 and decided to go with it (really cool). But i've also discovered that i cannot build it on our CI-server where .NET SDK only is installed. I tried to put Microsoft.VisualStudio.TeamSystem.Data.Tasks.targets to the CI-server but it has too many dependencies on assemblies such as Microsoft.VisualStudio.TeamSystem.Data.dll.
Am i right that in order to build it i need VS 2008 Team System installed (unacceptable for CI-server) or there is a simpler solution?
You always need to install on your build server the same software you use to build on a developer machine. In this case, you do need the Data Edition installed. In the same way, if you had web tests as part of your automated test suite, you would need the Test Edition installed.
Scenario:
Production servers are running SQL Server 2008 in the domain myDomain.com
Dev/test/stage servers are running SQL Server 2008 in the domain dev-myDomain.com
Actual dev work done on local running SQL Server 2008 source controlled using SourceSafe
First of all, does this setup/environment make sense? And, what are some good ways of deploying projects including SSAS, SSIS, SSRS from local to the dev servers and finally into live?
Is including the output (compiled) files in SourceSafe and deploying from there good practice? If it is any ideas?
Or, is going straight from Visual Studio without having the output in SoureSafe better?
Thanks.
We rely heavily on the use of variables for the items we want to change in differnt configurations and then config files (one each for Dev, QA, Staging, Prod). All SSIS packages and config files are in Source Save.
Visual Studio has configurations you can set up in order to deploy objects to different servers.
You can also use utilities to copy some around:
DTUTIL for SSIS - delivered with SSIS
RSScripter for SSRS - third party free tool, which is very useful
I would think you would use the deploy tool in Visual Studio for SSAS, as it needs to populate the model. I am just getting started with SSAS, so there may be other tools.