devops 敏捷开发_敏捷开发 瀑布开发 devops - CSDN
  • 本课程主要讲解敏捷开发DevOps 在实际研发中如何提高效率、降低成本,以及分享互联网公司的研发流程、岗位分工和技术点,学习业界先进工程技术,提高团队效率。 本次腾讯云大学大咖分享课程邀请 CODING DevOps...

    点击观看大咖分享

    随着互联网、移动互联网的浪潮,软件工程从瀑布到敏捷发生了巨大的变化,服务器架构也从 IOE 演变到微型机,又发展为云计算,运维成本越来越低,持续部署逐渐流行起来。本课程主要讲解敏捷开发和 DevOps 在实际研发中如何提高效率、降低成本,以及分享互联网公司的研发流程、岗位分工和技术点,学习业界先进工程技术,提高团队效率。

    本次腾讯云大学大咖分享课程邀请 CODING DevOps 架构师 杨周 分享关于“敏捷开发与 DevOps 实战”课程的内容。

    软件工程:从瀑布到敏捷

    软件工程从瀑布到敏捷,是对软件工程效率和软件交付效率的提升。

    瀑布模型(Waterfall Model)将软件生命周期划分为6个阶段:计划、需求分析、设计、编码、测试、维护,顺序固定,如同瀑布逐级下落。作为早期软件工程方法,瀑布在20世纪80年广泛使用,但存在致命的缺点:流程是线性的,到最后才测试和交付开发成果,一旦发现问题为时已晚,所以没能很好的解决软件危机,2003年的统计报告显示82%的项目延期,和1995年的84%几乎没有好转。

    敏捷开发是循序渐进的开发方式,在尽量短的周期内持续测试和交付“可运行的软件”,再加上团队沟通和客户沟通,从而做到了“拥抱变化”。在敏捷开发中,软件项目在构建初期被切分成多个迭代,各个迭代的成果都经过测试,具备可视、可集成和可运行使用的特征。

    敏捷开发宣言:

    1. 个体和互动:高于流程和工具
    2. 可运行的软件:高于详尽的文档
    3. 客户合作:高于合同谈判
    4. 响应变化:高于遵循计划

    从上面的宣言可以看出,敏捷开发的核心是人 、协作、时刻可运行的软件、变化。

    敏捷开发框架

    敏捷是一种思想,不止应用于软件开发。

    敏捷开发框架种类较多,但Scrum使用频繁度最高。

    幻灯片9.JPG

    下图为 Scrum 框架的流程:

    幻灯片10.JPG

    互联网公司的岗位分工和敏捷工作流

    主要有产品负责人和开发团队,具体工作流如下图所示,而敏捷教练往往由研发工程师或产品经理兼任。

    DevOps 自动化上线

    实战:Git项目管理&自动上线

    修改一个错别字需要多久呢?其背后流程又是如何运作的?

    首先,使用缺陷管理

    其次,创建缺陷

    由于这个文档项目很简单,所以采用单分支开发,即 GitHub Flow。具体知识大家可以扫描下图中二维码进行阅读。

    Git commit 怎么写才正规?有两个原则:

    1、不要做完几件事一起提交,而是做完一件事就提交一次,用一句话简洁地描述

    2、详细的描述在任务里,关联任务 ID 即可,所以做任何事之前都应该先创建任务

    建议大家安装使用 git cz 工具,提供了 feat、fix、refactor 等关键词,严格按照要求做,经过一段时间就学会了。具体知识大家可以扫描图中的二维码进行阅读。

    最后,合并请求

    团队沟通的效率非常重要,这是敏捷开发的核心价值观。效率最高的是 面对面交谈,然后是电话、即时聊天,最差是邮件。

    所以发起代码合并请求之后,用即时聊天软件通知同事,请她进行评审,她合并之后,就自动上线了。

    敏捷开发之持续交付

    持续交付已发展为DevOps

    服务器架构:从自建到云计算

    雅虎开创了 web 1.0 时代,编辑生产内容,免费提供,通过网站广告营利,这个模式至今仍然是2C消费互联网的主要商业模式。

    如果大家对互联网发展史感兴趣,推荐阅读《浪潮之巅》,作者是吴军博士,曾担任 Google 资深研究员和腾讯副总裁。

    云计算的第一个产品是 云存储,第二个产品才是租服务器。

    自建服务器的上线流程

    幻灯片26.JPG

    云计算时代的上线流程

    可以发现,云计算大厂招募运维开发岗,广大中小团队和非科技公司点击开通就可使用,不再需要招聘不会编程的普通运维了,所以运维的岗位数量越来越少,难就业。

    而开发人员会配云服务器是必备技能,学计算机的同学请注意。

    DevOps

    DevOps 自动上线的原理

    把一个网站部署到服务器分为几步?答:3步。

    1. 打成压缩包;
    2. SCP 上传到服务器;
    3. SSH 解压;

    如果使用持续集成,则可以实现提交代码时自动上线,原理如下图:

    常见的持续集成有:商业化的 CircleCI、开源的 Jenkins,本文以 Jenkins 云服务—— CODING 为例。

    1、 DevOps 理念

    自动化是核心理念。

    2、 DevOps 权限最佳实践

    代码质量的终极方案:Code Review 和单元测试

    1、 现状的代码质量低。

    2、 提高代码的终极方案有如下三种。

    实战:像互联网公司那样做项目(代码托管、敏捷开发、DevOps)

    像互联网公司那样做项目。这些属于产品经理的工作,对大学专业无要求,推荐感兴趣的同学读一读《俞军产品方法论》

    创建团队

    backlog 与迭代

    服务器安装了 Apache,就可以通过 IP 访问了,但 IP 都是数字,不好记,所以我们需要买个域名。

    切记:不要用电话号码、QQ 号这种很长的数字注册域名,那和 IP 一样难记,失去了域名的本意。

    2012年,腾讯注册了五位和六位数的QQ号码.cn域名,结果并不好用,2014年就过期了。具体新闻请扫描喜爱阅读。

    域名解析有一个入门技术点:www 其实是二级域名,根域名是什么都不带的,一定要都配上,才能保证用户输入哪个都能访问。

    这个网站很简单,就是一个 markdown 文档,Git 提交流程和上一篇实战一样,就不再赘述。Git 提交完毕,我们来配置一下 Jenkins,建议调试阶段使用在线静态 Jenkinsfile,调试通过以后,再保存到代码库里。

    • 注册 coding.net,创建一个 Git 仓库,提交代码;
    • 创建一个私钥放在 CODING,把公钥放在服务器的 .ssh/authorized_keys,实现 SSH 信任,参考文档:《在持续集成中使用凭据》
    • 新建构建计划,选择“使用静态配置的 Jenkinsfile”,然后可以使用“图形化编辑器”,也可以使用“文本编辑器”填入下面代码,保存并构建;

    pipeline {
      agent any
      stages {
        stage('检出') {
          steps {
            checkout(
              [$class: 'GitSCM', branches: [[name: env.GIT_BUILD_REF]],
              userRemoteConfigs: [[url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID]]]
            )
          }
        }
        stage('构建') {
          steps {
            echo '构建中...'
            // 把 markdown 转成 HTML
            sh 'apt-get update && apt-get install -y python3-pip'
            sh 'pip3 install mkdocs'
            sh 'mkdocs build'
            // 打包成压缩包
            sh 'tar -zcf tmp.tar.gz apache2/ site/'
            echo '构建完成.'
          }
        }
        stage('部署') {
          steps {
            echo '部署中...'
            script {
              def remote = [:]
              remote.name = 'web-server'
              remote.allowAnyHosts = true
              remote.host = '106.54.86.239'
              remote.user = 'ubuntu'
              // 需要先创建一对 SSH 密钥,把私钥放在 CODING 凭据管理,把公钥放在服务器的 `.ssh/authorized_keys`,实现免密码登录
              withCredentials([sshUserPrivateKey(credentialsId: "c4af855d-402a-4f38-9c83-f6226ae3441c", keyFileVariable: 'id_rsa')]) {
                remote.identityFile = id_rsa
    
                // SSH 上传文件到远端服务器
                sshPut remote: remote, from: 'tmp.tar.gz', into: '/tmp/'
                // 解压缩
                sshCommand remote: remote, command: "tar -zxf /tmp/tmp.tar.gz -C /tmp/"
                sshCommand remote: remote, sudo: true, command: "mkdir -p /var/www/china-speed"
                sshCommand remote: remote, sudo: true, command: "cp -R /tmp/site/* /var/www/china-speed/"
                sshCommand remote: remote, sudo: true, command: "cp -R /tmp/apache2/ /etc/"
                // 重启 apache2
                sshCommand remote: remote, sudo: true, command: "a2ensite china-speed.org.cn"
                sshCommand remote: remote, sudo: true, command: "a2enmod headers rewrite ssl"
                sshCommand remote: remote, sudo: true, command: "systemctl reload apache2"
              }
            }
    
            echo '部署完成'
          }
        }
      }
    }
    

    经过一番调试,Jenkins 构建成功了,这时候再把它保存在代码仓库里,把设置修改为“使用代码库中的 Jenkinsfile”,以后推送代码即可自动上线。

    • 切换到 Markdown 编辑器TS
      流量劫持属于互联网黑产,2015年,国内某智能路由器厂商劫持404页面,收集用户数据并插广告。后来此厂商的官网也被宽带运营商劫持插广告,他们部署了 HTTPS,仍然被劫持,就是因为没有部署 HSTS 以及禁止 iframe。
      当用户手动输入域名时,浏览器默认请求 HTTP,返回跳转,但被劫持篡改成 200,内容改为 iframe 展示 HTTPS 的正常内容,而 iframe 外面展示广告。更多知识请扫描图中的二维码进行阅读。

    • no-www
      2018年9月,Chrome 69 隐藏 www,引发了争议,让人以为真的不用打 www 了,结果很多落后网站无法访问,比如学校网站。然后 Chrome 又显示了 www。到了2019年8月,Chrome 76 再次隐藏 www。理念很简单:技术应该迁就用户,而不是迁就那些落后的网站。www 没有意义,去掉让用户更方便更环保。
      就像万维网之父蒂姆在2009年向公众致歉:网址中 http: 后面的两条斜线 // 其实没必要。“如果这么多年来人们不用写或敲入那两条斜线的话,该可以省下多少的纸和树啊。”
      所以我建议:大家做网站时,把 www 跳转到根域名。更多有趣的知识可以扫码阅读。

    总结

    完整代码:https://china-speed.coding.net/p/china-speed/d/china-speed/git


    问卷

    为了给广大开发者提供最实用、最热门前沿、最干货的视频教程,请让我们听到你的需要,感谢您的时间!点击填写**_ 问卷

    腾讯云大学是腾讯云旗下面向云生态用户的一站式学习成长平台。腾讯云大学大咖分享每周邀请内部技术大咖,为你提供免费、专业、行业最新技术动态分享。

    展开全文
  • 从概念上说,DevOps 是一种方法论,是一组过程、方法与系统的统称,用于促进应用开发、应用运维和质量保障(QA)部门之间的沟通、协作与整合。概念有了,怎么落地?很多公司在实施容器云时实现CI(Continuous ...

    前言

    DevOps是什么?从概念上说,DevOps 是一种方法论,是一组过程、方法与系统的统称,用于促进应用开发、应用运维和质量保障(QA)部门之间的沟通、协作与整合。概念有了,怎么落地?很多公司在实施容器云时实现CI(Continuous Integration, 持续集成),或者CI/CD(Continuous Integration/Continuous Delivery or Deployment, 持续集成/持续交付 or 持续部署)就叫DevOps。我们觉得这只是实现DevOps的一部分,但不等于DevOps。

    一、CI 不等于DevOps

    CI持续集成是编码、构建的过程。容器云DevOps从CI起步,也是一个很好的切入点。但这仅仅是一个开发构建过程,都在开发端,是实现敏捷开发的一种方式,研发过程自动化,这也是我们考虑采用容器云和DevOps的一个因素。但仅有开发端的敏捷还不等于DevOps。

    二、CI /CD也不等于DevOps

    现在我们也总是听到一天要上线多少次多少次的。是一个应用吗?频繁上线是需求不明确还是代码质量不高?厂商在这里可能有点偷换概念。一天上线几十次几百次,肯定不是一个应用。象阿里等,那么多系统那么多应用,每天那么多的更新次数很正常。持续交付、持续部署的好处是基于自动化的过程支持。也就是开发、测试、交付部署过程工具链集成实现自动化。

    但CI/CD依然没有解决开发、运维、质量保证部门之间的协作和整合。职责依然没有划分清楚。而且目前的容器云CI/CD流水线设计,不足以支撑企业生产环境部署要求。更多象是PoC概念验证阶段。这也是为什么很多公司即便采用容器云也只是在开发测试环境使用的原因。

    三、我们理解的DevOps是什么?

    DevOps在概念上理解其实很简单,但落地很难。很多厂商也提出要建立领导小组、委员会什么的,就是要调整企业组织结构。我们觉得这就是技术人员思维方式,理想化!组织结构的调整是大事,牵扯的利益很多,很难要求一家公司为了一个项目去调整组织架构。其实云计算已经有了一个很好的解决方案:多租户。这也是我们对多租户设计要求比较高的一个原因。

    我们采用容器云的需求是:

    1.提升敏捷开发能力。这是DevOps能力

    2.建立开发测试甚至生产环境一致性。 这是容器云和DevOps能力。

    3.实现应用全生命周期自动化管理。这是DevOps能力。

    4.弹性伸缩、灰度发布等。 这是容器云和微服务的能力。

    这也是我们为了适应公司互联网业务发展和应用快速迭代开发的要求,让生产端也更加敏捷起来;逐步建立标准化、一致性的开发、测试、运维环境,专注于业务应用研发而不操心资源管理;满足公司内私有云环境内的应用托管、应用开发、自动化运维等应用服务全生命周期管理需求;实现应用服务的弹性伸缩、灰度发布等能力,满足促销、秒杀等业务需求;从而逐步提升自主研发能力,促进业务创新和快速迭代。

    从我们采用容器云的需求上看,前三项都是涉及DevOps能力的。DevOps要求开发、测试、运维一体化,谁开发谁运维,实现敏捷开发、敏捷部署和敏捷生产。

    DevOps从计划、编码、构建,到测试、发布、部署,以及运营、监控,形成一个环路。这也是我们实施服务化或者采用微服务持续改进的要求。结合容器的搭建和微服务架构的采用,我们把DevOps分为下面几个流程:

    持续集成,需求的不断变动触发持续的编码、构建流程。
    持续交付,完成测试的业务应用以合适的方式交付到适当的节点。
    部署发布,将交付的业务应用按照规则部署到生产环境,完成测试后发布。
    持续监控,时时监控业务应用以及系统平台的运行情况,形成监控报告。
    持续反馈,是基于监控和业务应用的使用情况,持续的数据分析,持续地提出完善意见。
    持续改进,基于反馈的意见,启动新的改进计划流程。
    这些流程的实现,需要众多工具的支持,形成一套DevOps工具链。这些流程如何落地?我们觉得可以从这些方面考虑:

    (一)持续集成

    持续集成阶段,考虑实现计划流程自动化、资源选择自动化、代码质量控制自动化、构建自动化等流程。借助相应的工具链,来提升对业务需求的响应能力和敏捷的开发能力。

    计划流程自动化,是从最初的想法提出,或者反馈的意见建议,有自动跟踪的工具。经过可行性分析讨论,最后形成业务需求,安排开发计划。这个阶段的信息我们觉得应该对所有人开放。有人会觉得这样的话你一言我一语、乱七八糟的信息就特别多,我们反而觉得这样才能收集到真实的需求、真心的建议、真正的意见!我们有大数据平台,可以通过大数据平台来初步分析这些信息,提取有价值的想法建议,由相应的业务人员、分析人员作出初步的评估,形成初步需求,和技术分析师、业务分析师等进行评估讨论可行性、疑难点、紧迫性、资源投入、风险特性等,然后根据实际排进研发计划。计划流程使用什么工具?我们觉得Jira就是一个不错的工具,可以满足这些需求。

    资源选择自动化,其实我们是考虑把人力资源做成一个资源池,或者仅仅把软件技术人员做一个人力资源池,这样可以结合Jira实现技术资源的自动化选择。同时也可以作为技术人员评估考核的一个量化依据。不过人力系统需要做点扩展,同时需要提供集成接口。

    代码质量控制自动化,是实现代码质量的自动检查。编码当然还是离不开人,研发人员完成编码之后,提交到SVN或Git,可以借助于Sonar等工具来实现代码质量的自动检查。代码提交,触发代码质量检查。Sonar插件集成到IDE工具,自动实现编码质量扫描,比后期的提交之后再做扫描会更好。

    构建自动化,采用容器云后就是构建镜像。在代码检查完毕,没有什么缺陷的情况下,可以自动启动构建流程,Maven或Gradle是目前比较受欢迎的工具。说起构建,一般都离不开Jenkins。它可以集成SVN或Git,JDK,Sonar,Maven等众多工具,是非常方便的构建自动化实现方式。

    (二)持续交付

    镜像构建完毕,上传到镜像仓库。开发工作暂告一段落,需要准备测试环境进行测试。实现自动化测试,需要实现环境准备自动化、测试用例生成自动化、质量监控自动化、交付自动化。

    测试环境准备,传统测试方式是非常花费时间的事情。借助于容器云,实现开发、测试甚至生产环境一致性,提高测试的效率,提高敏捷性。我们希望通过申请,容器云构建分配测试需要的环境和资源。测试环境由QA来维护和提供,测试环境用到的基础设施资源,由运维人员来维护和提供。研发人员在此阶段专注于业务应用的测试。这里我们定义一个测试域,就是一个业务应用的范围。业务应用之间的调用测试通过虚拟接口模拟数据的方式实现,一个测试环境一次测试不会超越这个域。QA可以很明确很方便的去维护这些域环境。这样其实也和我们多租户的设计相关。不同的租户都有自己独立的明确的边界,和其他租户的交互通过标准的协议和接口实现。

    测试用例生成自动化,这可能需要QA团队实现一些工具,根据业务需要自动生成测试用例数据。

    测试过程中,不可避免会发现一些缺陷和漏洞,需要自动记录测试数据和异常信息,以备进一步分析。完全的质量监控自动化比较困难,结合自动测试和人工测试,自动检测和人工记录,形成测试报告。测试工具有很多种,这可能需要QA去做一些工作,比如用Jmeter测试业务服务时发现异常或缺陷,如何自动和Jira系统集成自动把缺陷信息记录。

    测试完成没有问题,自动交付到生产镜像仓库。

    1、镜像仓库

    容器云中镜像仓库我们作为持续集成和持续交付的终点,也是开发和业务部署运营的中介、中间节点。所有的开发测试工作到此已经完全完成,所交付出来的是可以部署到生产的业务应用镜像。每个镜像备注说明,包括配置说明,部署事项,依赖关系等。

    镜像仓库中的镜像需要实现镜像的自动安全扫描,确保使用的镜像是安全的。

    (三)部署发布

    部署首先涉及到基础设施资源,资源供给实现自动化。不同的应用可能对资源的要求不一样。就象AWS,提供了几十种不同的资源类型,不同的业务需求可以选择不同的资源类型,在容器云上也可以通过简单的标签来实现资源类型匹配,从而实现资源选择的自动化能力。

    容器云还有一个重要的特性是弹性伸缩的能力,这也是我们考虑采用容器云的一个因素。弹性伸缩非常适合促销、秒杀等业务活动。我们在《容器云之弹性伸缩》中详细讨论过这一点。大部分厂商也基于CPU、Memory实现了自动弹性伸缩能力。如果能更完善,更能满足业务弹性伸缩的需求。需要说明的是,即便有自动弹性伸缩的能力,在一些促销、秒杀业务开始前,还是需要提前根据预测部署足够的实例,准备足够的备用资源。自动弹性伸缩是为了避免意外,不是为了放任不管。

    业务运营过程中,会涉及到一些定时任务或批处理任务。这些工作可以通过任务调度自动化能力来实现。可以通过自动调度组件来实现,也可以通过脚本来实现。

    业务运营中很重要的工作是服务治理。服务治理和服务部署也密切相关。不同的服务架构、不同的服务治理实现方式,都可能会影响到服务部署的方式。服务的路由、熔断、容错、优先级等也需要实现自动化能力。当然这部分大部分组件都已提供了相应的能力。

    (四)持续监控

    日志、监控是业务运营过程中判断业务运行是否正常的重要的基础能力,持续监控就是实现平台各层次的健康检查能力。包括基础设施层、平台层、应用层等。基础设施层就是我们通常所说的IaaS层,存储、网络、计算资源等。平台层是容器云平台的能力,比如Docker引擎、容器编排调度、服务发现、负载均衡等。应用层需要实现对应用的进程、使用资源(存储、计算资源等)、网络流量等进行监控检查,收集日志。

    持续监控是实现日志收集、健康检查监控的自动化。

    (五)持续反馈

    持续反馈是基于日志和监控的基础上,实现数据分析自动化、告警自动化、反馈自动化等。日志中心对收集到的数据可以进行分析,监控中心对监控数据也需要进行分析,不只是有异常才提示、告警,其实这些数据也可以和大数据平台进行集成,使用大数据平台实现一些关联分析,从而提供更多有价值的反馈。

    反馈的形式可以是简单的短信、邮件告警,也可以是分析报告。集成短信、邮件、微信、设置是Jira等系统可以实现反馈的自动化。当然在实现的时候也需要相应的过滤规则。

    (六)持续改进

    基于反馈的信息,继续改进应用服务。实现了业务应用的全生命周期管理。在各个阶段实现自动化,也提升了效率和响应能力。

    四、开发、运维、QA之间的关系

    前面说了那么多,还没有说明开发、运维和QA之间的关系。到底谁该做什么?我们认为:DevOps中,开发专注于业务应用的生命周期管理,运维专注于自动化环境资源的维护,QA专注于自动化业务运行环境的供给和质量跟踪保证。

    上面我们谈到的大部分工作,其实是开发人员的职责。也就是业务应用的全生命周期的管理。也是因为运维和QA都是在做幕后的工作。运维人员主要负责资源,软硬件资源的维护,要保证应用服务整个生命周期所需的软硬件资源具备。比如运营过程中磁盘损坏的修复,主机计算资源的增删、分配等。QA则承担提供开发、测试、生产运行环境供给和测试用例自动生成,以及测试自动化、运维自动化工具研发,质量跟踪保证等职责。

    五、形散神聚统一体

    DevOps和容器云是相辅相成的,容器云提供基础设施资源,为DevOps的实现提供了资源基础。很便利的实现环境一致性。容器云并不包含DevOps,所以不是在容器云里实现DevOps,所以容器云中去做CI或CD流水线,是不合适的。CI应该是独立于容器云而存在的,即便不采用容器云,同样可以实现CI 或DevOps。

    DevOps和容器云不是天生一体的。没有容器云DevOps也可以实现。容器云是微服务运营的一个便利的载体,微服务生命周期管理可以是DevOps的一个重要部分。容器云的架构非常适合微服务的架构。微服务的开发部署和运营又和DevOps的理念和方法论很匹配,所以采用容器云和微服务,实现DevOps,是一个很好的选择。

    不管再怎么变化,人是总控,是master,需要协调定义好人在各个流程各个环节的角色和职责。DevOps也是一个不断优化、持续改进的过程。

    原作:DevOps 不等于 CI,也不等于 CI /CD

    展开全文
  • 敏捷开发、持续集成/交付(CI/CD)、DevOps学习笔记 版权声明:原创内容,如需转载请联系作者。 https://blog.csdn.net/CrankZ/article/details/81545439 概述 敏捷开发DevOps都是一种理念。他们的理念相似,...

    敏捷开发、持续集成/交付(CI/CD)、DevOps学习笔记

     

     版权声明:原创内容,如需转载请联系作者。 https://blog.csdn.net/CrankZ/article/details/81545439

    概述

    敏捷开发和DevOps都是一种理念。他们的理念相似,都是为了更好更快的发布产品,但又不完全相同。

    而CI/CD是实现这两者理念的一种方法。

    敏捷开发

    前言

    传统方式开发前有一份详细的开发文档,程序员照着需求直接敲代码,产品做好了直接部署上线。中间不会有人打扰,需求也不会变。

    但是目前的情况是,用户需求和市场都变化太快,就算你前期用户调研的再好,计划书写的再详细,也抵不住市场的变化,说不定产品做出来,用户就不需要了。

    所以为了适应市场的发展,我们必须不断提高我们的开发效率,及时跟进用户需求,缩短开发周期。在这种情况下,就有人提出了敏捷开发。

    传统开发

    传统开发方式的拥护者和敏捷开发方式的拥护者看待软件开发的世界观是不同的。
    在传统开发的眼里,软件开发过程是确定的、可测的,只要在一开始努力收集到需要的信息并制定好计划,然后忠实的执行计划就应该可以成功。如果不成功一定是你在一开始就没有做好,没收集到必要的信息,计划做的不好或者执行不到位。然后传统开发方式就试图引入更多的流程,文档,试图让每一步都做到万无一失

    敏捷开发

    而在敏捷的眼里世界可不是这样的,敏捷认为在软件开发中,世界是变化的,有很多不确定首先不论哪种开发方式,不过不管什么开发方式前期还是要做足充分的调研和分析,收集足够多的信息。但是我们不是先知,没人能确保自己的预测足够准确,也没人能保证能收集到所有有用的信息。但是可以肯定的是随着开发的进行,我们对会对正在做的东西的认识越来越深刻。因而做一段时间后常常有发现需求有调整,或发现之前的想法不对。另一方面,世界本来就是在快速变化中,尤其是互联网,所以我们也不得不适应这个环境。所以为了适应这个市场的变化,我们要采用敏捷开发。

    总结

    在传统开发中要做好一个产品,大部分精力都要花在前期

    1. 更多调研
    2. 更多信息
    3. 更多文档

    缺点

    始终走在市场后面,无法紧跟潮流,做出的产品容易被淘汰。

    敏捷开发核心

    1. 拥抱变化
    2. 快速迭代

    下面图的标题是How Spotify builds a product.很好的诠释了敏捷开发的含义

    CI/CD

    概述

    可以把开发工作流程分为以下几个阶段:

    编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署

    正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。

    持续集成CI(Continuous Integration)

    基本概念

    持续集成(Continuous Integration)简称CI,持续集成强调开发人员提交了新代码之后,立刻自动的进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。

    持续集成过程中很重视自动化测试验证结果,对可能出现的一些问题进行预警,以保障最终合并的代码没有问题。

    持续交付CD(Continuous Delivery)

    基本概念

    持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。交付给质量团队或者用户,以供评审如果评审通过,代码就进入生产阶段。

    持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。

    这里强调的是

    1. 手动部署
    2. 有部署的能力,但不一定部署

    持续部署(Continuous Deployment)

    基本概念

    http://3lsqjy1sj7i027fcn749gutj-wpengine.netdna-ssl.com/wp-content/uploads/2015/12/409-images-for-snap-blog-postedit_image3-auto.png

    持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。

    这里强调

    1. 持续部署是自动的
    2. 持续部署是持续交付的最高阶段

    持续交付(Continuous delivery)与持续部署的关系

    有时候,持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中,但是出于业务考虑,可以选择不部署。如果要实施持续部署,必须先实施持续交付。

    1. 持续交付表示的是一种能力
    2. 而持续部署则是一种方式

    具体实现

    整体而言,Jenkins 过去一直是大部分公司的选择,但这个现象正在发生改变,随着公有云服务、Docker,SaaS 的普及,越来越多的企业开始选择在线托管型持续集成系统。

    总结

    「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行。无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。

    DevOps(开发与运维 – Development and Operations)

    产生背景

    DevOps是Development和Operations缩写,现在市场需求和技术变化都非常快,为了配合市场的需求,开发周期就要变短(但是软件质量不能因为这个原因降低),比如说某些APP可能每周就要更新一次,所以说为了跟上市场的变化,势必就要缩短开发周期,但是传统的开发过程中与运维相关的部分比如测试,发布,部署都很花时间,所以往往开发人员和运维人员之间有着很深的隔阂,并且两者沟通效率低,为了解决这个问题,使之能够更专注于开发。就有人提出了DevOps这理念。

    DevOps简单的说就是为了打破传统开发和运维之间的隔阂与低效,在保证产品质量的前提下实现更自动化、更高效的协作与产品的交付。

    DevOps是什么

    DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

    具体来说,就是在软件交付和部署过程中的提高沟通与协作的效率,旨在更快、更可靠的的发布更高质量的产品

    我们可以列举下DevOps是干啥的。

    • DevOps是一组过程、方法与系统的统称。用于促进开发、运维和质量保障部门之间的沟通、协作与整合。
    • DevOps是一种文化转变,打破了以往开发和运维之间的隔阂,或者说是一个鼓励更好地交流和协作(即团队合作)以便于更快地构建可靠性更高、质量更好的软件的运动。
    • DevOps 是一种工程模式,本质上是一种分工,通过对开发、运维、测试,配管等角色职责的分工,实现工程效率最大化,进而满足业务的需求。
    • DevOps是一种能力,具备此能力的团队可以高质量、快速的交付软件产品或服务。

    DevOps与传统开发方式区别

    传统的开发方式是线性的,开发与运维之间存在隔阂而且沟通效率低下。而DevOps使开发与运维的流程形成了一个闭环,打破了隔阂,各部门协作更紧密,提高了协作效率。

    DevOps好处

    http://5b0988e595225.cdn.sohucs.com/images/20180628/e4fbf44fa9b44f36b98e5f01f02db79f.jpeg

    • 依托自动化工具把开发、测试、发布、部署的过程整合,实现高度自动化与高效交付。
    • 在保证产品质量的前提下快速、频繁地发布产品。
    • 能够即使获得用户反馈,并快速响应。
    • 最大限度地减少风险,降低代码的出错率。
    • 高质量的软件发布标准。整个交付过程标准化、可重复、可靠。
    • 整个交付过程进度可视化,方便团队人员了解并控制项目进度。
    • 团队协作更高效。

    为什么DevOps姗姗来迟

    1. 容器技术开始成熟,特别是docker技术的大行其道。
    2. 微服务架构技术的广泛使用。
      微服务是支撑DevOps方法的手段,传统开发是在一个服务器里面,把各种元素装在一起组合成一个程序,但微服务是每一个服务是一个单独的单元,可以部署在不同的服务器上,通过SOA的方法,把它连接起来,再提供整个功能。
      微服务是由一个个团队组成,每团队有自己的服务,做好后,可以独立的进行测试、开发、部署,然后整个应用组合到一起。
    3. 敏捷开发流程的深入人心。
      诸如Scrum, Agile, Kanban等敏捷方式被团队广泛使用,TDD、BDD、DDD这些测试驱动设计、行为驱动设计、域驱动设计等设计方式的采纳,CI和CD这些持续集成和持续部署等方式的实施,这些都是对DevOps的强烈需求。

    DevOps带来的变革

    1. 角色分工:打破传统团队隔阂,让开发、运维紧密结合,高效协作
    2. 研发:专注研发、高度敏捷、持续集成
    3. 产品交付:高质量、快速、频繁、自动化、持续交付

    具体落地

    简单的说,DevOps=团队文化+流程+工具

    1. 团队文化的意思很简单就是你的团队要知道并认可DevOps理念
    2. 然后就要通过具体的流程和工具来实现这个理念。

    DevOps工具

    简单列举下常见的DevOps工具

     

    参考:

    https://segmentfault.com/a/1190000006166538

    http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html

    https://acejoy.com/2018/04/20/438/

    https://zh.wikipedia.org/wiki/%E6%8C%81%E7%BA%8C%E4%BA%A4%E4%BB%98

    https://zh.wikipedia.org/wiki/DevOps

    https://www.zhihu.com/question/33600749/answer/57971123

    https://www.jianshu.com/p/9fbdc741a10

    展开全文
  • 华为敏捷开发介绍,非常经典,值得学习。讲述敏捷转型的内在含义,分析企业现状,差距,如何转型,转型要求、步骤等
  • DevOps敏捷开发

    2018-08-01 09:58:50
    第一,是在需求阶段和开发阶段之间,针对不断变化的需求,对软件开发者提出了高要求,所以出现了敏捷开发方法论,强调适应需求、快速迭代、持续交付。第二、是在开发阶段和构建部署阶段之间,大量完成的开发任务可能...

    在软件开发生命周期中,会遇到两个瓶颈。第一,是在需求阶段和开发阶段之间,针对不断变化的需求,对软件开发者提出了高要求,所以出现了敏捷开发方法论,强调适应需求、快速迭代、持续交付。第二、是在开发阶段和构建部署阶段之间,大量完成的开发任务可能阻塞在部署阶段,影响交付,于是有了DevOps。

    引用:
    https://blog.csdn.net/difffate/article/details/77542768

    展开全文
  • 敏捷开发管理贯穿软件生命周期的始终,覆盖了从市场和用户,到开发,发布和运维的方方面面。但是它更多体现的是流程,沟通,协作等方面的方法和实践,比如它提倡快速,高质量的开发产品原型交付于市场,以便尽快获取...
  • 腾讯云开放DevOps敏捷开发套件,助开发者驶入开发快车道   开发者如何在云计算时代更好的提升开发效率?8月23日,在腾讯“云+未来”峰会北京站开发者专场上,腾讯云宣布将陆续开放DevOps(英文Development和...
  • 华为云HE2E devops 敏捷开发实践课程——Kanban和Scrum 粒度和耦合 规划、设计、跟踪 HE2E 框架 Kanban看板方法 通过可视化寻找改进点并驱动团队持续交付的有效方法。 看板——“信号卡”代表的一系列方法 信号卡 ...
  • 其中的很多理念都是从敏捷开发管理引申过来的,比如:持续反馈,持续改进,持续业务计划等等,越来越觉得敏捷开发管理,DevOps和微服务是天作之合,如果能够结合企业的愿景和成熟度来规划整体建设,那么企业转型成功...
  • Team Foundation Server 2015 Update 2版本终于在2周前的//Build 2016大会上正式发布了,借这个东风,小编也完成了【DevOps敏捷开发动手实验】开源文档的第一个正式版本v2015.2 文档地址:...
  • Jenkins 是一个独立的开源软件项目,是基于 Java 开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。它可以用于自动化运行各种任务,如构建,测试和部署...
  • DevOps敏捷开发流程

    2019-11-19 17:29:15
    近期根据我们DevOps开发团队敏捷开发项目的实践经验,将完整流程整理如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际过程中可以参考。 1. 目的 规范...
  • 敏捷开发DevOps都是一种理念。他们的理念相似,都是为了更好更快的发布产品,但又不完全相同。 而CI/CD是实现这两者理念的一种方法。 敏捷开发 前言 传统方式开发前有一份详细的开发文档,程序员照着需求直接敲...
  • 两者之间的差异在于开发后会发生什么。早期,软件开发并不真正使用特定的管理框架。然后是瀑布开发方式,它提出了一个想法,即可以通过应用程序创建或构建所花费的时间来定义软件开发。那时,创建,测...
  • devops 敏捷 题目 有答案 单选题 devops敏捷练习题合集 带答案 分享01
  • 原文链接:点击打开链接摘要: 让开发人员全心全意投入应用安全(APPSEC)的关键方法之一,就是清除掉将安全过程嵌入日常工作流时遇到的诸多麻烦。DevSecOps取得成功的一大因素,在于公司有能力实现开发人员不会痛恨的...
  • 它们与敏捷开发devops的关系? 现在某些大型公司中软件的开发和发布已经形成了一套标准流程,其中敏捷开发DevOps是更好更快发布产品的常用的两种理念,而CI和CD是实现这两种理念的一种方法。他们之际的关系可以...
  • DevOps 的世界里,所犯下的最大的错误是:整天只知讲些文化、协作, 却完全将最重要、最关键,存储在 SVN, Git⋯内的开发人员的 “行为数据” 视而不见。在 DevOps 的世界里犯下这样的错误,将使得团队白白的耗费...
1 2 3 4 5 ... 20
收藏数 11,919
精华内容 4,767
关键字:

devops 敏捷开发