How using SSDT can I set up different database configurations for the different configurations specified in my solution (e.g. DEBUG, RELEASE etc)?
In the VS2010 database project I used to be able to set up different connection strings, SQL command variables and deployment configurations dependant on which configuration I had selected. I was then able to right click on my solution and click "Deploy" which would deploy all of the databases in my solution to their target actual database services.
This was very useful during development when in DEBUG configuration I would tend to set the options to...
Deploy to localhost\instancename
Drop the current database(s) and re-create
.. and then in release mode I could create an upgrade script to run on a test database before go live.
As I have multiple databases in my project the ability to deploy all of them in one go was very useful, however these options seem to have been replaced in SSDT with a publish option where I don't seem to get settings per configuration mode or the ability to deploy everything at once. Additionally, there seems to be no way to specify SQL command variables per configuration.
Has anyone else experienced this and found a solution or work around?
Thanks.
An workaround would be to create different publish profiles - from Publish window, after configuring the target database etc., "Save Profile As" [database name].debug.publish.xml, [database name].test.publish.xml...
If you want to deploy all databases at once, use a batch script to deploy.
Let's say, for the test environment the command for each database would be:
"C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\sqlpackage.exe" /Action:Publish /SourceFile<path>\<database name>.dacpac /Profile<path>\<database name>.test.publish.xml
Related
We have a C# .NET project using Visual Studio 2013 and we're setting it up to release and deploy with Visual Studio Team Services (VSTS). The websites were pretty simple and easy to set up and they work fine. A few projects are libraries or Console applications and we're trying to determine the best method for creating an automated release for these.
The publish profile asks for a location to publish to - we've experimented with the build drop on our VSTS build server (where all of the other files are) and then asks for a website, a UNC path or a CDROM. We chose "UNC Path" and put the same build drop location in, but in UNC format.
It hasn't really worked yet, so I thought I would see if any best practices for creating VSTS releases and deploys for Console or Code Libraries exist.
Thank you!
Have you considered installing the agent on the target environments and using a release definition that simply copies the right files at the right place?
Regards
Note: copy path shouldn't be hardcoded and rely on variables.
To specify the agent queue by going to the tasks tab when editing the release definition. Click on the "run on agent" header, that will open the details, select your queue here.
Agent queues can contain multiple agents, so your job when you add agents is to organize them by queues that make sense in your context.
I am building my solution in Visual Studio Online Build, the default 'steps' are build/test/index+publish/publish build artifacts. I want the build to be placed in a folder in my source control (rootfolder/builds). However, I don't see an option to enter an output-path anywhere.
EDIT: I see that next to 'timeline' on the build screen there is the option to view the 'Artifacts', but, I want to see/copy the drop to my TFS online project folder like '$myproject/mybranch/builds/'
The option to store the build drop on the TFS server is no longer supported. It was introduced as a temporary measure in 2012 and replaced with server drops in 2013.
Server drops are stored in an unversioned store in TFS/VSO and does not incur the overhead of versioning.
In TFS 2015 this transitioned to the new Artifacts repository. All build output is stored on the server and is accessible in the web, and through an API.
The way things stand right now, this is not possible. You have two options to drop your build outputs
Team Foundation Server
UNC file share if you use a on-prem agent.
See the Artifact Type argument on Publish build artifacts.
I it is possible with a custom powershell task. I have recently created a powershell build task that could "check-in" your drop artifacts into a folder like $myproject/mybranch/builds.
Have a look : https://github.com/skuvnar/visual-studio-team-services-scripts.
Although its possible, I would suggest against it - could lead to all sorts of trouble with the builds.
Having created a SQL Server maintenance plan in a SQL Server 2008 R2 instance, how can I import the definitions into a Visual Studio 2013 SSDT database project?
I don't mind using pre- and post-deployment scripts if that helps but I want it to be in a database project and to be able to build the project in VS and then to be able to deploy either a new instance of the plan, or to be able to synchronize an existing plan instance with the definitions in the database project. Also, drop and re-create is entirely acceptable.
Does anyone else already know how to do that ?
First of all maintenance plans are not supported by SSDT.
You can export it manually as an xml template file and then try to write some sql/batch post deploy scripts to deploy it.
You can find general instruction here (read comments also): https://robertbigec.wordpress.com/2013/10/03/automating-deployment-of-sql-server-maintenance-plans/
One note: The exported xml template contains some specific values such as server name or path to backup/log file locations. You might want to write custom script to get these values from target machine and replace it in the xml file.
I have a database project in Visual Studio 2012. When selecting "Deploy MyDBProj" on the Build menu nothing happens.
When I hit F5 to debug however, the database project is deployed, using the settings in the debug section of the database project properties. This is enabled in by checking the "deploy" checkbox in the solution's configuration manager.
I would like to be able to do a deploy, without starting a debug session. How do I do that?
Note: This is not publishing, which is something else. I want to know how to manually initiate the deploy that is part of the build process. Since the deploy is already done automatically it should be possible to initiate it manually too.
I got an answer from Microsoft at MS Connect:
There was a bug in the version of SSDT that shipped in Visual Studio
2012 in wuich the Deploy menu command appears but is a no-op. This has
since been fixed and is available in the latest version of SSDT:
http://msdn.microsoft.com/en-us/data/hh297027
The only way I can think of doing it (though I haven't tested it) would be to use the command line to do it as outlined at http://msdn.microsoft.com/en-us/library/dd193258(v=vs.100).aspx.
Though once you have your manifest, you can run:
VSDBCMD /a:Deploy /dd:+ /manifest:manifestFileName.dbmanifest
from a command line to deploy your database.
The manifest will contain your target database name, connection string, and so on but you can also specify those as part of the command line instead.
Can anyone shed some light on how to get Team Build 2010 beta 2 to push a SQL database project to the SQL server?
In VSTS 2008 you'd just add MSBuild commands with the targets attribute set to "deploy" in the TFSBuild.proj file, but I'm having a little trouble translating that to the new workflow based xaml thing that 2010 uses.
What I'm looking for is how to trigger the actual deployment of the databases themselves. It is already generating the deployment scripts just fine.
For anyone still looking for the answer, use an Invoke Process that uses vsdbcmd.exe:
http://msdn.microsoft.com/en-us/library/ff805001.aspx
Here is an example:
http://www.nablasoft.com/alkampfer/index.php/2009/10/06/deploy-a-database-project-with-tfs-build/
It may be that you are simply missing the DeployToDatabase=true
There is another solution to this problem if you don't need incremental database upgrade. So if recreating the database for each build is ok with you the following would also work.
Add a deploy target to Database Project file
Configure the deployment settings for ‘My project settings’. Those settings will then be used by the build server when building the solution. When building locally, the settings used will be the ones from ‘My isolated development environment’.
In the database project properties
Deploy Action needs to be ‘Create a deployment script (.sql) and deploy the database’; this will prevent the execution of the script, it will only create it.
Database project file
Modify the database project file (right-click database project, select Unload, right-click again, select Edit [ProjectName].dbproj)
from
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
To
<Project DefaultTargets="Build;Deploy" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
When the Build server builds the solution containing the database project, adding the default targets will also deploy the database. This build will use the Deploy settings selected for ‘My project settings’.
Pros
Easy to set up
Cons
Because the default target is changed to Build and Deploy, when a developer do a local Rebuild of the solution, it will also deploy the database (building only won't trigger the deployment)
The closest thing I've found so far is this post from Jim Lamb (the Team Foundation PM at Microsoft).
Here he talks vaguely about creating a custom proj file and modifying the default build process template to invoke the proj file.
He also talks about using the upgrade template, which I'd previously ignored. Apparently the upgrade template can be used to invoke a 2008 build definition. I'd rather not invoke and define the entire build based on the legacy proj file though, but at least it is an option.
Neither topic contains sufficient information for me to actually make the modifications necessary, but it does give me a reasonable starting point for some future experimentation.