[独孤九剑]持续集成实践(一)- 引子

本系列文章包含:

[独孤九剑]持续集成实践(一)- 引子

[独孤九剑]持续集成实践(二)– MSBuild语法入门

[独孤九剑]持续集成实践(三)- Jenkins安装与配置(Jenkins+MSBuild+GitHub)

1、概念描述(了解的话直接跳到第2部分)

1.1、我的理解

持续集成(Continuous Integration),以自动化方式实现“从开发阶段性完毕到部署上线之前”这一阶段的工作。当然也可做到简单部署,复杂的要涉及到持续部署阶段。

1.2、理论层面的描述

下面为摘抄各网站的定义:

百度:持续集成是一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

搜狗:持续集成是指开发阶段,对项目进行持续性自动化编译、测试,以达到控制代码质量的手段。持续集成是一种软件开发实践。

1.3、应用与组成

在敏捷开发过程中,持续集成的使用尤为频繁。而每次的集成都是通过自动化的构建来验证,包括自动编译、发布和测试,从而尽快地发现集成错误,让团队能够更快的开发内聚的软件。

1.3.1、持续集成的核心价值

持续集成的核心价值在于:

1) 持续集成中的任何一个环节都是自动完成的,无需太多的人工干预,有利于减少重复过程以节省时间、费用和工作量;

2) 持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之,任何时间点都能第一时间发现软件的集成问题,使任意时间发布可部署的软件成为了可能;

3) 持续集成还能利于软件本身的发展趋势,这点在需求不明确或是频繁性变更的情景中尤其重要,持续集成的质量能帮助团队进行有效决策,同时建立团队对开发产品的信心。

1.3.2、持续集成的原则

业界普遍认同的持续集成的原则包括:

1) 需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 IBM Rational ClearCase、CVS、Subversion 等;

2) 开发人员必须及时向版本控制库中提交代码,也必须经常性地从版本控制库中更新代码到本地;

3) 需要有专门的集成服务器来执行集成构建。根据项目的具体实际,集成构建可以被软件的修改来直接触发,也可以定时启动,如每半个小时构建一次;

4) 必须保证构建的成功。如果构建失败,修复构建过程中的错误是优先级最高的工作。一旦修复,需要手动启动一次构建。

说了不少废话,现在开始上干货。

2、正文

2.1、持续集成系统的组成

一个完整的构建系统必须包括:

1) 一个自动构建过程,包括自动编译、分发、部署和测试等。

2) 一个代码存储库,即需要版本控制软件来保障代码的可维护性,同时作为构建过程的素材库。

3) 一个持续集成服务器。

其中1)自动构建和2)代码存储库,都是有相应的软件配合,开发人员需要的学习成本不高,复杂在各模块的相互配合,这一期间可能需要大量时间去调试。一旦调试完毕,对于之后工作效率的提升是成倍的。

2.2、MSBuild

自动构建,做.Net开发的同仁相信大多数都会使用VS,而Visual Studio用MSBuild构建.NET项目。MSBuild所需的仅仅是一个脚本,在脚本中指定要执行的target;项目中的.csproj和.vbproj 文件都是MSBuild脚本。当编写好MSBuild脚本后,只需要一条简单的命令,即可实现代码的编译与测试工作。下面将介绍MSBuild的基本语法。

[独孤九剑]持续集成实践 – MSBuild语法入门

虽然MSBuild实现了自动编译与测试,但是在调用MSBuild时,我们还是通过输入命令进行调用的,这里掺杂了人工干预的成分,因此要将这部分工作剔除。

2.3、版本管理

目前主流的版本管理有传统的SVN、分布式的Git和Mercurail各有利弊,自行选择。

【资料中使用的是Mercurail,我以前没用过,也懒得配环境学习了;我使用的是Git,why?因为有GitHub(可以在线托管,嘿嘿;当然,如果是局域网环境,可以自己搭建版本管理服务器,Git、SVN、Mercurail随你喜欢)。如果你知道其他好用的在线版本管理工具,请一定要留言给我,让我学习下。】

2.4、Jenkins

Jenkins是一个开源项目,提供了一种易于使用的持续集成系统,使开发者从繁杂的集成中解脱出来,专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误,提供详细的日志文件和提醒功能,还能用图表的形式形象地展示项目构建的趋势和稳定性。下面将介绍 Jenkins 的安装与配置。

[独孤九剑]持续集成实践 - Jenkins安装与配置

Jenkins配置好了,以后每次变更代码,提交新的版本后,Jenkins都会自行执行单元测试,在其设置页面,还可以根据需要将运行报告发送给指定的人,方便跟踪。

3、最后

整个的部署实际上无需花费过多时间,而且如果已搭建好持续集成服务器,那么每次新增的只是一个Job以及它的配置。麻烦的就是在刚学习时,会出现各种难以预料的问题,有时会是一个简单的拼写错误,有时可能是版本等问题导致你所看到的资料所描述的,与你实际搭建的环境所需要的不一致,因此就需要自己学会排查、解决这些问题。总的来说,持续集成是个好东西。

时间: 2024-10-24 02:31:11

[独孤九剑]持续集成实践(一)- 引子的相关文章

[独孤九剑]持续集成实践 – MSBuild语法入门

