I'm trying to upgrade my TFS2017 Update 3 environment, to a new Azure DevOps Server (on-premise) environment.
I've created a new server for Azure DevOps Server, as I'd like a newer version of Windows Server, and in general just want a completely fresh environment. I took backups of my databases, shut down the old TFS2017, without deleting anything.
I migrated the databases to a new SQL Server instance (where I have all my other databases), as I see no need to use an SQL Server license just for source control.
Now comes the fun part. I tried to configure Azure DevOps Server to use the existing database (after the migration to the new SQL server instance was done). I had some issues with the TfsJobAgent service, but got those resolved.
I then tried to reconfigure Azure DevOps Server (as it failed the first time), but during configuration, it now tells me that data is corrupt, and that the existing database cannot be used. Good thing that I took backups :)
It should be said, that the new SQL server instance is a 2019 version, so that shouldn't be a problem.
I'm not quite sure what is happening here, and why it's giving me this error. Am I migrating in a wrong way? There's not much documentation out there describing this flow.
Please go through the documentation below before upgrade:
https://learn.microsoft.com/en-us/azure/devops/server/upgrade/get-started?view=azure-devops
And follow the steps in article Upgrade scenario walkthrough for Team Foundation Server to upgrade your TFS. Summarize the steps here:
Prepare your environment. The first step is to check the system requirements for TFS 2018. Upgrade SQL Server is
necessary for your scenario. Including SQL Server, you also need to check other system
requirements and prepare the environment.
Expect the best, prepare for the worst. You must have a complete and consistent set of database backups in case something
goes wrong.
Do the upgrade. Once the preparation is done, you'll need to install the new version of TFS to get new binaries, and then run
through the upgrade wizard to upgrade your databases.
Configure new features. Depending on what version you upgraded from, you may need to configure each team project to gain access
to some of the new features made available.
Related
I'm currently working on a enterprise that uses TFS 2017, and we pretend to upgrade to Azure DevOps. So far I'm just studying about how to implement this TOOL. I'm new on devops things and I have these following doubts... Why do we need SQL Server to install DevOps Azure? What kind of information are stored in there?
In the server configuration wizard, I have the option to select an existing database to use for the Azure DevOps Server that's being deployed... Can I select the currently database that's used by TFS 2017?
Azure DevOps Server and Team Foundation Server store just about everything in massive SQL Server databases.
The main server configuration is stored in the tfs_configuration database and each project collection is stored in a separate database The default is tfs_defaultcollection.
The collection database holds all version controlled files (TFVC and Git), all work items (Product Backlog, Sprints etc), Test Cases and all test run attachments, your Pipelines, Builds and Releases as well as all of the artifacts produced by these pipelines.
These databases can grow considerably.
Whether you can keep your current database server depends on what version you're currently running. SQL Server 2016 SP1+ happens to be supported by both Azure DevOps Server 2020 as well as Team Foundation Server 2017. You could keep using that for the upgraded installation.
But my recommendation would be to install SQL Server 2019, you'll get all of the performance and security benefits of the new server, support for the latest Windows Server platform, as well as a support window that matches your new Azure DevOps Server installation.
You can find the SQL Server compatibility matrix for TFS/ADS here:
Azure SQL Database and SQL Server
TFS 2017 was one of the last versions to require a database for the Warehouse, which is a form of replicated data. Reports can be written to pull data from the warehouse, without impacting the user experience. The database is somewhat deprecated now, especially for reporting. Microsoft promotes the use of the API to pull data from the live database. TFS does however still need its "live" database to store all of the data presented to users. These will be work items, discussion comments, project templates, user mappings to AD, amongst other things.
You will need to upgrade your 2017 Schema to conform to the new standard as defined by Azure, which will be taken care of as part of the upgrade.
What kind of information are stored in there?
Issues, templates, build results, lots of things.
Can I select the database that's used by TFS 2017?
Yes, that will be upgraded during the installation.
We have a single MS Server 2012 for hosting our MSSQL 2014.
On the Server we already installed two instances of MSSQL 2014.
One for the productive Business-Applications and one instance for the development Databases.
Beside the MSSQL 2014 installation we need to setup the TFS2013.
My question is if it is a good thought to make an own instance for the TFS or if we should just use one of the existing instances (Probably the dev) to store the databases.
We would love to use another instance because we would like to isolate the TFS Databases (so a restart of the TFS SQL Service should not affect the prod dbs) from the rest. We know that the administration needed for three instances is bigger than for two but we can neglect that.
Will there be a big loose in performance with a third instance, or isnt it that dramatic?
To avoid some anwsers, there is no possibility to implement the TFS or MSSQL on an other server(Because we just don't have any free resources).
The Server is from the hardware POV suitable and because we're a small company there won't be that much connections to the DB's (40 Employees to the Prod Instance, 3-5 Developers connecting to the DEV and TFS Instances).
The data tier of your TFS installation does not require any restarts. It's just a database that's created on your SQL Server.
The application tier of TFS is where the real work happens. This is where your users connect to and where the Windows Service and IIS websites are running.
It is no problem to use a shared SQL Server instance for installing Team Foundation Server.
If you want more information on how to install TFS checkout the ALM Rangers documentation. We have just released a new version of the guide that can be found here.
I would install also on a separate instance because the development or the production databases may require an SQL Server services restart which will cause a TFS unavailability.
Also you don't want to give permissions to the developers on TFS databases (usually developers are requiring higher permissions on their development databases, e.g. sysadmin for backup/restore)
We have migrated our production environment to Azure (using SQL Azure instead of SQL Server)
Our local development environment uses SQL Server. We write change scripts when database changes need to occur during a release.
PROBLEM
The issue now is that some T-SQL commands/statements/keywords don't work when run on SQL Azure. This is constantly disrupting our release process.
Educating everyone to use a subset of T-SQL is happening, but these problems continue to crop up.
Is it not possible for us to parse our SQL scripts as 'Azure SQL compatible' in SQL Server using the parser before running them:
Thanks
If you use the new "SQL Server Database Project", there is a feature in Visual Studio that allows you to select the "Target Platform" to SQL Azure. This will allow you to build all your t-sql scripts and check them for SQL Azure compatibility. Any compatibility errors will throw errors and it can create a bacdac/dacpac/t-sql script that is compatible with SQL Azure.
In order to take advantage of this, you have to manage your code using the "SQL Server Database Project" projects in Visual Studio.
You are not going to like this answer .. but the best bet is to move your development environment to SQL Azure. We started in the same process but you will just have the constant battle. We used Redgates SQL Compare tools but I don't believe they will solve your problems, but maybe worth a shot as they are constantly getting better.
Even if you have multiple devs and they each need a SQL Database I would still recommend getting everyone to signed up with Azure and pay the cost under it. Thankfully the database are not that expensive to run, and you might get under the free tier structure. It is still cheaper for us to run the cost of the SQL Azure Dev boxes than it is to have the pain and waste of time at release.
We have just created a new Windows Server 2012 with TFS 2012 using a SQL Server 2012 db. I need to migrate the code with history from a TFS 2010 using SQL Server 2008 RS to this new server. Any suggestions?
I went down this road recently. You basically have two options:
Migrate
Upgrade
Migration
I started going down the Migration route and downloaded the TFS Integration. In short, this ended badly. I spent a total of 2 weeks running the migration and eventually gave up. The tool said that it was going to take over a month to complete the migration.
Eventually I gave up and instead tried the Upgrade route.
NB. I want to point out that whilst I had issues, I'm sure there are many people have used this tool successfully. I am only speaking from my own experience
Upgrade
You are in the same position as I was, namely you already have a new server ready to go. All you need to do to upgrade is as follows (This is not a full guide, there is a link below to a complete guide for this process.):
Open Team Foundation Administration Console on the 2010 server
Click Team Project Collections
On the General tab, select Detach Team Project Collection - a wizard opens
Follow the wizard and detach the collection.
Once detached, backup the Collection Database
If TFS 2012 is already installed then simply restore the database into the new TFS 2012 instance. If not, you need to prep the new SQL Server using TFSConfig PrepSQL.
Restore the backup into the SQL 2012 instance
Attach the collection in the Team Foundation Administration Console on TFS 2012.
The Detach and Attach processes are important as they prep TFS for the transfer process and actually perform upgrades on the database
This is not a full guide, this is just a set of pointers. I strongly recommend you read this page fully before performing any steps. http://msdn.microsoft.com/en-us/library/dd936138(v=vs.100).aspx#Backup
I figured it out!
I used this series to do the install of TFS and the migration:
http://mohamedradwan.wordpress.com/2013/01/05/upgrade-tfs-2010-to-tfs-2012-with-migration-to-a-new-hardware-series/
Answers to my comments below:
When you go to your Team Project Collections you can actually use the ChangeUrl function to reset it to what it should be. It is common that it will come up with the wrong url when doing a restore from another server. I took screen shots of the process and should have paid closer attention to the warnings that were at the finish.
As far as my second question, apparently VS keeps a config file that has the mapping settings which contains the credentials. I tried to remove and save, but for some reason this didn't work. I mapped it to a new folder, and it worked without issue.
I am on a shared host and whilst in development (umbraco) I think it would be easier to use VistaDB then package up to install to SQL Server. However, I have already started using SQL Server. Is there a way to migrate my SQL Server (2008) database to VistaDB. I assume the schema is identical but I need a way/tool to move the data to VistaDB.
You could migrate to VistaDB in the same way that you want to migrate data from development to production. Create a package from your current SQL Server-based development site, then create a new empty install of Umbraco with a VistaDB database and import the package there.
This would also be a useful dry run to check that migration to production is going to work as smoothly as you expect.
You can also use the Data Migration Tool in VistaDB to migrate any SQL Server database to VistaDB 4. If you need an older migration (I think the current Umbraco is still using VDB3 files) contact support through the VistaDB.Net site and someone will help you.