Transporting content developed in SAP HANA Studio is well documented and works like a charm: you
- create a delivery unit
- assign the desired package(s) to it
- use the Studio's Import/Export feature to transport it from A to B.
Wonderful.
The issue we had in our project with this? It's a manual process.
In the day and age of continuous delivery, we needed some kind of tool to script this process, thus being able to integrate it into our build automation and deployment.
Enter regi.
regi is a command line tool for accessing the HANA repository. It is shipped not only as part of the SAP HANA installation itself but also as part of of the SAP HANA Client, which allows it to be installed onto our Atlassian Bamboo® build agent.
Process flow
During our build, all objects of our main development package wap (short for "Web Analytics Platform") and sub-packages thereof are extracted from our HANA DEV system and pushed to a github repository.
In systems further up the chain (i.e. TEST, QA and PRD) we then first clean the proverbial slate by emptying the HANA repository, upon which the development objects are pulled from the github repo, committed to the HANA repo and finally activated.
In slighlty more detail
Certain prerequisites need to be in place before one can work with the HANA repository using regi:
- an entry (also called key) in the secure user store
- a so-called workspace on the filesystem
The key is created using the tool hdbuserstore, which is also shipped as part of the SAP HANA Client and allows for creating, viewing and deleting sets of logon data (i.e. hostname, port, user and password). See the SAP HANA Security Guide for more information.
Once this has been created, it is used to create a workspace in the filesystem:
regi create workspace myWorkspace --key=myKey
Having changed to the workspace directory in the filesystem of the source system, we now check out the currently active development objects from the HANA repository using
regi track wap
regi checkout
As a result, an XML representation of each development object in this package (or sub-package) will have been created in the workspace, whereby the package structure is mirrored in sub-directories.
These files are now copied to a (previously cloned) github repository using rsync. We use this nifty tool instead of a standard file copy, because one of its many options allows for deleting "extraneous files from the receiving side". In other words, this helps ensure that any development objects deleted in the HANA repository are also deleted in the git repo.
Finally, any changes are pushed back to github.
In the target system, we first also create a key in the secure user store and a workspace. All the following commands are performed in the workspace directory.
Initially, we clear the HANA repository. This is done by checking out the development objects to filesystem, deleting them there, and - lastly - committing and activating this deletion:
regi track wap
regi checkout
rm -rf ./wap
regi commit
regi activate
Though the HANA repository now does not contain any more development objects per se, it will still contain the empty package structure. Unfortunately, regi is not able to delete the parent package if it contains sub-packages - regardless whether they are all empty. But with a for loop at a shell prompt, this too can be solved:
for pkg in `regi list packages | grep wap | sort -r`; do regi delete package $pkg; done
Now the HANA repository is really empty.
What remains to be done is to now copy the development objects pulled from github and committing/activating them to the HANA repository.
In the workspace directory, the following commands need to be issued:
cp -R <local_git_repo>/wap .
regi commit
regi activate
That's it, the target system now contains all development objects from the DEV system. On a TEST system one could now take it a step further and run some automated tests, but that's a topic for a future article.
Happy delivering continuously :smile:
