持续集成

最近在做一个团队项目的时候，用到了自动编译发布部署环境【也可以说是持续集成】，于是顺便学习了下这个环境的搭建过程。 持续集成 　　持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。 1、持续集成系统的组成 　　一个完整的构建系统必须包括： 1) 一个自动构建过程，包括自动编译、分发、部署和测试等。 2) 一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。 3) 一个持续集成服务器。 其中1)自动构建和2)代码存储库，都是有相应的软件配合，开发人员需要的学习成本不高，复杂在各模块的相互配合，这一期间可能需要大量时间去调试。一旦调试完毕，对于之后工作效率的提升是成倍的。 2、MSBuild 　　自动构建，做.Net开发的同仁相信大多数都会使用VS，而Visual Studio用MSBuild构建.NET项目。 MSBuild所需的仅仅是一个脚本，在脚本中指定要执行的target；项目中的.csproj和.vbproj 文件都是MSBuild脚本。当编写好MSBuild脚本后，只需要一条简单的命令，即可实现代码的编译与测试工作 。 参考： [独孤九剑]持续集成实践 – MSBuild语法入门

简介 本文将介绍如何通过微软的Team Foundation Server平台，结合Docker完成程序的持续集成、持续部署。这里小编以.NET Core为例向大家分享整个DevOps流水线的搭建过程以及思路，其他语言平台均适用。 作者：周文洋 LEANSOFT研发总监，认证 Scrum Master，曾为多家客户提供微软Team Foundation Server实施咨询、二次开发、报表定制等服务，包括：中国农业银行， 博时基金， 斯伦贝谢， 京东商城，国电南自等，现负责公司核心产品的开发工作。 流水线概述 开发人员编写代码，并提交代码到TFS配置库(Git \ TFVC), 触发持续集成。 构建代理服务器拉取最新代码到服务器， 通过Docker容器完成应用的编译、测试工作 ，并生成镜像推送到镜像仓库，最后 更新 docker-compose.yml镜像版本 并回传到TFS Build Artifact, 触发持续部署。 构建代理服务器根据目标环境， 替换docker-compose.yml内的环境变量 ，并复制docker-compose.yml文件到目标环境，运行应用。 流水线拓扑图 项目配置 在配置TFS持续集成之前，需要先在项目根目录下添加如下几个文件，每个文件独立分工，各负其责，以便我们完成后面的持续集成，持续部署。大家可以根据自己的实际需求来增减。

Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作， 旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。 Jenkins是可扩展的持续 集成、交付、部署 （软件/代码的编译、打包、部署）的基于web界面的平台。 允许持续集成和持续交付项目，无论用的是什么平台，可以处理任何类型的构建或持续集成。 Jenkins功能包括： 1、持续的软件版本发布/测试项目。 2、监控外部调用执行的工作。 Jenkins 只是一个平台，真正运作的都是插件。这就是jenkins流行的原因，因为jenkins什么插件都有 Hudson 是Jenkins的前身，是基于Java开发的一种持续集成工具，用于监控程序重复的工作， Hudson后来被收购，成为商业版。 后来创始人又写了一个 jenkins ，jenkins在功能上远远超过hudson 来源： https://www.cnblogs.com/centos2017/p/12165313.html

持续集成就是快速且高频率地自动构建项目的所有源码，并为项目成员提供丰富的反馈信息。 一次完整的集成往往会包括以下6个步骤： 　　持续编译：所有正式的源代码都应该提交到源码控制系统中，持续集成服务器按一定频率检查源码控制系统，如有新的代码，就出发一次集成，旧的已编译的字节码应当全部清除，然后服务器编译所有最新的源码 　　持续数据库集成：在很多项目中，源代码不仅仅值Java代码，还包括了数据库SQL脚本。每次发现新的SQL脚本。就应该清理集成环境的数据库，重新创建表结构，并填入预备的数据 　　持续测试：单元测试和集成测试都应该在每次集成的时候运行，并且在发生问题的时候能产生具体报告 　　持续审查：持续集成可以使用Checkstyle和PMD之类的工具来生成个类报告，当审查发现问题时，可以给开发人员反馈警告信息 　　持续部署 　　持续反馈：将集成失败报告发送给这次集成相关的代码提交者，项目经理应该受到所有失败报告 持续集成的好处：尽早暴露问题；减少重复操作；简化项目发布；建立团队信心 在创建Hudson持续集成任务之前，用户需要对Hudson系统做一些基本的配置，包括JDK安装位置和Maven安装等在内的重要信息都不必须首先配置正确。 对于一般的Maven项目，可选择的类型有Build a free-style software project和Build a maven2

一、配置背景： 要想介绍Hudson，就要从持续集成开始介绍。持续集成，最开始知道有这个概念的时候是从一本叫做《.NET中的持续集成》，但是本人熟悉的是Java，而不是.Net平台，所以这本书就放下了，没有仔细的看。如今，我们需要用SSH架构开发一个知识管理平台，项目组长给我的任务恰好就是配置持续集成的开发环境。 说了这么半天看来是有点跑题了，还是没有说持续集成是个什么概念。所谓持续集成（Continuous integration）就是：持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。 上述定义是来源于软件大师：马丁福勒（Martin Fowler），大师就是大师，反正我没看懂。我来说说我的理解，在这里，我用举一个例子来说吧…… 现在我们已经进行完了前期的工作（包括：需求的确定，原型的设计等等），到了开始编程的阶段了，我们现在很少有孤军奋战的了吧？大多是小组内各个成员进行配合，编写系统，这样就有个问题，大家的编程环境可能出现差距

