Conception and Realization of the Versioning of Databases between Two Research Institutes S. Mueller, R. Mueller GSI, Darmstadt, Germany

Requirements CERN GSI Results Abstract Java-Code-Migration G G This paper describes the version control of oracle databases across dif- Separate Database G G Because of the desire for ”cherry-picking” and the versioning of ferent environments. The basis of this paper is the collaboration bet- Traceability G G two databases in one, both tools reach their limits. is ween the GSI Helmholtz Centre for Heavy Ion Research (GSI) and the Repeatable Jobs G G European Organization for Nuclear Research (CERN). in this case better, it gains flexibility and has more advantages The goal is to provide a sufficient and practical concept to improve Existing Database G through the XML-configuration approach than Flyway. database synchronization and version control for a specific database Expandability G G

landscape for the two research facilities. Open source G G First, the relevant requirements for both research facilities were identi- Flyway: Existing Environment G G fied and compared, leading to the creation of a shared catalog of requi- rements. In the process database tools, such as Liquibase and Flyway, Cherry-picking G  Can’t handle two databases with one config file were used and integrated as prototypes into the Oracle system lands- Data import G G  Can better handle PL/SQL and SQL in only one file cape. During the implementation of prototypes several issues were identi- Requirements of each institutes  Can delete the whole fied, which arise out of the established situation of two collaborating  Circular dependencies departments of the research facilities. Requirements on the prototype were, to be flexible enough to adapt to the given conditions of the da- Evaluation Liquibase: tabase landscape and easy integration without too many changes into the existing development environment.  More manageable through XML The creation of a flexible and adjustable system enables the two re- After collecting the requirements , the next step was to select  Can handle C4O and FESA or LSA at once search facilities to use, synchronize and update the shared database tools which will fit theoretically. As it had to be an open source landscape.  Has problems parsing PL/SQL and SQL files in one step tool, there are two popular migration tools on the market - Flyway and Liquibase. Each of these tools fits theoretically to the  Can only delete general database objects requirements catalog. For a better exclusion process, an  Different ways to setup various database environment was created, which is similar to the production  Circular dependencies Current Status environments of both departments. The goal was to simulate  Commons 4 Oracle (C4O) the database landscape of both institutes, to be able to test the G Collaboration between two institutes - CERN and GSI chosen migration tools in an environment close to the Requirements Flyway Liquibase   G The applied frameworks - FESA and LSA real-world. Java-Migration Separate Database   G Frameworks have dependencies on each other Traceability   G Software is versioned, database is not versioned Flyway - Advantages: Repeatable Jobs     G Lightweight - no config file is needed Existing Database Expandability   G K.I.S.S - principle Open source and free   G Continuous delivery Cherry-picking   G More compatible with Oracle database than Liquibase Data import   Liquibase - Advantages: PL/SQL and SQL   Oracle compatible   G XML based C4O and Databases   Initial situation between the two institutes G Convert the XML to SQL during run-time Requirements of each institutes G Continuous delivery

G Expandable by plug-ins

G Liquibase has a few more articles on Stackoverflow than Current Status - Outlook Procedure Flyway Example of a file for Flyway At the moment GSI uses Liquibase for the database migration. V00_01_00010__INSTALL_COMMONS_BASIC. CERN is in the phase of testing Liquibase. Since GSI was starting First, a requirements catalog of the two institutes was created V00_01_00020__INSTALL_LSA_TABLES.sql with an empty database from scratch they did not have to care and taken as basis for the choice of the best method to V00_01_00030__INSTALL_LSA_VIEWS.sql about the content, so CERN is investigating at the moment how collaborate and later on for evaluation of a suitable tool. The to handle the existing content and looking into baselining its second step was to make a model of each possible method and Example of including a config file in Liquibase database. test these models in a simulation environment. This approach helped to discover possible issues, which, based on the concept only, could not be detected. CERN: Example of an XML config file from Liquibase G Evaluating Liquibase G Asking each institute for the requirements [...] GSI: G Generate and evaluating the requirements catalog The procedure’clone_trims_settings’ was lacking the possibility to clone settings for G Using Liquibase function arrays G Changing existing database more and more to Liquibase

G Java-Code-Migration - For running Java code during the migration Change Email-Server

G Separate Database - To generate a database from the G Traceability - Traceability of the code migration

G Repeatable Jobs - Repeatable code migration Update Commons 1.15 to 1.16 G Existing Database - Setup the migration tool on a existing

G Expandability - Expandability of the migration tool via plug-ins [...]

G Open source - Open source and no cost [...] Overview of the migration, which are implemented at GSI G Existing Environment - Included in the existing environment

G Cherry picking - Selection of the changes

G Data import - Import static data

presented at ICALEPCS 2017