We have a TeamCity installation as well as an external MSSQL database on a Microsoft SQL server. We've had to migrate the database to a new instance and now have to configure TeamCity to point to the new database.
I've looked through this guide (https://confluence.jetbrains.com/display/TCD10/Manual+Backup+and+Restore) among others but they all seem needlesly complicated and seem to imply a complete relocation of the entire teamcity installation whereas we simply want to point an existing teamcity installation to a new database.
A simply search reveals a config with a connectionstring hidden in teamcity/serverdata/config. It would seem like we could simply change the config file and be done with it. Are we missing something?
We're using TeamCity Professional 2017.1 (build 46533)
If you're only migrating to the new server, then changing configuration in <TeamCity Data Directory>\config\database.properties file all you have to do.
I assume that you'll make a backup, migrate data to the new database, right? After that you can safely change value in the corresponding file and restart the Teamcity. Probably make sense to check connection to the database from Teamcity server first as well.
Related
I have a Windows server with MS SQL Server running on it.
On the SQL Server developers have created stored procedures, views, tables, triggers.
On the Windows server developers created shell scripts.
I would like to start versioning the code described above in a BitBucket repository. I have a repository created in BitBucket.
How should the branches be organized in this repository? i.e. "SQL Server\Database\\ ...
"Windows Server\\shell_script" ...
Can I connect BitBucket to SQL Server and Windows Server and specify which code needs to be versioned?
Are both 1 and 2 options above possible?
I just need to version control the changes to the code and have the ability to mark under which project the code change was made.
I am new to BitBucket. I am using the web front end of it. I do not know how to configure command line access, so please try not to reference Bitbucket commands. Sorry if I sound confusing.
Please help.
I know this is an old question but anyway, in principle I'd recommend:
Put all the server shell scripts into one place and make that a git repo linked to your bitbucket repo
Add a server shell script to export what you want version controlled from the SQL db
The export from the SQL db should be to text files so they are easily 'diffable'
You might as well make the export to a sub-directory within the shell scripts repo so that everything is in one place and can't get out of sync
So you only have one branch, not a separate one for server shell scripts and db
Make sure people run the export script and then commit everything when they make a change
You ideally have a test server which means you'd want a way to push changes from the repo into the SQL db. I presume you can do this with a script but deleting the server setup and re-creating it from the text files.
So basically, you can't connect an SQL db to bitbucket directly. You need scripts to read and write to the db from a repo.
My DBA and I are trying to work out how to effectively use Microsoft's Database projects and the Dacpacs they generate to simplify our production deployment system.
Ideally, I would be able to build and/or publish the .sqlproj, generating a .dacpac file, which can then be uploaded to the production server and used to upgrade the database from whatever version it was to the latest version. This is similar to how we're doing website deployments, where I publish to a package, and then that package is uploaded to the server and imported into IIS.
However, we can't work out how to make this work. The DBA has already created the database and added it to our Availability Groups. And every time we try to apply the Dacpac, it tries to adjust settings which it can't because of the AGs.
Nothing I've been able to do has managed to create a .dacpac file which doesn't try to impose settings on the database. The closest option I've found will exclude them when publishing, but as best as I can tell you can't publish to an inaccessible database, and only the DBA has access to the production server.
Can I actually use dacpacs this way?
There are two parts to this, firstly how do you stop deploying settings you don't want to deploy - can you give an example of one of the settings that doesn't apply?
For the second part where you do not have access to the SQL Server there are a few different ways to handle this:
Use an offline copy to generate the deploy script
Get the DBA to generate the deploy script
Get the DBA to deploy using the dacpac
Get read only access to the database
Option 1: "Use an offline copy to generate the deploy script"
You need to compare the dacpac to something and if you do not have a TDS connection (default instance default port tcp:1433) then you can use a version of the database that matches production either through:
Use log shipping to restore a copy of production somewhere you can access it
Get a development db and production in sync, then every release goes to the dev and prod databases, ensuring that they stay in sync
The log shipped copy is the easiest, if it is to a development server you can normally have server permissions to give you acesss or you can create the correct permissions at the database level but not on the production server level.
If the data is sensitive then the log shipped copy might not be appropriate so you could try to keep a development and production database in sync but this is difficult and requires that the DBA be "well trained" into not running anything that isn't first run against the db database as well.
Once you have access to a database that has exactly the same schema as the production database you can use sqlpackage.exe /action:script to generate a deploy script, in fact because it isn't the production database you can generate the script as part of your CI process :).
Option 2: "Get the DBA to generate the deploy script"
This is to get the DBA to copy the dacpac to the productions server and to use sqlpackage.exe that will be in "Program Files (x86)\Microsoft Sql Server\Version\DAC\bin" folder to compare the dacpac to the database and generate a script that he can review before deploying.
Option 3: "Get the DBA to generate the deploy script"
This is simlar to option 2 but instead of generating a script he deploys in SSMS he just use sqlpackage.exe /Action:Publish to deploy the changes directly.
Option 4: "Get read only access to the database"
This is actually my preferred as it means that you always build scripts against what is guaranteed to be the state of production (as it is production). In your case you would need to get the tcp port between your machine or ideally your build machine and the SQL Server and then you will need these permissions:
https://the.agilesql.club/Blogs/Ed-Elliott/What-Permissions-Do-I-Need-To-Generate-A-Deploy-Script-With-SSDT
As I said option 4 is always my preferred but I understand that it isn't always possible.
Option 2 + 3 are fraught with worry as you will be running scripts that haven't been tested anywhere, with option 4 and 1 you can generate the scripts and then deploy to a test / QA database as long as they themselves have the same schema as production. The scripts can also go through a code review process.
If you do option 2 / 3 then I would create a batch file or powershell script that drives sqlpackage.exe and if they deploy from a different server that doens't have sqlpackage.exe then you can copy the DAC folder to that machine and run sqlpackage from that, you do not have to actually install it (you may need to also copy in the Microsoft.SqlServer.TransactSql.ScriptDom.dll from the "Program Files (x86)\Microsoft Sql Server\Version\SDK\Assemblies" folder.
I hope this helps, if you have any more questions feel free to post here or ping me :)
ed
I recently developed a winform application with c# and SQL Server 2008 data access. I want to create an "InstallShield express" setup file for it (I don't want to use ClickOnce or Setup And Deployment witch is available in VS). I want to create a db or attach it to SQL server instance after installing SQL Server Express 2008 SP3 (not local db). What is the best way to do this?
Your question is quite vague as you do not explain what kind of “app”, “setup file” or “db” you are using, nor how you “attach it to sql”. In the future, please include these details. However, I can give a general answer.
Create a seed database, that contains the starting data for your application, in your source project.
Add the seed database file to your project/solution file and set its Build Action to “Content”.
Ensure your installer includes project content in the deployment folder (the application folder for WinForms apps).
To open the seed database from your app, use a connection string like Data Source=|DataDirectory|seed.sdf. Do not try to search for your seed file or to set DataDirectory yourself; the installer will set DataDirectory to the directory your content was installed to.
Do not try to write to DataDirectory; it may not be writable by the user who installed it. Repairing the app will overwrite DataDirectory, destroying anything you saved there, as well.
If you need to save data in the database, copy |DataDirectory|seed.sdf to Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), then read and write all data to the copy.
For more information, read my answer to a poster who wrote to |DataDirectory| and therefore kept destroying his user's data.
The goal: decom the old server where TFS/SQL was originally installed, and run TFS/SQL on new server. To add insult to injury, the old server I will reference here is SBS 2011 - if you know anything about that environment, you may understand why it is slated for decom.
I performed a restoration-based move last week. While it was successful with respect to functionality, I now have what I would describe as a dual data + application tier implementation. Today, I have TFS/SQL installed on two servers, both with TFS Version: 11.0.60610.1 (Tfs2012.Update3) and SQL Version: 2008R2. Both servers in the same domain.
My curiosity lies in the behavior of the Tfs_Configuration db. I restored both the Tfs_ db as well as the Tfs_Configuration db (via .BAK files) to the new SQL server, but I still see activity happening on the old server here "c:\Program Files\Microsoft Team Foundation Server 11.0\Application Tier\Web Services_tfs_data", but no updated/recent files in the same location on the new server, suggesting the Tfs_Configuration db really did not move/restore properly.
In the TFS console on the new server, I see the URLs in the “Application Tier Summary” section referring to the old server, but the Machine Name is the new server. I also see in the "Application Tiers" section, a reference to the old server Machine name. Yet, in verifying change logs, the Tfs_ db is now resident on the new server and accepting Visual Studio commits/check-ins. There is a Tfs_Configuration db on the new server, but it seems to be the default install copy and not my restored db.
In the various guides I have read, I do understand the web.config file holds the instructional set for the catalog, etc. here "appSettings … add key="applicationDatabase" value="Data Source=instance name;Initial Catalog=Tfs_Configuration;Integrated Security=True". I was expecting to change that entry once it migrated to the new server, but rather it is still parked on the old server.
I have turned off the TFS and SQL services on the old server as a trial to see if the new installation would pick up the load, but as you might expect, TFS then goes into an unavailable state to the users.
The primary questions are:
Why did the Tfs_Configuration db not restore to the new server in the same fashion as the Tfs_ db?
How can I move that Tfs_Configuration db and turn off that old SBS 2011 unit?
Any tips or tricks are welcomed and appreciated.
Thank you.
What you did is a non trivial operation (see Move Team Foundation Server from One Hardware Configuration to Another).
Typical missing steps:
Changing URLs
Cleaning caches
Changing server ID if you want to keep both instances live
Changing accounts in case you used local user accounts
I have completed this process successfully. It required a triangulation between the three servers. The essential aspects involved solid SQL backups, coupled with the settings.xml from healthy TFS Console backups.
It was certainly a process that took a lot of planning and anticipating snags.
All-in-all, it was a great exercise in watching the data flow and understanding the roles of the configuration and collection DBs. Thank you for responding to my inquiry.
We are in the process of trying to migrate from a VPS to a shared environment. The VPS is running Studio Express 2005 so is therefore limited quite a lot in functionality in terms of exporting.
I have managed to export a database in .bak format and upload (Restore) it to the shared environment.
However, here comes the problem, the schema has come with the database. Causing problems when connecting via asp.
The table name structure is as follows [SCHEMA].[TABLE_NAME].
The shared environment does not allow for changing of schema or many advanced features. (Its running myLittleAdmin).
So I guess the schema changes would have to be done on the database, then exported then imported.
Ps. I'm new to MSSQL and more experienced in MYSQL.
Ok So I have found a solution to this.
Export the schema from Studio Express using Right Click > Tools > Generate Script.
Execute this script on the server.
Open this file, find and replace the old user with your new one.
Use a tool such as this one http://sqldumper.ruizata.com/ (SQL Dumper) to export the DB to .SQL.
Find and replace on this file, again for the old user to the new.
Copy this SQL and execute it on the server.
Job done!
Joe