华为软件开发云如何实现DevOps落地？
首先给大家梳理下什么是DevOps。
DevOps可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。
2009年DevOps这个新理念出现，是为了应对IT环境中普遍面临的一些挑战。
如图所示，第一个隔阂，存在于商业需求和开发之间，敏捷的出现缩小了这个鸿沟。但是这给运营带来了很多压力。
所以这就诞生了第二个隔阂，存在于开发和运维之间，这就是DevOps理念要解决的问题。
DevOps的核心实践理念统称为CALMS：文化（Culture）、自动化（Automation）、精益（Lean）、度量（Measurement） 、共享（Share）。
DevOps的优势很明显，但是为什么这些年来实际践行的企业却这么少呢？
一、为什么DevOps很好，但是80%的公司很难落地？
我觉得DevOps最大的难点，有以下几方面。
1、文化和理念障碍
DevOps体现了传统孤立团队之间的合作和团队精神，需要一个队伍的专家朝着一个目标工作，就像是一个足球队。
但开发和运维之间就是存在沟通和理解的鸿沟。开发要的是快速实现新功能，不断满足客户的新需求，他们经常不考虑自己写的代码会对运营造成什么影响，运维关心的是稳定压倒一切，希望尽量避免修改功能，从而降低满足非功能性需求的风险。
还有一些管你那也限制了DevOps的成功——InformationWeek的调查显示：“只有45%采用DevOps的技术专业人士表示期望它能提升安全性；32%认为DevOps对安全性没有任何影响；7%认为DevOps将导致IT运行可能更不安全。
这种文化的东西，中间隔着的三八线，不是说打破就能打破的。
2、流程和工具差异
各家公司的流程和工具都是有差异的，有的企业是主干开发、分支release；有的企业是分支开发、分支release……
3、决策层
一线的IT人员认可了DevOps，但是到了决策层，DevOps的落地就更加艰难。
要改变从前传统的开发方式，要付出大量的人力资源和资金，这对于老板来说，是一个需要考虑很久的决定。
正如很多企业采用敏捷开发一样，这需要一个准备，尝试和逐步实施的过程。
所以对于团队leader来说，想实施好DevOps，需要理清现状，统一概念模型，制定阶段性目标，激发团队热情，有效规避风险，循序渐进地将这个先进的理念落地。
二、华为软件开发云如何让DevOps落地？
华为软件开发云是一款轻量级的DevOps工具。作为软件开发云的用户，我有这么几点体会。
华为开发云有项目管理、配置管理、代码检查、编译构建、测试、部署、发布、流水线这几大服务。
从技术层面来看，用了刚才说的这几个服务，就能可视化地创建流水线，本流水线包含多个阶段（stage）；在每个阶段创建多个不同类型的任务（task）。比如代码检查任务、编译构建任务等。
在代码提交后，流水线的相关任务可以实现最大程度地并发，在小时级别自动化实现版本级集成发布，得到版本质量报告，并快速反馈给开发人员，以便进行快速修复，在开发人员修复版本后并再次进行流水线的集成发布。
在紧急状态下，还能实现版本的快速可靠回退。这样一来，版本就能实现每日构建了，项目管理服务提供了敏捷式、社交化的项目管理方式，可与配置管理关联，使得开发团队有效协同，通过看板等各种图表实时掌握项目进度和质量。
我在网上看到一个实际的案例，说是一个智慧城市和软件开发云合作后，产品版本的集成发布由原先的1天缩短为30分钟，整个项目的交付周期缩短到3个月。
和其他家产品的比对，我会在以后的文章中和大家继续分享。
有兴趣的开发者可以关注下这个工具：软件开发云_开发云_研发云_开发者平台-华为企业云服务
DevOps的核心理念是CAMLS，包括：Culture（文化）、Automation（自动化）、Lean（精益）、Measurement（度量）、Share（共享）。DevOps的落地，如果没有工具平台的支撑，基本上就是空中楼阁。所以一个团队是否践行了DevOps研发模式，只要问问他使用的工具就可以知道了。用了一下华为软件开发云DevCloud，觉得是一个良好的开始。随着DevOps的概念越来越受到关注，一些开发者对开展DevOps的困惑也随之而增多。Dev+Ops提出将开发和运维团队的工作紧密结合起来，建立持续交付和持续反馈的闭环，这个思路让人耳目一新，DevOps持续在实践中探索，市场上关于DevOps的文章以及新闻还不能全面解释DevOps的真正含义，甚至于有一些见解是相悖而行。如何开展DevOps，应该做什么，如何做，业内真正形成体系的说明少之又少。
根据【DevOps实践指南】丛书和eWEEK的报告以及StackStormCEO和Nexenta联合创始人Evan Powell的行业信息，我们可以总结出对于DevOps方法理解常见的几大误区：
1、采用DevOps的企业比你想象的要多的多
根据Puppet实验室的2013年DevOps 状况报告，在被调查的企业中，有66%的企业已经在使用或计划采用DevOps的方法。而最先采取DevOps方法的电信行业，有88%的公司正在使用或者计划使用。
2、DevOps将取代敏捷。
DevOps的原则和实践与敏捷方法一致，许多人认为DevOps是自2001年开始的敏捷之旅的合理延续。敏捷通常是DevOps效率的保障，因为它专注于让小团队向客户持续交付高品质的代码。
3、DevOps意味着消除IT运维，即“NoOps”。
许多人错误地的将DevOps解释为完全消除IT运维的智能，然而，这种情况是很少见的。虽然IT运维工作的性质可能会发生改变，但它仍然像以前一样重要。IT运维团队要在软件生命周期的早期就与开发团队开展合作。在代码部署到生产环境后，开发团队也要继续与运维团队合作。
IT运维不只是工单驱动的手动操作，而是能够通过自助服务平台和API来提升开发人员的生产效率，让他们能自助的创建开发环境、测试和部署代码、监控和显示业务运行的状态等。通过这种方式，IT运维人员变得更像是开发人员（或者QA和信息安全人员），融入到了产品开发过程中，而该产品则是开发人员在生产中用来安全快速地测试、部署和运行IT服务的平台。
4、DevOps代码部署比常规方法快30倍
高性能的DevOps组织部署代码经常要比传统组织快30倍（来源：Puppet实验室的2013年DevOps状况报告）
5、不断变化的DevOps环境相对来说更稳定
你可以通过释放Chaos Monkey（一个灾难事件测试）来使你的环境更稳定。灾难恢复计划就和你最后一次成功使用它们一样，末日场景需要不断得测试。
6、DevOps对信息主管们来说是保持关联性的最好机会
由于全部是自动化协助，DevOps的顶级运营人员已经证明其要比传统IT更富有成效。这也是为什么信息技术的工作量迁移到SaaS以及其他地方的原因，远离CIO们的控制和经费预算。然而，企业能够采用DevOps，正是因为他们能够从根本上修复信息技术，即回到CIO中心讨论如何提高企业业务。
7、DevOps只是“基础设施即代码”或自动化。
如果不是像看待代码一样看待你的基础设施，那么并不是在实施DevOps。如果要连续集成（CI）/连续交付（CD）或者持续运营（CO），你必须存储配置代码
8、DevOps仅适用于开源软件。
尽管许多DevOps成功案例发生在使用LAMP（Linux、Apache、MyqSQL、PHP）等构建软件的公司，但实现DevOps与所使用的技术无关。在使用.NET、COBOL和大型汇编语言以及SAP甚至嵌入式系统的那个编写应用程序的公司，DevOps也能取得成功。
真正的DevOps落地，不是单纯靠某个部门，某个人来完成，他们是紧密结合在一起的，同时，运营、开发、运维是不可分割的。DevOps的方法就是把他们的工作紧密结合在一起，提高效率，享受轻松高效的开发方式。
最后推荐DevOps开发平台：脉冲云，简单易用的软件开发DevOps协作平台，享受真正轻松高效的开发方式。
