持续交付

一、持续集成概念理解 白话理解：多个开发人员多次将自己写的提交代码到某个文件夹,通过又之前的代码进行整合,发现错误并修改; 持续集成(Continuous integration,简称CI),简单地说就是多个开发人员一天多次地将自己编码的代码提交到主干; 01:快速定位错误(每完成一点代码更新,就提交到主干,通过以之前提交的代码进行集成可以快速发现其中的错误) 02:防止分支大幅度偏离主干(若不经常持续集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成); 持续集成的目的就是让产品可以快速迭代,同时还能保持代码的高质量。 二、持续交付概念理解 白话理解：所有开发人员在某个时间代码提交完成后,交给质量团队(测试工程师)进行测试。 持续交付(Continous delivery)指的是,频繁地将软件的新版本,交付给质量团队(测试人员)或者用户,以供评审,如果 评审通过,代码就进入生产阶段。持续交付可以看作是"持续集成"的下一步。它强调的是，不管代码怎样更新，软件 是随时随地可以交付给质量团队(测试人员)和用户进行评审。 三、持续部署概念理解 白话理解：质量团队(测试工程师)测试代码没问题,将代码交给运维人员,运维人员通过工具将代码发布到生产服务器 持续部署(Continuous deployment)是就是"持续交付"的下一步,指的是代码通过评审后,可以自己的部署到生产环境

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

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 软件工程快速地从敏捷开发到持续集成、再到持续交付的发展，如何才能跟上互联网大规模协作的软件进程？持续交付不是做不做的问题，而是不得不做、如何去做、如何做好的问题。 英文链接： Continuous Delivery: The Value Proposition 　　过去十年中，一个划时代的改变就是：基于Web的业务模式对传统企业业务模式的冲击。亚马逊就是历史最长，也最明显的例子之一，而越来越多的公司（从航空到金融服务）开始依赖软件打造其竞争优势了。 　　依靠软件来运行的业务有两个关键组件：一是你想如何改变世界的愿景，二是尽早收集用户的反馈。 精益创业运动 特别强调反馈的重要性，这不仅仅体现在创业公司。像亚马逊、NetFlix、和脸谱这样的公司也持续不断地对其网站进行小步改进，从而增加收入，并改善网站用户的体验。 　　 什么是持续交付？ 　　想在用户与项目团队（包括客户或者Product Owner）之间建立紧密的反馈环，依赖于你是否有这样的能力，即：通过持续交付新的软件版本，验证新的想法和软件的改动，并能衡量这些改动对收入的影响。 　　对于很多需要几个月时间才能发布新版本的公司来说，在一天之内发布数次似乎是天方夜谭。然而，遵循《持续交付》一书中的原则与实践，一些原来一 年才能发布几次新版本的公司

在使用 flow.ci 进行持续集成的过程中，也许你会遇到一些小麻烦。最近我们整理了一些常见问题在 flow.ci 文档之 FAQ ，希望对你有用。如果你遇到其他问题，也可以通过「在线消息」或去 Gitter群 给我们反馈 :) 这期 CI Weekly 收录了一些CI/CD进阶线路、具体实践、Dcker/微服务、DevOps相关的技术分享，一起看看~ 『CI/CD进阶路线/相关实践 』 The Continuous Delivery Maturity Model 如何评估 CI / CD 导入的狀況如何？The Continuous Delivery Maturity Model 是个不錯的 CI/CD 技能升级线路，參考一下吧(via : @InfoQ ) <img src="http://7xsn88.com1.z0.glb.clouddn.com/image/8/85/f5071b163e0820ac392685b6826cd.jpg" width = "100%" alt="flow.ci" align=center/> 微店MySQL自动化运维实践 微店实现的MySQL自动化运维体系能够解决规模化的痛点，主要包括实例创建、部署、监控、备份、HA切换、迁移、扩容等的自动化，所有模块的主发点是要能“自动化”的方式运作，尽量少的人为参与。（via :微店技术团队公众号）

原文首次发布与 flow.ci Blog >> 链接 ，转载请联系:) 准备了很久，CI Weekly 第一期终于来了。 CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外关于持续集成、持续交付，持续部署、自动化测试、devops、敏捷开发等实践教程、资源与工具，以及一些工程师文化相关的程序员 Tips。 同时，CI Weekly 会坚持每周发布一期精选文章，每一期的文章尽量围绕 CI 相关的 topic 展开，在 flow.ci 微信公众号、官方微博，知乎专栏，简书等同步更新，欢迎关注或投稿:) 第一期篇幅有点长，内容丰富，请准备好开启新的技术旅途~ 『 持续集成相关实践教程 』 ## 使用GitLab来实现IOS项目的持续集成CI 这篇文章讲述了持续集成和交付/部署（CI/CD）方面的一些基础知识，集合APP开发中遇到的一些问题，优化产品打包、测试过程。（via : 简书cjzhao ） ## Jenkins+GitHub+Xcode+fir搭了一个持续集成环境 使用Jenkins+GitHub+Xcode+fir搭建持续集成环境，过程记录很详细。（via :简书 宣X_x ） ## Android CI with docker *develop -> commit -> build -> test -> ( deploy) -> repeat

