devops

CI/CD 是一种通过在应用开发阶段引入 自动化 来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“ 集成地狱 ”）。 具体而言，CI/CD 在整个应用生命周期内（从集成和测试阶段，到交付和部署）引入了持续自动化和持续监控。这些关联的事务通常被统称为“CI/CD 管道”，由 开发和运维团队 以敏捷方式协同支持。 CI 和 CD 之间（以及不同 CD 之间）有什么区别？ 缩略词 CI / CD 具有几个不同的含义。CI/CD 中的“CI”始终指持续集成，它属于开发人员的自动化流程。成功的 CI 意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。 CI/CD 中的“CD”指的是持续交付和/或持续部署，这些相关概念有时会交叉使用。两者都事关管道后续阶段的自动化，但它们有时也会单独使用，用于说明自动化程度。 持续 交付 通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库（如 GitHub 或容器注册表），然后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。 持续 部署

在当今日益复杂和快速变化的环境中提供更可靠软件的分步指南 。 这篇文章基于最近一次与Cloud Native Computing Foundation合作，与OverOps工程团队的Brandon Groves和Ben Morrise合作创建的网络研讨会。 如果您认为向微服务和容器的转变是演变而不是革命，那么您来对地方了！在本文中，我们将对基于Kubernetes的应用程序领域采取务实的方法，并详细介绍一系列步骤，以确保整个管道的可靠性。 因为即使今天确保应用程序质量是过去的两倍，但我们还有很多改进方法。具体来说，在对基于Kuberenetes的应用程序进行故障排除的上下文中，我们将涉及持续可靠性的3个支柱：在CI管道中实现代码质量门，在CD管道中实现可观察性，以及创建上下文反馈循环回开发。 当今软件质量状况 首先，让我们尝试了解发生了什么变化以及为什么需要重新审视代码质量的基础。 就在最近，我们总结了年度 软件质量状况 调查，来自世界各地的开发人员提供了600多个答复。我们今年的目标是找出当今的工程团队如何解决速度与质量的难题。 好消息是，大多数调查参与者（70％）表示 质量至高无上 ，他们会优先考虑速度。不幸的是，受访者每周花费一天或更长时间来排查与代码相关的问题，其中超过50％的受访者每月至少一次遇到影响客户的问题。 尽管本次调查更广泛地关注于交付可靠软件的现实和挑战，但仍有

你肯定经常在会议室看到这样的场景： 线上出了 Bug 召集会议复盘，开发指责测试没测出来，没把好质量关； 测试抱怨开发不做单元测试，要不早发现了。 结果往往是大家写个改进报告， 测试保证添加相关测试用例并补充到回归测试集，开发承诺以后做好自测， 提交了事。 你应该做什么样的测试人？ 但这样，真的对工作改进或者测试人员成长有帮助吗？ 或者可以说公司真的需要你这样的测试么？ 在这个 5G 时代，“快”是唯一的标准，软件研发的交付也要快，对业务来说做到持续集成、持续交付，才能满足需求。 之前看了一个 统计 ，在 2018 年初全球已有 91% 的软件开发采用了敏捷开发，而现在已经 2020 年了，国内有更多的企业采用了敏捷开发模式， 但遗憾的是，真正理解“敏捷”的初心和目标的管理者和测试人寥寥无几。 很多时候，你不知道什么是 BDD（行为驱动开发），但却在使用 BDD 的自动化测试框架； 也不知道看板和敏捷的关系，但每天都在公司的项目管理工具里，处理电子看板上的测试任务。 大部分测试人知道敏捷测试，也有敏捷测试的意识。 但受限于自身的理解和企业的使用，也就不了了之了。 敏捷测试本身涉及很多东西，它包含了人员、组织、技术、方法、流程和工具等各个方面。 敏捷测试的思想和方法到底是什么？ 很遗憾，这件事情我也苦恼了一下， 因为市面上基本没有一套严谨的中文教材可以给我答案。 直到我看到了

你肯定经常在会议室看到这样的场景： 线上出了 Bug 召集会议复盘，开发指责测试没测出来，没把好质量关； 测试抱怨开发不做单元测试，要不早发现了。 结果往往是大家写个改进报告，测试保证添加相关测试用例并补充到回归测试集，开发承诺以后做好自测，提交了事。 你应该做什么样的测试人？ 但这样，真的对工作改进或者测试人员成长有帮助吗？ 或者可以说公司真的需要你这样的测试么？ 在这个 5G 时代，“快”是唯一的标准，软件研发的交付也要快，对业务来说做到持续集成、持续交付，才能满足需求。 之前看了一个 统计 ，在 2018 年初全球已有 91% 的软件开发采用了敏捷开发，而现在已经 2020 年了，国内有更多的企业采用了敏捷开发模式， 但遗憾的是，真正理解“敏捷”的初心和目标的管理者和测试人寥寥无几。 很多时候，你不知道什么是 BDD（行为驱动开发），但却在使用 BDD 的自动化测试框架； 也不知道看板和敏捷的关系，但每天都在公司的项目管理工具里，处理电子看板上的测试任务。 大部分测试人知道敏捷测试，也有敏捷测试的意识。 但受限于自身的理解和企业的使用，也就不了了之了。 敏捷测试本身涉及很多东西，它包含了人员、组织、技术、方法、流程和工具等各个方面。 敏捷测试的思想和方法到底是什么？ 很遗憾，这件事情我也苦恼了一下， 因为市面上基本没有一套严谨的中文教材可以给我答案。 直到我看到了

