SAP成立于1972年，总部位于德国，“是全球最大的业务软件公司”。根据百度百科，SAP是世界第三大独立软件供应商，是全球第二大云公司。全球有120多个国家超过17万的用户正在运行SAP软件。SAP是公认的企业服务软件”重型武器”之最，在云计算的浪潮之下，也在积极进行业务变革和技术转型。如果有些企业觉得自身产品和业务太过复杂，不适合微服务架构和DevOps管理模式，相信本文可以帮您树立转型的信心。
隆重介绍本文作者，也是庐透社第一位专稿撰写人：Akira。就职于北美SAP，担任DigitalBusinessServices部门的SolutionArchitect，主要服务于Nike、UnderArmour、L’Oréal等国际零售客户。在SAP工作的十年中，亲历了SAP产品从BusinessSuite到HANA再到SAPcloudplatform的转型，所处的研发团队也从瀑布式交付模式逐步向DevOps和MicroServices模式。
一、SAP传统BusinessSuit的DevOps
SAP传统的ECC或BusinessSuite长期以来都是使用着开发、测试、环境多组分开工作分开职能的结构。主要是由于源代码编辑一般在server端，一个对象同时只能有一个active的version用以执行/测试。一般都是在整个版本开发结束，多个相关对象被激活后，共同测试。
近年来，SAP基于ABAP的传统BusinessSuite也越来越多的吸收了Agile的概念，以使得开发周期更快，开发团队协作更灵活。工具方面，SAP的SolutionManager系统中提供的多种工具CHARM(ChangeRequestManagement)和自动化模块测试工具等，这些都为基于ABAP的开发合并及测试提供了强大的支持，使得SAP的开发顺利从Waterfall切换到Agile模式。方便管理Release->Wave->Sprint作为单位的featurelist。与以前相比，感觉featurelist管理的更好，Feature与团队之间相互影响变小，各个scrum团队的进度也很快。
但个人感觉传统Suite在DevOps方面还是有些不可避免的挑战：
SAP系统一般都是作为企业的Backbonesystem，稳定性至关重要。多年来在客户方面也是开发、测试、运维一贯都是多个不同的部门。有的管理层喜欢运维与开发之间的角力以保证最稳定对业务最优的结果。
SAP的BusinessSuite比较难以封装成Micro-service的形式。
需求相对没有这么高：
ReleaseStrategy：SAP的主要BusinessSuite的Release周期一般还是3个月（Cloud）到六个月（OnPremise）。每次Release都是features一起。即使对于周期较短的CloudVersion也不怎么需要以micro-service的形式发布。对于企业级用户，每次的features发布到被业务应用，一般在客户内部也都是统一培训。
对应的代码段一般是由不同产品组精细管理，需要同时重叠改动的机会非常之少。
即使有很急切的改动（如hotfix），一般也是以pilotnote的方法给出，在一两个客户中确认成功，再以一般note形式供所有客户下载安装。
如何得到测试结果：Acentralrepositoryforartifacts--Nexus(Java)
如何保证Build对各组可见：开发人员的问题--我的代码怎么样了？被合并了没？需要changereviewtool(如Gerrit)，需要buildscheduler(如Jenkins)。
如何自动部署：一般CI/CD不要求在生产环境自动部署，但是要求自动validate以尽可能保证部署改动的质量。
二、SAPCloudPlatform上的DevOps
1.流程与工具：
先来看看SAPSCP(SAPCloudPlatform)上应用部署官方推荐的CI和CD的流程图。Bestpractice基本和市场上的都差不多，运用一些通用DevOps的工具。
对于多组共同开发，目前无法做到完全的自动整合(除非假设多组改动的代码完全是不同的部分，并使用optimisticmerge)。以下是比较经典的多组共同开发的示意图-在开发时间和代码部分有重叠的情况：从mainline的源代码分支修改的build成型后，将被设为voterbuild(也称为pendinghead，可以用来测试和保证改动代码的质量），其代码称为proposal。先merge的proposal进入mainline源代码，对应的build为CIBuild。这部分源代码与另一组的proposal手动合并，成为新的voterbuild。
其中的关键是build和test能够足够快，以此来保证mainline源代码的及时性和正确性。因此，Build和test的自动化至关重要。
同样重要的是这些build的测试环境。有时候不同的测试环境造成测试结果的很大出入，并需要很多人力去找出原因并解决。所以一般建议以管理代码的方式来管理环境的搭建和配置。任何安装在环境中的软件以sourcefile形式存在，并可随时重建。常用工具包括：Chef,Puppet,Salt,Ansible等。在此之上的配置以脚本形式实现。软件的安装则一般使用镜像container，比如Docker等。
2.组织结构：
SAPCloud产品里面的DevOps一般属于研发部门的Platform。基本上Dev和Ops还是的两个大组，中间安排有DevOps把两边串起来。在研发部门内部，会根据任务组建基于sprint的DevOps打散的virtualteam的形式。但是相对来说都是研发一个大组下面的，所以人员都相对比较稳定比较熟悉。感觉还是挺合适的。（很多人倡导Dev和Ops完全融合，个人感觉还是很难实现，特别是产品featurelist多和平台体量大的情况，两个团队还是会有自己的侧重点。）
最重要最核心的一到两个人DevOpsLead来把整个产品的开发、测试、部署运维、流程自动化都串起来，需要懂得多，级别也高。他们下面一般都有几个的资深DevOpsEngineer，设计部署运维测试工具都要管，需支持SAPcertify并使用的某个平台（如AWS,GCP,AZ等），部署自动测试和自动环境搭建的工具等。DevOpsLead和资深DevOps比较难招，要什么都懂自己也有设计开发经验的通才，还要能crossteamfunctioning。因此很多时候我们还是看到dev是dev的管理，自动化是自动化团队管理，测试是测试团队，尤其是大的团队。这样的virtualteam组成起来，没有一个好的人串起来的话，推进是会很困难，一般都是PM或者TPM自己管。
在此之外Ops下面有一些DevOpsEngineer组成的一个pool，其实我感觉就是OpsEngineer，他们与研发的关系相对没有这么紧密，工作内容类似于一般的Basis/Infrastructure管理，确保平台运维。
与传统系统相比，过去SAP传统的Suite研发绝对主导，没有什么Ops的概念，因为客户一般都是OnPremise部署，系统搭建和运维都是客户自己的basis团队或者第三方。SAP有也就是在offshore设一个团队提供支持，主要的安装配置权限管理一百样都是研发团队的人自己弄，弄好了以后交给offshore支持一下（升级维护之类），有问题或需求就报报requestticket。随着SAP的云转型以及S4/HANA的云部署，Ops这方面越来越重要，这些系统的downtime也要最小化，DevOps的重要性也就凸显出来。
公司云转型中DevOps至关重要，现在感觉基于Java的（successfactors、concur）和基于Abap的（S4HANA、BW4HANA…）对于DevOps的应用差别还是比较大。在基于Abap这块最大的问题还是难Micro-service，以及已有的资深专家对于DevOps的技能和mindset的适应，将是一项重要而赋有挑战的任务。
庐透社论：
SAP碰到的问题，我们都碰到了，相信各位也都碰到过。并且，看起来大家的解决思路都类似；
敏捷流畅的CI/CD流是解决问题的不二法门，大家可以出门左转，看庐透社对微软DevOps的专访。
如果你公司有不错的DevOpsLead，请一定好好珍惜爱护，这种人像熊猫一样珍贵。再次感谢Akira，你为庐透社读者开了个好头:)
