terça-feira, 18 de outubro de 2016

Managing your Database with Liquibase and Gradle

One of the major system development problems has always been how and when we will update the database.

When happen some database change in the development environment, always some questions appear:
  • Scripts for DB changes were created?
  • Where to save the DB changes?
  • When should we apply these changes?
  • These changes have already been implemented?
  • How do we track and manage database changes?
  • Who did these changes?

Liquibase is the library that can help address these issues.

Liquibase is an independent library open source database used to track, manage, and apply changes to the database.

Liquibase works better because it understands what the changes are. For example, a database comparison program would simply see the “person” table on integration has a “firstname” and a “lastname” column, but on live, the “person” table has a “name” column. It would report that you need to drop the “name” column and add a “firstname” and a “lastname” column. While this would leave you with the correct schema, you would lose everyone’s name in the process. With Liquibase, you would have a changeset that says “rename ‘name’ to ‘lastname’ and add a ‘firstname’ column” or, even better, “split the name column on a space and place the values in new ‘firstname’ and ‘lastname’ columns, then drop the ‘name’ column.” Knowing why they are different allows changes to production databases without the fear of losing valuable data.

In this post I will show how you can use the powerful tool Liquibase together with Gradle to automate these tasks, from there will be easy to put Liquibase to work with your continuos integration tools.

Some important concepts:

Changelog file

  • Is the file that contains references of all scripts that should be applied to the database in any environment.

ChangeSet Files:

  • Are all the files recorded in a Changelog
  • Changesets files can be written primarily in XML, YAML, JSON, SQL
    •  I chose for this example SQL.

Some Advices:

  • IDs cannot be repeated, otherwise they will not run
  • Scripts should be smalls
  • Should be added script Rollback whenever possible
  • Must be added new scripts on the changelog.xml
  • Everything that was executed is registered on table DATABASECHANGELOG

Sample:

changelog.xml


 001.SAMPLE.sql


 002.SAMPLE.sql

 build.gradle

 I created tasks for every environment I have and where liquibase should run the script.

With Gradle I need only choose a task as it is below:
  • To execute:
    • gradle task dev update
    • gradle task qa update
    • gradle task prod update

 After that you can check in your database, that these scripts 001 and 002 were applied.

On the table DATABASECHANGELOG is possible check some records like these:



This sample above complete in my GitHub 

References:


às Nenhum comentário:

quinta-feira, 13 de outubro de 2016

Library for configuration management from Netflix

Archaius is the Netflix client side configuration library. It is the library used by all of the Netflix OSS components for configuration. 

It is an extension of the Apache Commons Configuration project. It allows updates to configuration by either polling a source for changes or for a source to push changes to the client. Archaius uses Dynamic Property classes as handles to properties.

Some Archaius features: 
  • Dynamic, Typed Properties
  • High throughput and Thread Safe Configuration operations
  • A polling framework that allows obtaining property changes of a Configuration Source
  • A Callback mechanism that gets invoked on effective
  • A JMX MBean that can be accessed via JConsole to inspect and invoke operations on properties
  • Out of the box, Composite Configurations for applications
  • Implementations of dynamic configuration sources for URLs, JDBC and Amazon DynamoDB
  • Scala dynamic property wrappers

In my sample I will show how use Dynamic Properties and how is could be used Archaius with configuration with many environments.



About ArchaiusSandBox class:
  • Set default configuration with property archaius.properties 
  • installConfig is a method that apply config, with polling to each 1 second 
  • In set environment we will get value from "environment" variable, we expected in this case DEV or TEST
  • In the main method, we call the configuration to get "myprop"
    • it is possible put default configuration to property, I defined "NOT FOUND" but is possible put any value.
    • waiting 10 seconds to put new configuration and call again 







Resources folder. There are 3 properties:
  • archaius.properties is the default configuration with  reference to configuration available per environment
  • archaius-dev.properties configuration specific to DEV
  • archaius-test configuration specific to TEST













In runtime is possible change property, to work in this sample, should be added on archaius.properties (within 10 seconds) the property myprop=TEST-VALUE.

After 10 seconds put in main method it should printed the new value.

In this post I used some archaius functionalities, there are many others available. But with these few codes is possible create configuration to many environments with possibility to change in runtime.




References:


às Nenhum comentário: