标签：style blog http os 使用 ar 文件 2014 问题
工欲善其事必先利其器。要提高多团队的开发效率，而且还是在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。
每次修改代码，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上，所以你的产品打包将会让你“爽死”。
这是使用GIT的情况下的Landscape
这种情况下，又有两种办法去实现。
以上的实现都是基于本地的HANA Instance，不是HANA Cloud。
标签：style blog http os 使用 ar 文件 2014 问题
原文地址：http://www.cnblogs.com/wanghonggang/p/hana_development.html
