Continuous delivery and SAP HANA??

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 🙂