基于SAPHANA平台的多团队产品研发

工欲善其事必先利其器。要提高多团队的开发效率，而且还是在SAP HANA平台上，建议大家还是本着“慢就是快”的原则，不要急功近利，在没有准备好团队开发的架构时就匆忙开始功能的开发。匆忙功能开发就算了，估计还存在没想清楚做什么，为什么要做上来就开发的团队，那是更要不得。

今天就和大家分享一下在SAP HANA上开发时的一些准备工作的方法。

方法一：基本无代码控制的手工作坊式的开发

利用SAP HANA自身带的HANA Repository, 所有的团队成员在同一个HANA Instance上开发。每个想测试自己的代码有没有问题，必须要先Active他的代码，然后才能查看他开发的结果。

这个方法好处是大家公用一个HANA Instance，对硬件资源要求比较小。

坏处也是显而易见的，1. 代码混乱不堪，最终除了能在这个HANA Instance运行起来，基本没有办法部署到别HANA Instance上。2. 基本上无法做代码审查。

特别是在有团队成员不遵守代码开发规则，随心所欲的去开发，那这个项目就准备去死吧。因为大家都在一个Instance上开发，有些active生成出来的表。后来其他团队成员把源文件移动到其他package下重新active，而原来生成的表还在这个Instance上。别人的代码中引用这个表，在这个开发的Instance你怎么运行都没有问题，但是你想把你的代码部署别的环境那就是遍地问题咯。查找修复问题是痛苦的。如果这个项目前期持续集成没做起来的话，兄弟你可以考虑收拾收拾走人了。

这种模式下，所有开发人员必须遵守游戏规则，不然基本就是死路一条，No zuo no die。

方法二：启用SAP HANA的change recording的功能

每次修改代码，active时都会要求把代码改动放到一个change list中

每个change list都可以添加contributor。每个contributor都approved这个change list，最终才能release change

只有release的change list才能被transport。

这个方法看起来很不错了。基本上有代码的版本控制，代码审查。似乎蛮完美的。的确普通小项目这样做做没问题。

问题在于你是一个多团队的产品开发，你得调和大家的口味。项目的UI部分它和HANA本身关系比较小，很多时候UI团队的人会使用其他的SCM工具比如GIT、P4、SVN等。这时候你想部署环境做个build出来怎么办？先去帮UI的build的一下，然后帮UI的部分部署到开发机上，接着在开发机到处delivery unit。

因为你的产品代码在两个完全不同的repository上，所以你的产品打包将会让你“爽死”。

方法三：使用市面上成熟SCM，比如使用GIT来做SCM

这是使用GIT的情况下的Landscape

这种情况下，又有两种办法去实现。

1. 每个开发人员一个HANA Instance，所有冲突问题全解决。Pull、push代码，清理自己instance的环境，重新active自己项目，自己的新开发环境就完全好了。
2. 利用regi maven的插件，使rootpackage可配置化，这样就可以使用一个HANA Instance。

以上的实现都是基于本地的HANA Instance，不是HANA Cloud。

基于SAP HANA平台的多团队产品研发