Can I somehow get a build number into an extended property of my published database?
I use SSDT Projects and tfs build.
I want to get as much information as possible into the database.
I know there are a few variables, such as database name. Perhaps there are more?
Even build date would be useful (timestamp from when the deployment script was created).
But ":setvar ts GETDATE()" won't work since the GETDATE not being evaluated.
EDIT: I got it working by editing the xaml and then using XmlPoke. I can post more details if there is interest.
Pass the build number to a post-deployment script that is updating the extended property
Related
is it possible to update a databaseproject automatically? For example on a TFS build server?
I had a big database and just start with the databaseprojects. So currently our database is primary not updated by a databaseproject and thats the reason why i must update my project alot to get it sync with the database. Currently i use a preconfigured schemacompare of the datatools. But the update of the project must be done by hand :(
Is there any way to do that automatically?
Regards
If I understand your question correctly, then you should probably look into creating a .cmd script that calls SqlPackage.exe. The operation you are interested in is Extract. You should be able to update your .dacpac file with the current DB schema using this.
Visual Studio 2013 has a feature that allows for performing a data compare between your SSDT project and a target database.
According to another post here on SO, there are certain requirements with regards to performing such a compare.
Those requirements taken into consideration, I want to do something like this as a part of our build and deployment process:
Publish any DB schema changes to the target database(s) to make sure that source and target have exactly the same tables, columns, SP's, etc. to comply with the requirements mentioned in the link above
Run a data compare and generate an update script, or publish any changes in the source DB directly to the target DB
Currently, I have a script which takes care of bullet no. 1 by doing a schema compare, using a DACPAC, via sqlpackage.exe. It does not look like it is possible to perform a data compare using sqlpackage, though, and I have not found any other alternatives yet. In VS 2010 it was possible to run a data compare via the command window, but I have not seen any documentation regarding this in VS 2013...
Thus, my question is if there exists an API and/or other tools that allows for a data compare to be run programmatically through e.g. a Powershell script.
It appears you are correct, for schema diff there is command line support as long as SSDT is installed on disk (more details here), but there is no programmatic interface yet for data compare and update.
Am new to TFS and learning about CI.
Am going to Team Explorer = > Builds to see the list of build definitions created.
How do i identify who(Which user) has created that build definition ?
Am not getting where it is listed !! Hope it is available
Thanks
There is no option in TeamExplorer and I think there is no other way, because even in the database is not listed who created the build definition, only when it was created.
A strange workaround would be to check who changed the folder mappings of a build definition the last time, but this is only possible in database. I'm not very good in SQL and only spent few minutes to get this trashy statement:
SELECT ident.DisplayName
FROM [Tfs_DefaultCollection].[dbo].[tbl_BuildDefinition] as bd, [Tfs_DefaultCollection].[dbo].[tbl_BuildDefinitionWorkspace] as bdw, [Tfs_DefaultCollection].[dbo].[tbl_IdentityMap] as im, [Tfs_Configuration].[dbo].[tbl_Identity] as ident
Where bd.DefinitionId = bdw.DefinitionId
and im.localId = bdw.LastModifiedBy
and ident.Id = im.masterId
and bd.DefinitionName like '%CodedUITests%'
The DefinitionName might not work well with special characters, but you can check in the database how it is written internaly.
You could see who created/changes made to the underlying XAML files but the build definition as such is not exposed as a file in TFS now. So there is no history available. This has been requested as a new feature to MS but not sure when it will be available.
LINK
EDITED: from original as frankly it was a poor question first time around....
We have a batch script called DEV.DBDeployment.DropCustomCreate.bat, as the name suggests this drops and creates our db from a fresh, a useful tool in Dev but we don't always want to drop the database, sometimes just get the latest changes.
It's worth noting currently every CI checkin triggers a build in TeamCity which pumps the current Major.Minor.BuildNumber.Revision (e.g. 1.0.123.1568) number in to all AssemblyInfo.cs files within all Visual Studio projects. This obviously allows us to stamp the resultant dll's with the build number, pretty standard stuff for sure. We also overwrite a BuildInfo.txt file in a similar way, most importantly this BuildInfo.txt file is included within every deployment package and sits within the RoundhousE\deployment folder and is referenced by /vf=%version.file% when we run rh.exe as mentioned above from the .bat file. So we're sorted for deploying to existing databases in Test and Prod.
However in dev the AssemblyVersion is always 0.0.0.0 in AssemblyInfo.cs, as is the version number in BuildInfo.txt, therefore how do devs stage their changes locally against their database. For example, with this setup when we run rh.exe all changes will be stamped with the version number 0.0.0.0. Is the expectation that in dev you will always drop and create? If that's the case I'm assuming we need TeamCity to checkin the BuildInfo.txt file so RoundhousE can reference it from source control when executed in dev?
Is there something I'm missing here?
I think we discussed this over here - https://github.com/chucknorris/roundhouse/issues/113
As you saying about the .bat file; that is a tool for roundhouse. You have to run that batch file again and again when you want to run your scripts. If you want to run scripts when you build the roundhouse database project then you have to configure that with certain steps. If you wish I can tell you if you replied.
in our company we use tfs for source control of sql database version,when developers change the database they generate Equivalent script and put it in sql tfs project and checked in it with related workItem.after build we generate patch with this script for clients,but before pacth we need to some one decide on priority of checked in script,now i want to this decition become automatic and my question is how could specified priority in the moment of check in?
Sorry for my bad english,if you want more informationn to answer let me know.thanks.
Version handling of databases seems to be a never-ending problem. At a previous client, we gave the databases version properties, and then stored patch scripts in folders for each version, e.g. "Patches/2.0.10", "Patches/2.1.0". The patch scripts could then be executed in the same order as they were checked in (creation date).
Upon release, we ended up generating a complete patch script consisting of all those separate patches merged together (since the patches often affected the same data, they could be optimized) along with a new version number, allowing us to record what version any given databes instance had.