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. 1^st is how can developers in same project share objects among them and 2^nd 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.

https://help.sap.com/viewer/400066065a1b46cf91df0ab436404ddc/2.0.05/en-US/254fe0b0470749949cbda0e6150e8714.html

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.

https://help.sap.com/viewer/825270ffffe74d9f988a0f0066ad59f0/CF/en-US/4eddb4cfc29946f6b059306cbdfcb392.html

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.

1^st 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.

2^nd 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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. Then DEV_1 pushes the changes to QA_BRANCH (Remote branch in GIT); so that if required it can be accessed anytime in future.
8. 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).
9. 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).
10. 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.
11. DEV_1 uses the same .mtar file which is already deployed to QA space to deploy it to PROD space.
12. 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.