本系列文章包含: [独孤九剑]持续集成实践(一)- 引子 [独孤九剑]持续集成实践(二)– MSBuild语法入门 [独孤九剑]持续集成实践(三)- Jenkins安装与配置(Jenkins+MSBuild+GitHub) 本文是转发“用MSBuild和Jenkins搭建持续集成环境”,由于该文内容十分清晰,我就不再画蛇添足的再写一篇了.只是其中会夹杂一些个人的理解,如果各位看官介意,请移步至原文. 1.开始 在这篇文章中,我们会从头开始,一步步完成一个属于我们自己的MSBuild脚本.在它完成

持续集成实践

持续集成实践(一)- 引子 本系列文章包含: [独孤九剑]持续集成实践(一)- 引子 [独孤九剑]持续集成实践(二)– MSBuild语法入门 [独孤九剑]持续集成实践(三)- Jenkins安装与配置(Jenkins+MSBuild+GitHub) 1.概念描述(了解的话直接跳到第2部分) 1.1.我的理解 持续集成(Continuous Integration),以自动化方式实现“从开发阶段性完毕到部署上线之前”这一阶段的工作.当然也可做到简单部署,复杂的要涉及到持续部署阶段. 1.2.理论

基于Jenkins Pipeline的ASP.NET Core持续集成实践

原文:基于Jenkins Pipeline的ASP.NET Core持续集成实践 最近在公司实践持续集成,使用到了Jenkins的Pipeline来提高团队基于ASP.NET Core API服务的集成与部署,因此这里总结一下. 一.关于持续集成与Jenkins Pipeline 1.1 持续集成相关概念 互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称 CI) . 持续集成指的是,频繁地 (一天多次) 将代码集成到

基于Jenkins的开发测试全流程持续集成实践

今年一直在公司实践CI,本文将近半年来的一些实践总结一下,可能不太完善或优美,但的确初步解决了我目前所在项目组的一些痛点.当然这仅是一家之言也不够完整,后续还会深入实践和引入Kubernetes进行容器编排,以及通过阿里云K8S服务进行高效的云上托管,希望对各位童鞋有一点用. 一.持续集成全流程介绍 今年一直在开发我司的一个核心业务系统,一个还未上线的产品开发阶段,其中后端采用ASP.NET Core + 一系列开源组件开发微服务并且部署在Linux Docker中,前端采用React + Fl

Artifactory & GitLab CI持续集成实践

GitLab CI支持创建多个构建,并评估每次代码提交是否通过测试和以及对您产品的影响.在构建过程中,会生成大量二进制文件,如果不能正确的大规模管理这些文件,就会导致二进制文件管理混乱.为了克服这个问题,Artifactory被无缝地集成到GitLab CI构建过程中,以便更好的发布和管理这些二进制文件,并通过JFrog CLI, GitLab CI缓存.发布您的依赖包.制品包和构建信息到Artifactory. 这篇文章描述了如何将 GitLab CI 与 Artifactory 集成在一起,

Maven实战(四)——基于Maven的持续集成实践

Martin的<持续集成> 相信非常多读者和我一样.最早接触到持续集成的概念是来自Martin的著名文章<持续集成>.该文最早公布于2000年9月,之后在2006年进行了一次修订.它清晰地解释了持续集成的概念.并总结了10条实践,它们分别为: 仅仅维护一个源代码仓库 自己主动化构建 让构建自行測试 每人每天向主干提交代码 每次提交都应在持续集成机器上构建主干 保持高速的构建 在模拟生产环境中測试 让每一个人都能轻易获得最新的可运行文件 每一个人都能看到进度 自己主动化部署 原始文章

Azure云中Web应用的持续集成实践

由于从事的工作领域关系,目前会或多或少的关注DevOps课题的相关领域,当然目前还在尝试多种适应于持续开发持续集成领域的工具和组合方式,个人粗浅的领会是DevOPS其实既不会只是开发者需要关注的,也是运维人员应该关注的领域,因为未来的IT世界其实是个"相对混合"的空间,发展之快超出想象:在开发测试领域的工具上看,Chef/Puppet/PowerShell DSC,到开源领域广泛应用Salt Stack, Ansible到 Docker生态圈等封装一系列基础架构即代码等概念的涌现,无时

Azure云中Web应用的持续集成实践erehge

http://search.kankan.com/search.php?keyword=%E5%B9%B3%E9%A1%B6%E5%B1%B1%E6%89%BE%E6%9C%8D%E5%8A%A1%E7%BE%8E%E5%A5%B3%E7%94%B5%E8%AF%9D185g2057g2220%E8%8E%89%E8%8E%89http://search.kankan.com/search.php?keyword=%E6%B1%9D%E5%B7%9E%E6%89%BE%E6%9C%8D%E5%8

fir.im weekly - 「 持续集成 」实践教程合集

我们常看到许多团队和开发者分享他们的持续集成实践经验,本期 fir.im Weekly 收集了 iOS,Android,PHP ,NodeJS 等项目搭建持续集成的实践,以及一些国内外公司的内部持续集成系统的经验,供大家集中研究,参考借鉴. 先来看看国内外一些公司的实践经验: Continuous Deployment at Instagram Instagram 的开发团队每天保持着 30 - 50 次后端代码部署,几乎全程无人参与,完全自动化.这听起来很疯狂,但一切确实在这样运转.来这里看看