Delivering database changes pose a unique set of challenges that force many to treat database changes as a second class citizen when releasing software. In this course, you'll learn how to use Flyway to version changes to a MySQL database. You'll also learn how to leverage versioned changes from your code repository to get early feedback about potential problems, including how to simulate a production database update every time someone checks in a database change.
Continuous Delivery can dramatically decrease turn-around time between customer need and delivered software to fulfill that need. Combining discipline with the right practices and tools leads to early feedback about potential problems, a system of safety nets, the highest level of accountability, and an overall boost in confidence when releasing software. Delivering database changes poses a unique set of challenges that force many to treat database changes as a second class citizen when releasing software. This leads to delays and a lack of realizing the full potential of Continuous Delivery. In this course, you'll learn the fundamentals to make managing database change a breeze and how to make it a first class citizen in your Continuous Delivery pipeline. You'll learn how to use Flyway to version changes to a MySQL database. You'll also learn how to leverage versioned changes from your code repository to get early feedback about potential problems, including how to simulate a production database update every time someone checks in a database change.
Wes Higbee is passionate about helping companies achieve remarkable results with technology and software. He’s had extensive experience developing software and working with teams to improve how software is developed to meet business objectives. Wes launched Full City Tech to leverage his expertise to help companies delight customers.
Tracking Changes Hi, this is Wes Higbee. In this module, we're going to talk about tracking changes. Why? Because as you move to a model where each developer has her own dedicated development database, they'll need a way to not only track their changes but share them with others. This begs the question, how do we go from a central version of the truth in a shared development database to a model where files and Version Control become the central version of truth for our database? First, we're going to look at a conceptual approach to tracking changes then we'll look at a tool called, Flyway that can help us track changes and apply them automatically. Then we'll use Flyway throughout the rest of the module to start building out an actual database. By the end of the module, you'll see how simple it is to not only track changes but to apply them automatically, to create new databases on the fly, to share your changes and Version Control to capture the exact path the changes took and to keep an accurate history of those changes. Even the very first versions of a new database.
Development Workflow Hi, my name is Wes Higbee. Welcome to this module on a Development Workflow for working with database changes. Now that we understand how we can track and automatically apply changes, it be good to talk about how on a day to day basis, you can go about developing changes in a safe fashion, testing them, and sharing them with other people. Then we'll also look at what happens when things go wrong. We'll look at what happens when applying a change fails and we'll also look at what happens when we forget to put everything we need to into a SQL change script. In this module we'll focus on keeping a good set of notes about the changes we're making so we can easily create a SQL change script to share with other people. Then in the next module, we'll talk about a reverse engineering workflow so if you don't have notes to refer to, you can go about successfully recreating the changes you've made.
Pulling Changes Hi, I'm Wes Higbee. Welcome to this module on pulling changes. In the last couple of modules, we have been looking at how we can develop changes ourselves on our own dedicated development databases. But the reality is, other people are going to be developing changes as well. And at some point, we're going to need to pull changes from other people and apply them to our own development databases. In this module, we're going to see how you can go about pulling changes that other people have shared with you through version control, and specifically, how you can find out about database changes and how to deal with the situation when you might be building up some changes yourself while somebody else has just pushed changes to the database.
Transition Existing Databases Thus far, we've been working from the basis of a brand new payroll database, but the reality is, we all have existing databases that we might like to apply this same process to. It'd be nice to have a strategy with which we could easily transition an existing database, and put it under the scheme where we can track our changes through version control, easily share them with other people, find out about problems, and automatically pre-test production releases, and maybe even automate production releases. In this module, I'm going to focus on that strategy, how you can go about taking a legacy or existing database, and bringing it into this new, wholesome approach.
Rethinking How We Develop Now that we have a process that allows us to not treat database changes as second-class citizens we have the opportunity to re-think how we actually develop. In this module I want to talk about a couple of aspects of this. First, we'll discuss the opportunity to deliver more frequently, and why we would want to do this. We'll also talk about how we get buy-in with this process, in general, regardless, of how we develop. I'll take a minute to squeeze in a little discussion about code-based migrations versus SQL-based migrations because it's a great example of a situation where we can incentivize other people's participation based on the choices we make. We'll talk about what happens with database changes and branching. How we can be creative with our database changes, and how this process will allow you to start rethinking failure, in terms of releases, and challenge the traditional roll-back model.