码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2014-08-31 17:05:31      阅读:206      评论:0      收藏:0      [点我收藏+]

标签:style   blog   http   os   使用   ar   文件   2014   问题   

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

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

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

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

bubuko.com,布布扣

这个方法好处是大家公用一个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中

bubuko.com,布布扣

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

bubuko.com,布布扣

只有release的change list才能被transport。

bubuko.com,布布扣

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

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

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

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

这是使用GIT的情况下的Landscape

bubuko.com,布布扣

 

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

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

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

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

标签:style   blog   http   os   使用   ar   文件   2014   问题   

原文地址:http://www.cnblogs.com/wanghonggang/p/hana_development.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!