前面介绍了Jenkins的安装，这篇博客记录一下Jenkins的使用，这里我是用git拉取代码，用ant构建，项目还是之前写过的QQ邮箱。 1.Jenkins里面要想使用Git，ant必须要安装插件，在available里面找到Git plugin和ant plugins,并安装。因为我已经安装过了，所以在Installed里面可以直接看到 2.全局工具配置，要把使用的工具配置到Jenkins里面。这里我只配置了JDK，ANT，GIT，因为只用到了这几个，位置都是他们的安装位置。 3.新建项目 输入项目名，选择自由风格，点击OK 输入github的源码地址，上篇讲过如何将代码上传到git仓库 选择之前设置的ant和JDK 构建的时候，选择Execute Windows batch command,输入ant命令 在这个过程中也可以选择定时执行，执行完后发邮件等配置 4.构建项目 Build History里面就显示构建过程了 点击进入 这里看到自动化测试执行成功了，但是没有打开浏览器执行 来源： CSDN 作者： woshiweiweily 链接： https://blog.csdn.net/woshiweiweily/article/details/103799314

Composer Repositories Composer源 Firegento - Magento模块Composer源 Packagist - PHP包的源 PaketHub - 集成的PHP包的源 Private Packagist - 一个PHP的服务，提供Composer包的存储 WordPress Packagist - 使用Composer管理你的WordPress插件 Zend Framework Packages - Zend Framework Composer源 依赖管理 Dependency Management 依赖和包管理库 Composer Installers - 一个多框架Composer库安装器 Composer - 一个包和依赖管理器 Melody - 一个用于构建Composer脚本文件的工具 Pickle - 一个PHP扩展安装器 其他的依赖管理 Dependency Management Extras 其他的相关依赖管理 Composed - 一个在运行时解析你项目Composer环境的库 Composer Checker - 一个校验Composer配置的工具 Composer Merge Plugin - 一个用于合并多个composer.json文件的Composer插件 Composition -

What is Travis CI? Travis CI CI(Continuous Integration)翻译为持续集成。Travis CI是一个提供持续集成功能的平台，在Github上，可以添加Travis CI，当有code push时候，会推送通知到Travis，根据设置的脚本运行指定任务。 目前有两个站点: Travis.org 对于所有public项目完全免费 Travics.com 只针对private项目，提供更多一些额外功能，如cache，并行build个数 两个站点只能看到各自的项目，不能通用。 Why we need Travis CI? 有人可能会有疑问: 在本地写完博客，直接一个命令hexo d，不就搞定了么， 为啥要费力搞CI？ 的确, 想用TravisCI来自动部署Hexo博客程序，需要不少设置（瞎折腾），为了给大伙信心，列举一些优点： 优点1：直接在线编辑文件，立即生效 假设你已经发表了一篇文章，过了几天你在朋友机器上浏览发现有几个明显的错别字，对于有强迫症的，这是不能容忍的。 但你手头又没有完整的hexo+nodejs+git的开发环境，重新下载git，node，hexo配置会花费不少时间，特别不划算。 如果按照这篇完整折腾完，你可以直接用浏览器访问github个人项目仓库，直接编辑那篇post的原md文件，前后2分钟改完。 稍等片刻

https://blog.csdn.net/tq08g2z/article/details/79718425 https://www.jianshu.com/p/3507d8b2ac87 报错用下面解决 https://blog.csdn.net/xukangkang1hao/article/details/80756085 https://blog.csdn.net/cdnight/article/details/81078191 很全面解决各种问题，ssh登不上问题 结合上面三篇做成的 大致流程如下 1、 安装环境 192.168.0.76 jenkins git maven JDK 192.168.0.74 gitlab 192.168.0.72 tomcat JDK 2、配置工具 git maven JDK 这三个工具配置到 jenkins的 “全局工具配置” 里面 如何找路径：系统管理-全局工具配置 3、连接gitlab，gitlab的url写到 jenkins项目配置里面 的git 选项 4、创建项目配置项目 5、编写pom文件开始构建 来源： https://www.cnblogs.com/effortsing/p/10013447.html

GitLab+Jenkins持续集成+自动化部署 什么是持续集成？ （1）Continuous integration （CI） 持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。 （2）没有持续集成 项目做模块集成的时候，发现很多接口都不通==>浪费大量时间 需要手动去编译打包最新的代码==>构建过程不透明 发布代码，上线，基本靠手工==>脚本乱飞 （3）持续集成最佳实践： 维护一个单一的代码库 使构建自动化 执行测试是构建的一部分 集成日志及历史记录 使用统一的依赖包管理库 每天至少集成一次 熟悉Jenkins 如何安装Jenkins此文省略，可参考 安装文档 （1）登录Jenkins webUI界面创建第一个项目 （2）输入项目名称(My-freestyle-job)并选择构建一个自由风格的软件项目 （3）上面创建完成后跳转进来后进行配置，选择丢弃旧的构建（下面保持天数一般在5~7天即可） （4）接着上面选择构建，然后选择Execute Shell 来执行shell命令 （5）既然能执行shell命令，那么我们执行一个pwd