在2015年6月，Gartner预测，“到2017年底，手机APP开发服务的市场需求将比内部IT组织提供的能力要快至少五倍。”事实上，企业已经看到他们的app工作量飙升。因此，更多的组织采用DevOps - 一种通过让app开发人员和运维专家在端到端的应用程序开发和部署过程中进行协作来加快应用程序开发和交付的方法。这里有在组织中得到认可的10个DevOps“***实践”。
1. 打破IT中的壁垒
打破IT职能间的功能壁垒必须来自上级管理层，因为IT已经被组织成职能竖井几十年了。在这种环境下，应用程序开发工作历来是采用装配线方法(瀑布流模式)，其中一个部门构建app，然后将应用程序发送到运维组集成，接着app由QA组进行测试，之后该app回到运维组部署。
这种功能分离限制了协作，带来了延迟部署应用程序的问题。为了更快地交付今天的app，IT经理已经开始将IT重组为DevOps团队，这些团队是所有IT方法论的组合，每个团队都会对特定类别的app负责。
2. 调整绩效评估
当IT文化需要“脱轨”时，通过团队绩效和个人参与的团队绩效评估，可以大步走进这个过程。为开发人员和运营人员提供更多的绩效评估，使他们的团队能够满足app开发和部署目标。
3. 构建项目的实时可见性
当前项目管理软件现在已经具有内置的自动化功能，可以减轻项目更新的麻烦。项目管理工具可以提供对应用程序的实时可见性，以及提供开发部署过程中的准确位置。它还可以显示当前任务的人员和任务关键资源(看板)。项目管理软件可以作为跨职能IT团队的“单一版本”(对所有可见，统一理解)，使项目协调工作变得更加容易。
4. 随时随地使用软件自动化
您可以通过选择与IT环境兼容的应用程序自动化工具集来缩短时间，错误和成本。这种自动化可以扩展到应用程序源代码开发，系统和中间件配置，甚至数据库和网络更改。在部署前的重要的类生产测试，如回归测试和负载测试也可以自动化。这样可以节省开发人员和运维人员的时间和精力。
5. 选择相互兼容的工具
DevOps使用工具和自动化的另一个注意事项是工具在应用程序和系统两个级别上产生的状态信息不会冲突。从单一供应商选择工具通常更为有效，因为这些工具已经彼此紧密集成。这样可以改善app开发人员在应用程序的健康状况下收到的状态，与运维人员在其app中看到的内容一致。
6. 从小而成功的项目开始
CIO希望IT文化脱离壁垒，就需要确保新整合的DevOps工作团队能够取得一些快速的成功。这样会建立了他们对新方法的信念和合作。切忌贪大求全，需要有单点突破的能力，甚至说构建完整的持续交付流水线都是错误的。这个地方的方法是整体设计，分块构建，对于每个角色来说以高频交互场景为优先切入点。
7. 别忘了用户!
您正在开发的应用程序是最终业务。没有业务利益相关者的关键支持，您的DevOps工作将会面临失败。从您坐下来与他们定义应用程序需求的那一刻，原型开发，单元测试集成/回归测试，培训和部署整个DevOps进程都要包含最终用户。这种包含是以用户的价值为依归，从用户的角度出发，考虑其在业务连续性、可用性、用户体验、满意度等多方面的要求。今天看来，让用户参与设计，是一种detailed 设计方式，可以借助一些轻量级的技术手段，比如说A/B测试来减轻和加速这个过程。
8. 协同管理变更
当多方合作开展快速发展的开发工作时，其中涉及原型设计和其他工具，app的更改即将发生。这就是为什么一个有效的变更管理过程对每个DevOps项目至关重要。当app需要更改的那一刻，这个请求应该面向团队中的每个人，无论他们工作在哪个IT环节上。这种沟通也应该指向最终用户利益相关者。分布式研发管理模式下，工具非常重要，采用一个分布式管理工具、自动化构建和测试工具都是为了提高协同的效率。
9. 持续部署应用程序
DevOps在持续应用部署模式中最有效，其中网站不要等待将各种增强功能捆绑到独立的软件版本中，而是选择不断修改和交付修订的应用程序(基于MVP，增量迭代式的开发模式)。一个具有强大变更管理系统的app持续交付模式使得新的app功能更快速的交付业务。变更管理平台需要有灰度发布、A/B测试的能力，而不是更多的靠人为来保证。
10. 在公司内创建一个服务环境
IT温室时代已经结束了。 为了做好面向业务的交付，IT部门必须牢记业务用户需求，并交付满足或超过功能和上市时间预期的app。 如果改变文化可以强调团队精神的价值，开放式沟通和客户满意度的承诺，即使客户驻留在相邻的办公室也可以这样做。总而言之，要把自己的服务意识放在离客户最近的地方。
【本文是51CTO专栏作者“王津银”的原创稿件，转载请注明出处】
