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

工欲善其事必先利其器。要提高多团队的开发效率,而且还是在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。

posted @ 2014-08-31 16:38  王洪刚  阅读(1193)  评论(0编辑  收藏