正文如下 本文是第十四届 - 前端早早聊成长晋升专场，也是早早聊第 99 场，来自 阿里云- - 亦才 的分享 个人介绍 所幸，大家讲的东西跟我今天要讲的不一样，我觉得还是比较不错的。要不然我讲的东西都是一样的话，估计大家听的也比较乏味了。 看一下我在阿里的经历，我是 2014 年加入淘宝，2019 年在阿里云，做的事情也比较多。在淘宝的时候做过业务，也做过技术产品。在阿里云这边也做过业务，也做过很多技术产品以及基础设施的建设。 大纲 今天会讲两个部分，第一个是 成长 ，第二个是 晋升 。 成长 成长这块我会多讲一些，这块我会分三个部分来讲。第一个是 成长模型 ，因为我希望大家在听完我这个 PPT 之后有一些收获，而不是说听完之后就没了。第二个是怎么去 建立自己的技术栈 。第三个是比较核心的问题是 怎么在业务中去成长 。 一、成长模型 首先是成长模型，从我自己的个人经历去总结的一个模型，外界不一定有。会分三个层次，第一个是 解决问题 的阶段，第二个是 发现问题 的阶段，第三个是 定义问题 的阶段。三个阶段都会通过一个案例去做分析，在案例里面每个阶段都是怎么去做的。 这个案例是之前做了一个技术产品叫做 UITEST，它是用来做单元测试以及 UI 测试的，这边会重点说一下单元测试。整个阶段是从下往上是一个上升的趋势。 解决问题 。先看一下解决问题这个阶段是怎么成长的？我们在做

“ OSC 源创会·年终盛典 ” 时间： 2018-12-16 09:00 -17:30 地点： 深圳 · 科兴科学园会议中心 费用： 50 元/人（现场缴费，女士，开源软件作者，积分 50 以上者均免费，邀请满三个好友报名者免费，学生凭学生证免费） 报名地址： 扫描以下二维码，即可报名 “ 会议 日程 ” 周日 2018 源创会·年终盛典 12.16 2018 09:30-12:00 年终盛典 · 主会场 上午 13:30-17:30 前端 · 分会场 下午 13:30-17:30 移动开发 · 分会场 下午 13:30-17:30 容器与微服务 · 分会场 下午 13:30-17:30 开源综合技术 · 分会场 下午 13:30-17:30 技术管理与开发效能 · 分会场 下午 部分主题 开源技术黄昏，开源人生黎明 马越 | 开源中国 CEO 重新认识现代Java 杨晓峰 | 京东 大数据中心架构师、OpenJDK Committer 企业级项目的Web自动化测试工程化实践 何林江 | 腾讯 高级前端工程师 基于场景化提效的企业中后台开发实践 郑淳（鬼鼠）| 阿里巴巴 高级前端工程师 基于Taro的多端项目实践 陈嘉健 | 京东 高级工程师 阿里巴巴企业级中后台UI解决方案 —— Fusion 开源首发 钱陈（潕量） | 阿里国际 前端技术专家 基于 Flutter

在本文中， 峰会大咖黄金泽 将从工具链逐步铺开的角度，讲述中国出口信用保险公司IT团队在交付方面如何从“刀耕火种”发展到 DevOps 落地的快速转型。 中国出口信用保险公司 DevOps 的发展历程 中国出口信用保险公司是我国唯一政策性出口信用保险公司，中国信保通过为对外贸易和对外投资合作提供保险等服务，促进对外经济贸易发展。 现阶段公司面临由大到强的整体转型，总部及分支机构迫切需要IT团队提供科技赋能，以用户为中心，实现科技引领的目标。因此IT团队面临很大挑战，传统的IT模式向DevOps转型也成为必然趋势。 项目背景：在企业IT部门转型 DevOps 任务之初，IT团队生产力工具匮乏，仅有的SVN和QC工具已经无法继续与日益增长的需求相匹配，同时，开发、运维间隙越来越大，相关技术积累薄弱、新旧文化冲突突显，转型困难重重。 什么 是 CI/CD 交付通道？ Continuous Integration，持续集成包括：源代码变更、自动检测、拉取、构建、单元测试、自动化测试等。 Continuous Delivery，持续交付包括：源代码变更、自动检测、拉取、构建、单元测试、自动化测试、生产交付等 在众多CI/CD交付链介绍中，从CI到CD的区别只是最后能否将代码交付到生产环境。从理论上讲，在CI/CD交付链全部工具和技术就位并运转后，能否交付到生产似乎并不是很困难的问题

添加图中小伙伴，领取 5折优惠 还有更多知名技术专家的到来▲ 点击阅读原文，立即报名 本文分享自微信公众号 - DevOps持续交付（devopscd）。 如有侵权，请联系 support@oschina.cn 删除。 本文参与“ OSC源创计划 ”，欢迎正在阅读的你也加入，一起分享。 来源： oschina 链接： https://my.oschina.net/u/2483000/blog/4362703