随着软件部署的越来越成熟，敏捷、DevOps、CI/CD、Docker 等词语慢慢出现在工程师的视野中。对于持续集成，业界也没有一个通用的模式，每个团队可能习惯的方式和关注点都不一样。持续集成最关键的在于「持续」与「自动化」，这篇文章根据这两个关键点，将 CI 系统分为四个进阶过程，来看看你们的团队处在哪个阶段。 第一进阶 — 代码级别的集成，这是最初的持续集成 在最初的持续集成过程中，不依赖独立的持续集成工具，一般语言的 build 工具基本内置，比如 java 的maven/gradle/ant/ivy，c/c++ 的make /premake，同时也会加入代码风格检查，静态代码分析，单元测试调用，测试覆盖率检查等增强功能。接下来的交付准备环境、运行测试、备份旧版本、新版本打标签以及反馈机制等其他重复的事情全由手工完成 ，会花费很多时间。 第二进阶 — 集成 Workflow，基本实现了真正的持续集成 单一的编译-构建工具逐渐地不能满足产品快速交付的需求。 整个开发流程的重心从「代码级别的集成」转移到了 更自动化地编译 和 更完美的测试验证 ，致力于在最短的时间内发现问题，缩短开发周期，提高软件质量。比较常见的一个场景，某个团队先进行代码 Build，触发单元测试、集成测试，打包测试完毕后再自动部署到测试环境，循环往复，形成「编译-构建-测试-集成-部署到测试环境」的

CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外持续集成、持续交付，持续部署、自动化测试、 DevOps 等实践教程、工具与资源，以及一些工程师文化相关的程序员 Tips 。同步于 flow.ci Blog、微信公众号、 官方微博 ， 知乎专栏 ， 简书 ，欢迎关注或投稿:) 上周，我们对 flow.ci 做了比较多的功能优化: 1、iOS 项目持续集成 iOS 项目支持 Carthage 依赖管理； 去除 iOS 项目中自动管理证书设置，防止 Xcode8 编译失； 解决 xcodebuild 接口返回数据问题； 2、代码仓库授权 代码仓库重新授权优化； 分支处理优化； 3、其他 增加在线问题反馈； Build 邮件问题 Bug 修复； 任务的 Step 状态显示问题修复； 详细见 更新日志 ，有问题可通过「在线消息」或去 Gitter群 反馈 :) 本期 CI Weekly 整理了关于微服务架构下的持续部署与交付、自动化测试、DevOps相关的技术实践，欢迎提出意见~ 『 Docker/ 持续集成/持续部署相关实践 』 微服务架构下的开发部署实践 本文将从以下几个方面简要说明微服务架构项目的实践经验：架构选型、开发测试环境下的相关工具支持、人员分工及开发部署流程、相关设计及注意事项。 （via : 知乎： 无为2016 ）

原文首发于 flow.ci Blog >> 链接 ，转载请联系:) CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外持续集成、持续交付，持续部署、自动化测试、 devops 等实践教程、工具与资源，以及一些工程师文化相关的程序员 Tips 。同步于 flow.ci Blog、微信公众号、 官方微博 ， 知乎专栏 ， 简书 ，欢迎关注或投稿:) 说到创业团队的项目研发和管理实践，有很多很有价值的『经验之谈』。本期收集了一些团队的持续集成、部署、自动化测试相关的工具与实践分享，来看看吧~ 『 持续集成相关实践 』 聊聊创业团队的项目管理如何面向开发人员优化 这篇文章涉及开发环境搭建，代码管理，需求生命周期管理，项目进度管理，研发阶段的产品测试和反馈，持续集成和持续发布等等，分享了其中的一些管理经验和工具分享，非常实用！（ via : @wangchao0721 ） 浅谈GRAB的持续集成和持续部署 作者zhchang在gopher china 2016大会上面做了个关于 GRAB 的持续集成和持续部署(CI/CD)的分享。（via: zhchang ） Continuous Integration & Deployment for iOS Projects 关于 iOS 项目的持续集成与管理，中文翻译版见 这里 .（via: Twitter[

什么是 CI/CD？ 在软件开发中经常会提到持续集成Continuous Integration（CI）和持续交付Continuous Delivery（CD）这几个术语。但它们真正的意思是什么呢？ 在本文中，我将解释这些和相关术语背后的含义和意义，例如持续测试Continuous Testing和持续部署Continuous Deployment。 工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为运维开发DevOps践行者。 “持续”用于描述遵循我在此提到的许多不同流程实践。这并不意味着“一直在运行”，而是“随时可运行”。在软件开发领域，它还包括几个核心概念/最佳实践。这些是： 频繁发布 ：持续实践背后的目标是能够频繁地交付高质量的软件。此处的交付频率是可变的，可由开发团队或公司定义。对于某些产品，一季度、一个月、一周或一天交付一次可能已经足够频繁了。对于另一些来说，一天可能需要多次交付也是可行的。所谓持续也有“偶尔、按需”的方面。最终目标是相同的：在可重复