(Git) Versioncontrol of Board-Database-Schema

Nico Gerbrand

Problem to solve

Currently, it is a difficult task to carefully document a database schema. Often this task is postponed until later or is completely forgotten. Even if there is documentation, it is often not available centrally in one place for all project participants, but distributed in different places with different versions. It is therefore desirable to have living documentation and version control, as is common in software development.

 

Target

Managing the database schema in a remote repository, such as Github, Azure Repos, Gitlab or similar.

 

Implementation

To enable the user to work, it is necessary to store the database schema in a human-readable format. XML, JSON or similar would be suitable for this.

 

The database schema includes:

• Entities
• hierarchies
• Data cubes
• DataReader
• Rules
• Procedures
• API queries

 

The list is not exhaustive and can be extended by further elements.

 

Only meta-information is stored in the Git repository. It explicitly does not store content such as entity elements or transaction data of data cubes.

 

Example of meta-information for entities:

 

• Name
• Code Width
• Description width
• Physical name
• Group
• Max Item Number
• Sorting
• Item Display
• Allow in user view
• Is RollUp Entity
• Unbalanced Hierarchy

 

This list is also not exhaustive and can be extended to include other elements. In simple terms, all information in the Git repository that is used by the board transport tool should be taken into account.

The configuration should be possible for OnPremise customers in the server configuration and for Cloud customers in the Admin Portal. Capturing commit messages, displaying the commit history, creating branches and merging branches is done in the board interface.

 
It should also possible connect transport-tool to Git-Repository. 

Benefits

• Tools and procedures known from software development
• Lively and always up-to-date documentation of the database schema
• Faster troubleshooting possible, because it is always known 
  • Who originally developed something
  • who made changes
  • When changes were made
  • What changes were made
• Implementation of customer requirements can be linked to code and substantiated. The prerequisite for this is the capture of requirements in the appropriate tools such as Github, Azure DevOps, Gitlab and similar.
• The strategy of providing standard apps for customers is supported.
  • Apps are versioned
  • Deviations from the standard can be analysed more quickly
• Developers can develop in parallel in different branches without interfering with each other

Monisha Jain

Thank you for sharing your idea, Nico. We understand the need of this solution.

We are aiming to release the Phase 1 of our ALM in the Summer release of 2023. Our goal is to have something in the platform that will facilitate all the steps we have described in the presentation attached.

ALM.pdf

We encourage you to continue submitting your ideas and suggestions in the future, as we are always open to hearing new perspectives and feedback.