I am a 1 man team, more dev's coming on board, I have created a few on Premise SQL DBs; I have a Azure SQL DB managed instance and Azure Devops account setup
Currently:
I use SSDT -->Tools--> SQL Server: to manage the data and Schema comparisons , make sure it is in sync, On-Premise and Azure managed instance (as a backup at present, managed instance is not used for anything else)
I want to do
To manage the code for multiple devs,
I want to setup Azure SQL DB managed instance as production
SSDT or Git hub for version control(manage check-in / check out of SQL objects, we are all in sync)
Local on premise version as the development area, sync in with prod, use TFVC (SSDT) as tool to manage
the code conflicts , make sure all devs are working off the same DB
Q: Can I link my on premise SQL DB to DevOps source control , then links to SQL Azure managed DB? Can I do this with SSDT / GIT hub or do I need both?
Any step by step tutorials to set this up? In SSDT I am connected to my on premise SL db and to DevOps Repo , finding it difficult to figure out how to establish the link between the two
Getting overwhelmed with all the acronyms and 101 different products you can use (state based approach, DACPAC files, YAML , arm template , octopus deploy, redgate, dacfx,)
Cannot find anything online so far to show me how to setup from the ground up
Q: Can I link my on premise SQL DB to DevOps source control , then links to SQL Azure managed DB? Can I do this with SSDT / GIT hub or do I need both?
You have to install a self-hosted agent to access your on-premises instances
Then the pipeline flow can be built this way:
Build DacPac -> Deploy to Test (On-Premises) -> Deploy to Managed Instance (Prod)
Other points:
Since you are starting a new project, consider to use YAML pipelines.
Also, SSDT, starting VS 2019, is not suitable anymore for free use in a commercial environment. You have to get Professional or Enterprise license.
As the alternative, cross-platform Azure Data Studio + Database Project add-on
And some of the concepts blogged by me earlier:
https://www.alexvolok.com/2020/azure-devops-sql-server-dba-creating-database-project/
https://www.alexvolok.com/2020/azure-devops-for-sql-server-dba-automating-deployments/
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.
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.
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)
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.
I am looking for a means to use Git deployment on Windows Azure together with either their MySQL or other database solutions.
I need a means of migrating database schema changes as part of deployment - does Azure provide support for this without using Visual Studio or .NET.
You basically want to use Azure as a Continuous Integration (CI) platform and my view is that Azure by itself just isn't there yet.
A basic git based CI scenario would involve the following steps.
Your src code and any database schema/data updates are pushed to a central git repository like GitHub. [Feature available]
GitHub would then push the updates to Azure. [Not supported in Azure until they support GitHub hooks]
Azure compiles and deploys the code. [Supported]
Azure updates the database from sql files pulled from the repo (remember, this needs to be automated). [Not supported]
Azure reports any error in running the database or web application. [Supported]
Azure runs user provided integration tests to check more thoroughly specific functionality and reports the status of those tests to the user [Not supported].
Azure allows you to roll back to a previous deployment snapshot [Partly supported. Snapshots are not based on git commits for instance].
I might be wrong on some of those points or new features might be added since I've written this. Corrections are very welcomed and I'll try to update the list accordingly.
I am not sure how much experiences you have with Windows Azure Websites, however when you are creating a Windows Azure Websites, you have ability to use SQL Azure Database or MySQL cloud database directly integrated with your Windows Azure Websites.
So if you will use SQL Azure Database then there are several ways you can migrate your DB following the link here:
Migrating Databases to Windows Azure SQL Database (formerly SQL Azure)
To manage MySQL you can use Local Web Server to do it. The way I have done is to use PHP, the MySQL Command-Line Tool (part of MySQL), and a web server set up on my local machine, and that I have enabled the PDO extension for MySQL. This way I can manager my MySQL directly from my own local machine and the details are explain at the bottom of this article:
Create a PHP-MySQL Windows Azure web site and deploy using Git.
Also the SQL part you can write in Workbench if you use MySQL and Oracle SQL Developer if you use Oracle SQL.
Finally Git Deployment allows you to deploy your any kind of application directly to Windows Azure without using VSx.