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.
Related
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.
Ever since I started vb.Net programming, I have been using MS Access as back-end for all my programs.
It is easy to publish application with the MS Access database and run it on another PC without installing the MS Access database.
But now, the project I am working on needs a database with high storage capacity which means MS Access is no longer an option and I have chosen to use SQL Server. Now my question is do I have to install SQL Server on any system that the application will be run on? If so, how will I copy the database that I created on my development machine to other system so that my application will connect to it? Or is there any simpler way of doing this?
SQL Server is a client/server DBMS so you only install the database on the shared server. .NET includes SqlClient, which provides the client components needed for SQL Server applications.
There are a number of options for database deployment. Although you could use restore or attach your development database for the initial database deployment, that won't work well for future upgrades (assuming you want to keep data). Consider using T-SQL scripts and/or SQL Server Data Tools (SSDT). That will allow you to create new databases, such as for development and testing, as well as upgrade existing ones.
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)
Migrating a 2003 SharePoint farm from an old SQL Server 2005 install to a SQL Server 2012 install on a separate server.
We recently lost our SharePoint expert, so since me the DBA uses Microsoft products it shouldn't be that much of a leap right?
I can't for the life of me find the actual farm database configuration in SharePoint. I will need to change the connection string(if it uses such a thing) to point to my new database server after I detach and attach the database files.
It might be better to move the content databases over, and then re-run the SharePoint Technologies Wizard and create a new config database. Once done you can recreate the applications and re-add the content databases. I have had to do this after upgrades / failed patches, config corruptions etc. With an upgrade, you will also want to run the tool again to update the database schemas to the latest version.
Related : Visual Studio 2013 (Professional Edition)
I am trying to create Data Migration Script to deploy the changes on Staging Server.
This works locally fine. But When I try to run the generated Script on Azure Database, I get TextPtr is not supported on Azure platform. I studied more about it & found that the newer editions of SQL Server (sply for Windows Azure (SQL 2014 may be)) has dropped some keywords/functionalities the list can be found here.
The Sql Database Project only provides the Schema Compare, but Data Compare is avilables in tools Section (where we can not set Target Project Type property).
I wonder how can I deploy/Migrate the changes made in one environment to another in such a Situation. Currently I had to overwrite the existing Database on Azure platform.
But this is not Identical also, for first time this could work but not for later, as there could be some changes made to the Staging or other environments.
I had a similar problem, when trying to migrate between a test and staging environment in Azure. As a quick fix, I got around the problem by just doing a "copy" of the dev database via the Azure dashboard.