• Like
Handling Database Deployments
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Handling Database Deployments

  • 6,860 views
Published

So, you know how to deploy your code, what about your database? This talk will go through deploying your database with LiquiBase and DBDeploy a non-framework based approach to handling migrations of …

So, you know how to deploy your code, what about your database? This talk will go through deploying your database with LiquiBase and DBDeploy a non-framework based approach to handling migrations of DDL and DML.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Very interesting presentation. A little comment to let you know that there is a very promising free LGPL product called neXtep designer which handles this exact same problematic in a different way : it allows you to put all your database developments under version control and uses version information to generate pure SQL based deliveries. A Java command line installer can then handle the deployment to the target databases.
    More info in the wiki of : http://www.nextep-softwares.com
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
6,860
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
151
Comments
1
Likes
12

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Mike Willbanks Blog: http://blog.digitalstruct.com Twitter : mwillbanks IRC : lubs Talk: http://joind.in/986 Handling Database Deployment ZendCon Unconference 2009
  • 2. What We'll Cover (and not cover)
    • The [Somewhat] Prerequisites
    • 3. Why Use Database Change Management
    • 4. Why To Not Use Database Abstraction Layer Migrations
      • Even You Doctrine!
    • DBDeploy and LiquiBase
      • How It Works (under the hood)
      • 5. Basic Syntax
      • 6. Recommended Structure
  • 7. The [Somewhat] Prerequisites
    • You should be using an issue tracking system.
    • 8. You should be using source code management.
    • 9. You already know how you are deploying your code.
  • 10. Why Database Change Management
    • Do you version your code? Same reasons apply to database deltas (or change sets).
    • 11. Deltas typically are a part of a code change.
    • 12. Ensures the correlation between code revisions.
    • 13. Allows the automation of changes.
    • 14. Ensure you are keeping environments consistent.
    • 15. Allows for reverting back to previous versions (some voodoo magic may be required).
  • 16. The Traditional Way - #fail
    • Developer writes code and applies database change locally.
    • 17. Developer forgets to note change on bug tracking ticket or notify anyone of the change or DBA misses the change, etc.
    • 18. Code deployment and database deployment happens.
    • 19. System is broken... #fail
    • 20. Developer attempts to figure out what happened, “oops factor”.
  • 21. A Better Way
    • Developer writes code and writes a database delta.
    • 22. Developer tests changes locally.
    • 23. Code and Database Delta is committed against a ticket (or at least together).
    • 24. Pre-Deployment Database Changes are Applied.
    • 25. Code Deployment is pushed out.
    • 26. Post-Deployment Database Changes are Applied.
    • 27. System === happiness.
  • 28. Some Process Theory Simplified
    • Database Pre-Deployment
      • Apply database changes compatible with current code, in preparation for new code.
      • 29. Essentially, do not break what is already out there.
    • Code Deployment
      • No more detail needed.
    • Database Post-Deployment
      • Clean up database that was compatible with old code and /or migrate to fulfill new requirements.
  • 30. Database Abstraction Migrations
    • Many do not support pre and post migrations.
    • 31. If you change your abstraction layer, you must change your migration logic.
    • 32. Example Case:
      • Code Deployment
        • Database Migrations Run on 1 st Machine
        • 33. What about the n+1 machines?! #fail
  • 34. DBDeploy : dbdeploy.com
    • Java based solution - #port anyone?
    • 35. Utilizes SQL delta files.
    • 36. Handles undo within the delta file.
      • If using Ant – Issue #29 :)
    • Utilizes different table names to handle different deployments.
    • 37. Queries the database for what has not been applied and generates a SQL file to apply towards the database.
  • 38. DBDeploy : Getting Started
    • Install Java 1.5+
    • 39. Download DBDeploy (Obvious)
    • 40. Download your Java Connector
    • 41. We will be using the command line version (rather than ant for this talk)
      • It is kind of a blackbox :)
  • 42. DBDeploy : Initial Setup
    • Under scripts, install the SQL file for your database
      • Ensure you run this twice with 2 different database names. I suggest creating a pre and post changelog table.
    • Put the Java Connector somewhere that you can reference it.
  • 43. DBDeploy : The Command Line
    • java -cp [path/to/driver]:dbdeploy-cli-3.0M2.jar com.dbdeploy.CommandLineTarget
      • Relevant Parameters:
        • -D | --driver Database Driver
        • 44. -d | --dbms Database Type
        • 45. -s | --scriptdirectory
        • 46. -o | --outputfile Output File
        • 47. -u | --url DB URL
        • 48. -U | --userid DB Username
        • 49. -P | --password DB Password
        • 50. -t | --changeLogTableName
  • 51. DBDeploy : Writing a Script
    • Files run in the format of:
      • 001, 002, 003... with .sql on the end.
      • 52. You can add a comment on the file name:
        • 001_created_test_table.sql
    • Put in your delta, then for handling an undo, put in a comment in the format of:
      • CREATE TABLE `xyz` (id INTEGER); --//@UNDO DROP TABLE `xyz`;
    • Save this file to a directory of the type of script:
      • You did do pre and post changelog right?
  • 53. DBDeploy : An Example
    • java -cp mysql-connector-java-5.1.10-bin.jar:dbdeploy-cli-3.0M2.jar com.dbdeploy.CommandLineTarget -Dcom.mysql.jdbc.Driver -dmysql -sexample/ -u"jdbc:mysql://localhost/uncon2009_db" -Uuncon2009 -P***** -tchangelog_pre --outputfile deploy.sql
      • This will create the deploy.sql file to apply to your database.
      • 54. Let's watch this command, understand the output and look at the script.
  • 55. DBDeploy : The Output dbdeploy 3.0M2 Reading change scripts from directory /home/mwillbanks/presentations/zendcon-uncon-2009-db-deployments/bin/dbdeploy/example... Changes currently applied to database: (none) Scripts available: 1, 2 To be applied: 1, 2
  • 56. DBDeploy : Questions?
    • Any questions on DBDeploy, how it works and anything I may have missed before we go on?
  • 57. LiquiBase : liquibase.org
    • Java based solution - #port anyone?
    • 58. Utilizes XML Files for Changesets
    • 59. Handles undo within the changeset.
    • 60. Utilizes a single table with a primary key on the id, author and filename.
    • 61. Queries the database for what has not been applied and applies the different SQL.
    • 62. Very well documented unlike DBDeploy.
  • 63. LiquiBase : Getting Started
    • Install Java 1.5+
    • 64. Download LiquiBase (Obvious)
    • 65. Download your Java Connector
    • 66. We will be using the command line version
      • This command line version is full featured.
  • 67. LiquiBase : Initial Setup
    • Put the Java Connector somewhere that you can reference it (usually in the lib folder)
    • 68. That's pretty much all you need initially, besides extracting the tar ball :)
  • 69. LiquiBase : The Command Line
    • ./liquibase --driver=com.mysql.jdbc.Driver --changeLogFile=../sql/pre-deployment.xml --username=uncon2009 --password=****** --url="jdbc:mysql://localhost/uncon2009_db”
      • Relevant Commands:
        • migrate – applies change sets for migration
        • 70. rollback – to a tag
        • 71. rollbackToDate – rollback to a date
        • 72. generateChangeLog – useful to create the initial version of the change log.
        • 73. changeLogSync – mark all changes as ran.
        • 74. markNextChangeSetRan – mark next change as ran.
  • 75. LiquiBase : Generating a Script
    • Files run in XML files
      • You can include them from a file or keep all changes in a single file.
    • Run the command:
    • 76. ./liquibase --driver=com.mysql.jdbc.Driver --changeLogFile=sql/pre.xml --username=uncon2009 --password=****** --url="jdbc:mysql://localhost/uncon2009_db” generateChangeLog
    • 77. This saves the file to the area specified.
  • 78. LiquiBase : Writing a Change Log <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>   <databaseChangeLog xmlns=&quot;http://www.liquibase.org/xml/ns/dbchangelog/1.6&quot; xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; xsi:schemaLocation=&quot;http://www.liquibase.org/xml/ns/dbchangelog/1.6 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.6.xsd&quot;>   </databaseChangeLog>
    • All change logs must define the XML schema:
    • 79. Each change log starts with changeLog:
    <changeSet id=&quot;1&quot; author=&quot;mike&quot;> <createTable tableName=&quot;uncon2009&quot;> <column name=&quot;id&quot; type=&quot;int&quot;> <constraints primaryKey=&quot;true&quot; nullable=&quot;false&quot;/> </column> </createTable> </changeSet>
  • 80. LiquiBase : The Internals
    • LiquiBase creates tables called:
      • DATABASECHANGELOG – this handles all of the changes, each change has a primary key on id, author and filename.
        • This table also creates an MD5 of each change set, so do not change a changeset unless it has an error and will not run :)
      • DATABASECHANGELOCK – locks to ensure you are not executing the same change sets.
  • 81. LiquiBase : Examples of Migration
    • Running through the pre deployment file.
    • 82. Running through the post deployment file.
  • 83. LiquiBase : Pre-Deployment File
  • 84. LiquiBase : Post-Deployment File
  • 85. Conclusion
    • Use something to manage your database deployments.
      • There are tools, even more than mentioned here.
    • Ensure you can handle pre and post deployments.
      • They are important!
    • Read the manuals of each system
      • There is a bunch of items I didn't cover.
    • Slides will be posted with examples sometime today.
      • Both on my blog and I'll update the joind.in information to reference the presentation.
  • 86. Mike Willbanks Blog: http://blog.digitalstruct.com Twitter : mwillbanks IRC : lubs Talk: http://joind.in/986 Questions?