I am trying to add some stored procedures to a build process in visual studio (using MSBuild) with a database project (*.dbp).
However unlike some of the other database projects available in VS, it cannot be built or run. ( I believe this is the project file i want as I am using SQL2000)
How can I get the SQL scripts to run as I build the project?
I know that I can run the scripts by right clicking and pressing run....but that is not the question.
Database projects are not built like normal projects. If you want to execute scripts inside this project, my advice would be to extend the associated project(s) which are MSBuild compatible (csproj, vbproj, etc.) and reference/execute your scripts from there using your tool of choice.
How you implement it is up to you, for example, you could hook into BeforeBuild target and execute scripts using SqlExecute task.
FWIW, we have to support SQL Server 2000, 2005, 2008+, so the task becomes much harder; think NVarchar(max) (2005+) vs NText (2000+) plus all the sp renames, etc between versions. We also wanted a single script which developers, QA and installer used to ensure consistency. So our approach was a custom tool which allowed token/keyword replacements inside scripts, which provides flexibility between different SQL Server versions and customers installations (e.g. user/login details, db names), as well as integration into various technologies so scripts can run from command line, MSBuild, MSI custom action using Wix projects, or whatever we need them to run from.
Database projects can be Built.
They cannot be run - they can be Deployed.
When you deploy, the project builds and then deploys. The code will be deployed along with the Pre-Build and Post-Build scripts and the Pre-Deployment and Post-Deployment scripts.
So if you want scripts to run as you BUILD the project, you want to look into the Pre-Build and Post-Build under Build Events in the Project properties.
Related
I'm trying to build a CI/CD for my Microsoft SQL Server database projects. It will work with Microsoft DevOps pipelines.
I have all databases in Visual Studio databases projects with the GIT as source control. My objective is to have something that I can release databases with the use of DevOps pipelines to the diferents enviroments:
DEV
UAT
PROD
I was thinking of using DBGhost: http://www.innovartis.co.uk/ but I can't find updated information about this tool (only very old info) and there is very little information about it on the internet and how to use it (is it still in use?).
I would like to use a mix of DBGhost and DevOps. DBGhost to Source Scripting, Building, Comparing, Synchronizing, Creating Delta Scripts, Upgrading and DevOps to make releases (that would call the builds created by DBGhost)
If you have any ideas using this or other methods I am grateful because currently all releases are manual and it is not very advisable to do.
We have this configured in our environment using just DevOps. Our database is in a Visual Studio database project. The MSBuild task builds the project and generates a DACPAC file as an artifact, and the Release uses the "SQL Server Database Deploy" task to deploy this to the database. The deploy task needs to use an account with enough privileges to create the database, logins, etc., but takes care of performing the schema compare, generating the delta scripts, and executing them. If your deploy is going to make changes that could result in data loss such as removing columns, you will need to include the additional argument /p:BlockOnPossibleDataLoss=false in the deploy task. This flag is not recommended unless you know there will be changes that will cause data loss; without the flag any deploy which would result in data lost will fail.
I am currently working on a continuous integration project to auto build and deploy database changes to target environment.
We are using Perforce P4 for source code repository, Nexus for artefacts repository and MS SQL 2008.
We are not using Redgate for the database repository.
Check-in process
- Developers manually extract database objects (e.g. table, stored proc, function) using Management Studio and check-in to the source repository of Perforce.
Requirement:
As part of the CI process, when developers check-in their code to the source repository, the build process should get triggered and create artefacts of checked-in code and get copied to the artefacts repository.
The deployment process should get automatically triggered when it finds any new artefacts and deploy the artefact to the target environment.
I would highly appreciate if someone helps me to know :
build and deployment steps
requirement of manifest file
if it is possible to extract incremental changes
Get ssdt in visual studio (express works if you don't have licenses)
This will mean your developers check in create statements and you deploy incremental changes, it is pretty simple to setup just have a build step call sqlpackage.exe to deploy or generate scripts
We are using TFS (service, not server) to manage the versions of our database schema. Periodically TFS generates a build and saves it in a drop folder.
Following best practices (http://martinfowler.com/articles/evodb.html), recommendations, and above all, based in our own experience (and suffering), we want to generate automatically a daily/weekly diff script with the changes checked in.
There are a lot of tools (RedGate, Visual Studio, Open Sourece) that help to do this job, and I've tried all. But in all the cases needs to be done manually.
We are doing as often as we can… but since it is manually it is not as often as it should be necessary ;)
Is there a way to do it automatically (unattended)? Can be done between 2 deployment scripts of builds? Or to do it between 2 databases? Is it also possible to compare data automatically too?
Yes, it is possible to automatically generate the difference script. We have done that in my company.
We're using vsdbcmd command line tool from Visual Studio to generate the deployment script from the build and later use that script to deploy in the test servers. We do that using Visual Studio 2010.
So I am in the throes of developing our Continuous Integration practices. We are a .Net/MSSQL shop. We will all soon be on VS2012. We have settled on CruiseControl.Net for CI server, using msbuild to compile our projects. We use SVN (possibly switching to Git later, but that's another discussion) for source control. I'm leaning towards using InstallShield to deploy code packages (usually web apps and/or batch exeutables) to our QA and production servers. (CCNet would build these MSI's as part of our CI.) We are also starting to include unit testing in our projects, and will use NUnit integrated with CCNet to run them automatically upon check-in.
So far this works for our standard web app/exe development. Where it does not fit in (yet) is with our MSSQL change management, or lack thereof. It's been pretty cowboy how we've done this. Some folks have used Migrator.Net. Others just do a SQL Compare with Redgate and generate a script. Still others have hand-written sql scripts. It may or may not be in SVN. "Source control" at the db level is basically "we have backups of our databases." Boo, hiss. Needless to say that if we want some consistency with our CI and with our deployments, we need to settle on something. So far I am leaning towards using VS SQL projects to handle the change management and deployment.
Note: we (developers) are not supposed to push changes. Sys admins do that. So we can't run anything to deploy code or sql.
So, 2 problems to solve (I think):
What "technique" to use so that our CI server blows away a CI version of the database so that unit tests can be tested against it. I've settled that VS2012 SQL projects can do that. CCNet can run msbuild against the db project, which recreates the database. This is fairly easy.
How to generate change scripts for our QA and prod environments? This one I'm stuck on.
VS can do a schema compare and then generate the sql script -- but it is dependent on sqlcmd. So our sys admins would have to run sqlcmd from the command prompt to deploy it... probably not ideal. Right?
I could run msbuild again to deploy... but I don't want the database re-created, I just want changes deployed.
So what are the options here? I need something self-contained for the admins to run -- and check-in to SVN. Should I make another msi for database deployments? Can CCNet/msbuild make some other kind of "deployment package" for database changes (not re-creation) where the sys admins can double-click and go?
How do you all handle this?
Thanks
Tom
Check out the SQL Server Data Tools package from the Microsoft site.
This will register a new SQL Server 2012 Database type project to contain the definition for all of your database structures. Upon build, this will generate a create script that you can use to deploy your database.
Then for upgrading your database, use the SQLPACKAGE.EXE tool using the create script and target database server name to generate an Update.sql script.
Update: Also on the issue of how you're running unit tests, you could create supplemental methodologies that invoke the create scripts by launching a process and and passing the path to the output create.sql script, then have your tests 'tear down' the database using the same method but with a drop database statement.
I am trying to get our company's database objects stored in source control. We are going to be stuck using Aldon LM for our source control program. What is the best way to deploy scripts that we create to our SQL Server environments automatically from source control?
For our .Net web applications, we have configured Aldon to push our code to the web server and run MSBuild.
We have programs (ant hill pro for one) which go through the source control system, and retrieve all the necessary sql scripts and compile them into one file. We have a branch for each release, so only the ones for that branch get get pulled. I think cruise control can do the same thing, but I don't know how that is done.
We then can execute all the updates and once and don't have to worry about missing one.
Open a Database project in your solution to manage all SQL code such as stored procedures. This has a few advantages:
Your SQL can be under version control just as the rest of your conde
You can do easy find/replace file operations on multiple procedures
You can keep your SQL in a meaningful and systematic folder hierarchy
Install VS Team System Database Edition, now included (available to add to) Developer Edition.
This has tools to work out which scripts to apply to a database to update it to match the reference database and will (providing your SCM integrates with VS) also handle tracking all those scripts and there status within the project.