应用生命周期管理需要统一的DevOps方法

日期:2013-4-28作者:Jason Tee翻译:蒋红冰来源:TechTarget中国 英文

【TechTarget中国原创】

任何IT项目经理或应用架构师,谁在引人注目的项目上做了大量的投资,谁就感到这是一场恶梦,只能眼睁睁地看着它在生产阶段失败,因此因为非功能性需求,如性能或可扩展性问题。看到的只是,一个开发良好的应用,通过大量的应用生命周期管理(ALM)流程无缝地迁移,最后死去。或者,这个情节会更加地糟糕,实际部署的应用程序无意中暴露了特权数据,且不需要的充分的安全限制。

  随着强大的开发和操作团队一起工作,以一种统一的DevOps方式来进行应用开发、部署和运行时管理,这些问题就可以避免了,而且应用生命周期管理可以很大程度上简化。然而,常常在DevOps应该做什么和日常操作中究竟发生了什么之间存在分歧,这是一个问题。  

最后开发和操作会走到一起吗?

  DevOps是一个嵌合体,创建它是用来解决战略需求问题,以及在软件初期的大量操作需求。它本就应该结合操作和开发这两个不同的派系,所以他们应该共同工作,高效地创建部署更好软件。DevOps在这两个世界中都有它的足迹,它是这两种文件中的连接和共同的理想的位置。从这里,可以定义和创建标准,来集成ITIL(信息技术基础设施库)和CMMI(能力成熟度模型集成)。因为所有人考虑问题的方式都是一样的,试图使用共同的战略来解决问题,所以流程得到了改进。  

太少,太晚

  不幸地,许多IT商店仍然在先开发,再操作。没有统一的DevOps,然后,当组织等到开发流程快结束时,甚至才开始思考性能和安全,这时成本增加了,风险也增加了。

  Don Brancato,Hewlett-Packard公司的企业架构师,他只是说,“当你在产品已经形成后附加入质量和安全的话,成本就会很高。而且还有不能按时上市的风险。当在设计时非功能性问题解决后,那么开发人员可以编写代码来满足那些需求。这样成本的确会少一些。”  

如果进展顺利,是否可以把统一的DevOps变得敏捷?

  但随着不断提升的压力,推动产品越来越快地面市,把操作视图融合到设计阶段,这真的实用吗,尤其对于采用基于敏捷方法进行应用开发和部署的组织?

  Brancato说,对于为什么正确的计划应用减缓敏捷和Scrum的流程,还没有理由。现在已经有大量的关于非功能性需求的信息,团队可以依赖,包括政策、程序、规则和针对每个行业的纵向指导方针。“有一本非功能性需求手册在手,就不会违反任何一条Scrum原则,”他说。我们知道这些东西是存在的。他们是隐蔽的,必须有人来做这项工作,必须在产品发布冲刺前覆盖掉它。

  在计划、开发、或Scrum冲刺或部署阶段,参考一个规则库或行业标准手册,这并不违反Scrum原则。

  一旦统一的DevOps正确完成,这些好处可以极大地量化出来了。通过编写正确的代码,即代码感知到非功能需求,并与其保持一致,这些代码在未来的产品中就可以重复使用。

  “这个过程具有成本效益,” Brancato说。“我期待更好的执行商店,体验35%的代码重用,只代码最初是以安全的方式编写的,”缩减成本、减少开发时间、降低生产后期失败或后期制作风险,并确保产品质量,来满足开发和操作的期望和需求。当所有这些做完,那么组织就知道了它的应用开发人员、运营管理团队和管理ALM流程的人对DevOps做对了工作。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

Ajax 与RIA Web服务>更多

  • 四条原则直通真正敏捷境界

    随着时间的推移,软件团队开发他们自己的敏捷变体。这里告诉你如何使你的实践与敏捷精神相一致。

  • 从Web开发到交付:2015必备深度前端知识

    过去这几十年,互联网已被证明是影响技术世界的最复杂最难以预测的系统之一。软件往往是基于部署在本地硬件(或至少本地网络)上的假设来进行设计的。

  • 移动浏览器到云:JavaScript地位正在扩张

    不难发现人们非常喜欢在前端开发中使用JavaScript。但是,令我们惊讶的是后端开发也如此青睐JavaScript,促进了基于云和基于数据中心的托管应用的发展。

  • 移动HTML5挑战何在?

    当HTML5出现时,许多开发者和应用架构师视之为创建平台独立应用、简化你的设备支持以及当新的移动设备OS版本发布时减少应用相关问题的机会。

相关推荐

  • 你的微服务设计支持可重用并避免冗余吗?

    微服务是代码小型的功能捆绑,旨在通过适当的使用来促进可重用并改善QoE以及可用性。如果使用不恰当的话,它们就会成为应用生命周期管理和资源效率的“噩梦”。

  • 对于orchestration而言 ALM和DevOps至关重要

    为了确保开发和运营能够持续同步演进,开发者需要理解DevOps与orchestration之间的差异,对自己的开发和运营策略进行重新思考,并且对重要的新兴趋势保持警觉。

  • 开发运维一体化(DevOps):协作是成功的保障

    如今的IT部门存在一个矛盾:敏捷开发者希望可以快速部署常规软件,而运维团队则优先考虑稳定性。开发和运维不同的成功指标使得每个团队都有自己独立的目标

  • 中国市场DevOps应用趋势分析

    为了解决开发人员与运维之间的协作问题,从而提升工作效率,DevOps方法论应运而生。几年的发展,DevOps现在国内市场的应用情况如何?如何才能取得DevOps实施的成功?

技术手册>更多

  • 敏捷开发技巧指南

    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。关于瀑布方法和敏捷方法的分析已经探讨过多次,但瀑布方法在某些项目和开发团队中还存在价值。《敏捷宣言》声明指出,个人和交互高于流程和工具。由于开发项目的利益攸关者已经变得越来越分散,遍布在全球各地,甚至经常横跨了几个时区,基于云的开发环境已成为必备之选而非锦上添花。TT SOA在这本技术手册中将介绍敏捷开发的一些技巧以及瀑布方法和敏捷方法的对比,同时还涵盖了云对于敏捷开发所起到的作用。

  • BPEL 2.0服务契约手册

    本技术手册旨在探讨如何为封装WS-BPEL流程逻辑所需的Web服务设计WSDL定义。因为SOA提倡用“契约优先”的方式来设计服务,所以理解由WS-BPEL引发的这种独特服务契约设计理念,是成功构建有效流程和服务的关键因素。

  • BPEL基础使用技术手册

    BPEL是一门用于自动化业务流程的形式规约语言。 用XML文档写入BPEL中的流程能在Web 服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。在《BPEL基础使用技术手册》中,我们将介绍BPEL流程基础结构、BPEL可以用在哪些方面以及在在Oracle SOA套件中如何用BPEL创建复合服务。

  • 商业智能:BI

    商业智能也称作BI,是Business Intelligence的缩写。商业智能的概念最早在1996年提出。当时将商业智能定义为一类由数据仓库(或数据集市)、查询报表、数据分析、数据挖掘、数据备份和恢复等部分组成的、以帮助企业决策为目的技术及其应用。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算