《配置管理最佳实践》——2.11 持续集成与每日构建

持续集成是一个相当流行的软件开发实践。现在，人们时常把持续集成和敏捷开发联系到一起。实际上，即使开发团队使用的不是敏捷开发的过程, 持续集成在他们之间也已经非常流行。另外一个很明显的现象是很多研发团队并不需要签入构建（commit build, check-in build），也就是说并不需要每次有代码签入代码库都要立刻触发一个构建。

本节书摘来自异步社区《配置管理最佳实践》一书中的第2章，第2.11节，作者： 【美】Bob Aiello , Leslie Sachs著，更多章节内容可以访问云栖社区“异步社区”公众号查看

2.11 持续集成与每日构建

持续集成是一个相当流行的软件开发实践。现在，人们时常把持续集成和敏捷开发联系到一起。实际上，即使开发团队使用的不是敏捷开发的过程, 持续集成在他们之间也已经非常流行。另外一个很明显的现象是很多研发团队并不需要签入构建（commit build, check-in build），也就是说并不需要每次有代码签入代码库都要立刻触发一个构建。很多时候，每日构建已经足够用了，而且也容易实现。持续集成经常会发起很多没必要的失败构建，导致显示面板上出现很多没必要的失败记录。某些构建可能需要几个小时才能完成，这时持续的构建就会导致一个很长的构建队列，最终使有些构建无法完成。在我工作过的公司，我认为选择每日构建可能会更好。我的观点是尽可能采取更轻量级的流程。恰好够用的过程改进是我最推崇的，这也是建立有效开发过程最实际最直接的方法。

利用 Rainbond 云原生平台简化 Kubernetes 业务问题排查 Kubernetes 已经成为了云原生时代基础设施的事实标准，越来越多的应用系统在 Kubernetes 环境中运行。Kubernetes 已经依靠其强大的自动化运维能力解决了业务系统的大多数运行维护问题，然而还是要有一些状况是需要运维人员去手动处理的。那么和传统运维相比，面向 Kubernetes 解决业务运维问题是否有一些基本思路，是否可以借助其他工具简化排查流程，就是今天探讨的主题。
Devops 开发运维高级篇之微服务持续集成代码上传和代码检查 微服务持续集成(1)-项目代码上传到Gitlab 微服务持续集成(2)-从Gitlab拉取项目源码 微服务持续集成(3)-提交到SonarQube代码审查
微服务项目部署实践：使用Gitlab Runner实现微服务项目的持续集成，持续交付和持续部署 本文通过详细的步骤一步一步说明在微服务架构的项目中如何进行项目部署的操作实践，通过Gitlab实现项目的持续集成，持续部署和持续交付。详解介绍的Gitlab中实现项目持续部署的工具GitLab Runner的具体使用步骤。通过这篇文章，可以熟悉微服务项目持续集成，持续交付和持续部署，学会使用GitLab Runner的具体使用方式，极大简化微服务项目的部署。
基于Jenkins的开发测试全流程持续集成实践 本文介绍了我目前团队所在使用的持续集成全流程及一些重要插件的使用，虽然还很不完善，但初步解决了我所在团队在集成和发布上的一些痛点。随着后续对K8S的学习的深入，我会逐步引入阿里云K8S服务（ACK）进行微服务的容器编排以及持续集成的K8S化改造，希望到时再进行分享。
持续集成、持续交付、持续部署简介 怎样去理解集成、交付、部署的概念？首先集成是指软件个人研发的部分向软件整体部分交付，以便尽早发现个人开发部分的问题；交付是指研发尽快向客户交付，以便尽早发现生产环境中存在的问题；部署是代码尽快向可运行的开发/测试节交付，以便尽早测试。
持续集成（三）：最佳实践 本文讲的是持续集成（三）：最佳实践这是持续集成系列的第三篇。在这篇文章里，我们将介绍实现一个CI流程的一些最佳实践。笔者也将会根据自己的行业经验介绍一些真实世界里的提醒和警告。
异步社区 异步社区(www.epubit.com)是人民邮电出版社旗下IT专业图书旗舰社区，也是国内领先的IT专业图书社区，致力于优质学习内容的出版和分享，实现了纸书电子书的同步上架，于2015年8月上线运营。公众号【异步图书】，每日赠送异步新书。