Technical Articles
HANA XSA Simplified 3: Using GIT as a central repository in WebIDE and Deploy Process
I am back with my next blog post in this series of HANA XSA Simplified. In this blog post; I will explain mainly on 2 process related to WebIDE and GIT. 1st is how can developers in same project share objects among them and 2nd is accessing the objects which are already deployed on Quality Assurance (QA) and Production (Prod) system.
You can follow the below links to visit the earlier blog posts in this series.
HANA XSA Simplified 1: HANA XSA Implementation Methodology for different customer scenarios
HANA XSA Simplified 2: HANA XS classic and XS Advance comparison and migration from XSC to XSA
HANA XSA Simplified 4: SAP HANA Database Authorization provisioning for HDI Container roles
HANA XSA Simplified 5: Deployment options for XS Advance MTA projects
In HANA XS advance, we use WebIDE for development. WebIDE is a web-based development tool for all the native HANA developments in XSA. To know more about the WebIDE please refer the below link.
HANA XSA do not have inbuilt central repository like HANA XS classic. WebIDE is personal for every developer for example: Developer 1 and developer 2 are working in the same project but Developer 1 cannot see what Developer 2 has built in his WebIDE and vice-versa. They cannot use each other’s objects in their developments. In projects with large number of developers this can be a very difficult situation to handle as there is always a dependency of objects developed by different developers.
To handle this situation in XS advance, we use Git as a central repository for sharing the objects within the project team. Developers who are already working in some other open source technologies might be already aware of how to use the Git but developers who has only worked in SAP technologies might not be aware of it. You can find more the details about how to integrate/setup the Git for WebIDE and different options available in Git at below link.
WebIDE is only used for the development of different artifacts. It is only connected with Development Space. Once you deploy your .mtar files to QA or Prod system there are only few ways to see what is deployed on the QA or Prod Space.
1st way is to find out which .mtar file was deployed on the QA or Prod Space; download that file to local desktop and then unzip the .mtar file. In this file you can find all the artifacts which were deployed to target space. Import the artifacts to your WebIDE to fix the error and then again deploy them with new .mtar file. In this case, you must preserve the .mtar files for longer period.
2nd way is by using the GIT repository. I have described the process below in details.
In this example, I am considering 2 developers DEV_1 and DEV_2 working on the same project. DEV_1 is also a lead developer who has authorization to deploy the .mtar file to QA and Prod systems.
- DEV_1 has developed a Table_1 in his local branch DEV_1 in his WebIDE; and then pushed it to his remote branch DEV_1 in GIT.
- Similarly; DEV_2 has also developed a Table_2 in his local branch DEV_2 in his WebIDE; and then pushed it to his remote branch DEV_2 in GIT.
- Both developers have merged their remote branches DEV_1 and DEV_2 in master branch of GIT. Now both the objects Table_1 and Table_2 are available in master branch.
- Now when DEV_1, performs the Pull or Fetch and Rebase from the master then DEV_1 can see both Table_1 and Table_2 in his WebIDE.
- Similarly; when DEV_2, performs the Pull or Fetch and Rebase from the master then DEV_2 can also see both Table_1 and Table_2 in his WebIDE. This how DEV_1 and DEV_2 can use the objects developed by each other.
- DEV_1 has completed his development of Table_1 and it is ready to deploy to QA and PROD but Table_2 is still under the development which is worked by DEV_2. DEV_1 is also a lead developer who has authorization to deploy these tables to QA and Prod. DEV_1 creates a remote branch QA_BRANCH in GIT as well as local branch in his WebIDE (Need to be created only first time). He pulls the changes from GIT master branch into QA_BRANCH (Local branch in WebIDE). He deletes the Table_2 from the local QA_BRANCH and builds the project to generate the .mtar file with only Table_1.
- Then DEV_1 pushes the changes to QA_BRANCH (Remote branch in GIT); so that if required it can be accessed anytime in future.
- DEV_1 deploys the .mtar file to QA space (Git is not used for the deployment of .mtar files. There are multiple ways to do the deployment which I will cover in another blog post).
- DEV_1 creates a remote branch PROD_BRANCH in GIT as well as local branch in his WebIDE (Need to be created only first time). He pulls the changes from GIT QA_BRANCH branch into PROD_BRANCH (Local branch in WebIDE).
- Then DEV_1 pushes the changes to PROD_BRANCH (Remote branch in GIT). I have suggested this step again because there might be multiple iteration of deployment to QA and all the QA deployment will not be deployed to PROD.
- DEV_1 uses the same .mtar file which is already deployed to QA space to deploy it to PROD space.
- In future, whenever there is any issue reported in production then objects can be easily pulled from PROD_BRANCH into developer branch and fix them. Again, follow the same steps so that it can be again referred in future.
Hope this blog post will help you to setup the process with Git and WebIDE to share the artifacts within your project and maintain the QA and PROD versions in Git.
Can you help in finding some documentation exporting HDI Role from XSA to XSC database? How could we achieve it?
Hi Sathiyaraj Jagadesh,
I did not understand your question completely. Please could you elaborate it more. I have another blog post https://blogs.sap.com/2020/07/27/hana-xsa-simplified-4-sap-hana-database-authorization-provisioning-for-hdi-container-roles/ where you can find Best practices and recommendation for HANA XSA authorizations document at the end. This document might help you to solve your question. Please provide some more information if this blog do not solve you problem.
Best Regards,
Vivek Chaudhari.
Hello Vivek - I am interested to develop database admin roles in central XSA system and use the same roles for multiple HANA systems which doesn't have XSA infrastructure installed.
In your blog, 1st step of deploying mtar file into QA and Prod systems, How do we deploy the MTAR if we dont have xsa installed in QA and Prod systems?
Hi Sathiyaraj Jagadesh
You can create admin roles by adding the system privileges in XSA roles. But if you want to develop database admin roles and you have to use it for non XSA systems also then develop it with Repository role. You can extend these repository roles with XSA roles also for HANA XSA systems.
Vivek, Great article and very useful, thanks for sharing.
Thanks GARY BOYD.
thanks
Hi Joshua,
I did not understand what are you exactly refer as a 'Space'. For now I will consider space which we create under the organization in XSA cockpit. It is not good practice to have separate spaces for each developer. Good practice is to have have a single space for one project and then multiple developers are working in that project. Developers are using push and pull from the Git repository to have all the development in sync. If all the developers are working in different spaces and projects then it will be difficult to get the dependent object in one single project. I hope this answer your question. If not please elaborate more on your question.