Handling Database Deployments


Published on

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
1 Comment
  • 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  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Handling Database Deployments

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

    Clipping is a handy way to collect important slides you want to go back to later.