In previous post, we discussed about the problem of Database deployment and use Liquibase for Database CI/CD purposes. We also discussed the basics of how liquibase works behind the scenes. Now the next step is to install and configure liquibase. The steps here are for Windows OS but Liquibase being a cross-platform tool, the same can be repeated on any major Operating System.
For most of the Organizations, it is almost unthinkable to work in a software project without some kind of version control. The benefits of tracking and retaining an incremental history of the code are well understood and documented. However most of the time this has been limited to the application code and not the accompanying databases. This has remain a concern due to the many complexities and cultural issues associated with how the databases operates and their various versions. However, it is not just limited to keep database schema and data changes as part of the version control. Continue reading “Include Databases in CI/CD pipeline using Liquibase”
Many a times, you would need to identify the difference in database schema for two SQL databases so that you can take certain course of action. There are a lot of tools in market which can do this, but you would need to pay for them to get full difference or to use them on continuous basis. However, Microsoft Visual Studio has this functionality built-in for you and if you happen to use Visual Studio as your code development tool, this functionality is basically free. So in this scenario, it also prevents hassle of learning another tool. In this blog post, we’ll learn how to do the same using Visual Studio.
Caution – I am going to demo this Visual Studio Enterprise. I’m not sure what all sku’s it is associated with, so if you cannot repeat steps below, you might want to check that. Continue reading “Compare SQL Database Schema and deploy changes using Visual Studio”
The combination of technical and cultural processes behind databases makes automation difficult. Databases has a state associated with them, so you cannot blow them away like application code and create again from scratch without losing the data. Managing change in a way that doesn’t impact the data is very problematic. Combine that with the cultural issues, the silos, it creates a really difficult problem. There are some general best practices that you can apply to tackle a lot of this complexity, but any time you try to design the solution and get into the technicalities, a lot of time you end up implementing something very specific to a particular type of database. In this blog post, we’ll learn how to use SSDT to implement continuous integration and deployment for SQL database Schema to take some of these worries away.
I don’t do this a lot since most of the apps are now a days using Azure SQL using all the benefits it offers. So I thought it would be better to take note of all the steps done for this. If the msdb database is damaged and you do not have a backup of the msdb database (for whatsoever reasons), you can create a new msdb by using the instmsdb script. In this blog post, we’ll go through steps required for the same.
Rebuilding the msdb database using the instmsdb script will eliminate all the information stored in msdb such as jobs, alert, operators, maintenance plans, backup history, Policy-Based Management settings, Database Mail, Performance Data Warehouse, etc.