应用SAP HANA “官方”开发模式的伙伴们在转到“多团队大规模”开发模式时会遇到各式各样的心理不适应的状况，各种纠结。比如GIT Repository和HANA Repository冲突什么的。

这些问题主要是思路没有完全转换过来，两种开发模式在不断的“打架”。做一个简单的开发模式映射这样大家或许比较容易去接受“多团队大规模”的开发模式。这个映射不一定完全正确，主要是帮助大家理解。

伙伴们想一想平常我们做JAVA或者.NET项目是怎么做的？一般情况是使用各种框架写JAVA/.NET的代码，然后用ORM映射数据库。写SQL Query时基本上都是在SQL里面去写，去测试然后拼接到自己的JAVA/.NET代码中。

 + 

那么我们在SAP HANA平台上开发同样可以学习这样的模式，当然这种模式可能比“官方”模式厚重点，但是好处也是显而易见的，比如前文提到的那些好处。前后端的开发都可以在Eclipse中，HANA Studio的作用完全等同拼写检查SQL Query等SQL层面的工作。这样我们在开发过程中就可以应用很多手段，方便的传递参数。比如替换rootpackage，通过maven的插件就很容易的可以做到。这样HANA Instance就扮演了一个编译器的作用。前端的代码编译好之后，和后端代码整合到一起Activate到HANA Repository中，这时的Activate就像是compile一样。Maven的插件，或者Ant的脚本把Activate这些HANA特有的动作都封装起来，开发人员完全还是遵循着传统多团队大规模开发的模式——写代码，编译，调试等。

 + 

由于Maven涉及到公司内部提供的插件，没有开源。所以就提供一个Ant的脚本以饷读者。

         
      
       Regi wrapper
           
          
          
          
          
          
              
               
               
                   
                    
                    
                    
                      
                     
                
           
          
              
               
               
               
                   
                    
                    
                    
                      
                       
                     
                
           
          
            
             
           
            
              
               
            
             
              
              
               
                   
                    
                    
                    
                    
                      
                     
                
           
          
              
               
               
               
               
                           
                    
                
           
          
              
               
               
                   
        
         regi track @{package}
                    
                    
                
           
          
              
               
                   
                    
                
           
          
              
               
               
                   
                
           
          
              
               
                   
                    
                    
                
           
          
              
               
                   
                
           
              
              
               
                   
        
         regi checkout trackedPackages --force
                    
        
         workspacedir=@{workspacedir}
                    
                    
                
           
          
              
               
               
                   
        
         regi delete packages @{packages}
                    
        
         workspacedir=@{workspacedir}