Master Database Migrations with Liquibase and Kotlin Spring Boot
In this video, we are going to explore the process of applying database changes using a database migration tool, specifically focusing on Liquibase. We'll dive into a Kotlin Spring Boot microservice that collects event information and uses a PostgreSQL database managed with Liquibase for migrations. I'll walk you through the code and demonstrate how to create tables and columns, manage database migrations, and ensure your service is working as expected.
We'll also discuss the impact of backward-compatible and incompatible changes on the data layer and how to modify the database without causing breaking changes. By analyzing examples of both types of changes, you'll learn how to handle them in a safe and efficient manner. In addition, I'll share some recommended practices for database migrations, such as rolling out schema changes independently from application changes, throttling updates, coordinating database changes with scheduled backups, and waiting before dropping tables or columns.
Throughout the video, I'll be providing step-by-step instructions and showing you how to test your application using HTTP calls. You'll also find all the necessary commands and instructions in the video description, linked to a website containing a detailed tutorial. So join me in this informative and practical guide to enhancing your database migration skills and ensuring the seamless operation of your applications!
Tutorial: https://amasucci.com/posts/database-m...
Code on GitHub: https://github.com/outofdevops/db-mig...
Chapters:
00:00 Intro
00:27 The Service (in Kotlin)
01:56 The Database (Postgres)
02:42 Running the service
04:09 Calling the services via HTTP
05:01 Backward compatible DB migrations
05:41 Apply Liquibase migrations
09:12 How to rename a column without breaking your application
10:12 Best Practices for Database Schema Migrations
Best practices
Here are some best practices for database migrations:
Rollout schema changes independently from code changes, don’t bundle Schema changes and code changes in the same release. I also prefer to use different release processes to rollout DB changes, for two reasons:
permissions: privileges required for Schema changes are higher than the ones needed for normal operations
better design: bundled changes are impossible by design
Throttle the updates, execute them in small batches as they can affect DB performance or even stop completely the access in case of locks on tables
Coordinate Database changes with backup schedules, ideally we would like to execute the DB schema changes immediately after a backup
Wait before dropping, make sure you have enough confidence in the change you just applied. Monitor performance and statistics before and then wait for the next backup and then drop.
WHO AM I:
Hey friends, welcome to my YouTube channel / outofdevops . If you're new here my name is Anto, here I talk about software engineering and software engineers. Don't forget to comment like and subscribe 👍🏻.
YOUTUBE GEAR:
🎥 My YouTube Camera Gear - https://kit.co/outofdevops
MY SOCIAL LINKs:
🐦 Twitter - / outofdevops
📘 Facebook - / outofdevops
📰 My blog - https://amasucci.com
🌍 OutOfDevOps Website https://www.outofdevops.com
📸 Instagram - / outofdevops
GET IN TOUCH:
If you’d like to talk, I’d love to hear from you. Tweeting @OutOfDevOps directly will be the quickest way to get a response, but if your question is very long, feel free to email me at [email protected].
PS: Some of the links in this description are affiliate links that I get a kickback from 😜
