5. Development: The database side (2/2)
DEV
PRODHmm, what to release this week?
New tables, some data, a view or two,…
6. Let’s compare
Version well defined Say what?
Version controlled sources On a good day locally
Well defined release I’ll have a look
The code The database
7. Let’s focus on the database for once
Version well defined Say what?
Version controlled sources On a good day locally
Well defined release I’ll have a look
The code The database
8. Ever considered database migrations?
Recreate from scratch
Clear state
Easy version upgrades
+
+
=
9. How does it work
Step 1: version control
Creates a table SCHEMA_VERSION schema_version
10. How does it work
Step 1: version control
Creates a table SCHEMA_VERSION
Step 2: scanning
Scan filesystem/classpath for new migrations
schema_version
version 1
11. How does it work
Step 1: version control
Creates a table SCHEMA_VERSION
Step 2: scanning
Scan filesystem/classpath for new migrations
Step 3: sorting
Sort the new migrations on version number
schema_version
version 2
13. Ready to migrate
Step 1: version control
Creates a table SCHEMA_VERSION
Step 2: scanning
Scan filesystem/classpath for new migrations
Step 3: sorting
Sort the new migrations on version number
schema_version
version 2.8.1
pending
15. How do migrations look like? (1/3)
Plain SQL
Versioned
Repeatable
Java
V2.1__create_bar_invite.sql
CREATE TABLE bar_invite (
id uuid NOT NULL,
email text NOT NULL,
registration uuid,
created_on timestamp with time zone NOT NULL,
bar_id uuid,
user_id uuid,
bartender boolean
);
16. How do migrations look like? (2/3)
Plain SQL
Versioned
Repeatable
Java
R__create_bar_invite_view.sql
CREATE OR REPLACE VIEW bar_invite_emails AS
select email
from bar_invites;
17. How do migrations look like? (3/3)
Plain SQL
Versioned
Repeatable
Java
V1_2__Another_user