ci

Pipeline 介绍 要实现在 Jenkins 中的构建工作，可以有多种方式，我们这里采用比较常用的 Pipeline 这种方式。Pipeline，简单来说，就是一套运行在 Jenkins 上的工作流框架，将原来独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排和可视化的工作。 总体架构 在开始我们的工作之前，让我们花一点时间分析开始使用Jenkins使用Kubernetes容器所需的工作流。Kubernetes对于开发者来说是一个惊人的开源容器编排引擎。Kubernetes是由Google发起的，这使Kubernetes在使用多个开源容器项目方面有一个惊人的优势。默认情况下，Docker更受Kubernetes的使用者支持和青睐。使用Docker容器的工作流程如下图所示： k8s Jenkins构建持续集成流程 Docker技术这些应用场景 参考文档: https://blog.csdn.net/xiegh2014/article/details/80456486 部署准备 gogs代码管理 git服务器安装参考：https://blog.csdn.net/xiegh2014/article/details/81434421 Harbor镜像管理 持久化存储 NFS安装 1、使用yum源安装 yum -y install nfs-utils -y

gitlab 的 CI/CD 配置管理 （二） 标签（空格分隔）：运维系列 一：gitlab CI/CD 介绍 二：配置gitlab的CI/CD 的runner 三：代码的MAVEN打包环境 四：配置gitlab的CI 文件 五：发布项目 一： gitlab CI/CD介绍 1.1 gitlab CI/CD概述 Gitlab是常用的开源git代码管理工具之一，随着发展也推出了ci/cd解决方案． 顾名思义具体来说ci/cd主要完成以下两个工作． ci(持续构建) 代码提交后触发自动化的单元测试，代码预编译，构建镜像，上传镜像等． cd(持续发布) 持续发布则指将构建好的程序发布到各种环境，如预发布环境，正式环境． 官网： https://docs.gitlab.com/ee/ci/README.html 1.2 特性 gitlab ci/cd是由独立的runner程序完成，runner采用go语言编写，因此可以很好的进行跨平台，通常可以将runner部署到任何gitlab server之外的服务器，从而避免对gitlab server的影响． 官网：https://docs.gitlab.com/runner/ 二：配置gitlab的CI/CD 的runner 2.1 安装gitlab-runner 参考： https://docs.gitlab.com/runner

一.什么是CI,CD ​ 当我们在谈论现代的软件编译和发布流程的时候，经常会听到CI 和CD这样的缩写短语。CI很容易理解，就是持续集成。 ​ 但是CD既可以指代码持续交付，也可理解为代码持续部署。CI和CD之间有很多相似的部分，但是也有很大的区别。 它们之间的区别和联系。 1. 持续集成（CONTINUOUS INTEGRATION） 在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。 这样做是基于之前持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。 2. 持续交付（CONTINUOUS DELIVERY） 持续交付就是讲我们的应用发布出去的过程 。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。通过持续交付， 您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。 但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。 3. 持续部署（CONTINUOUS DEPLOYMENT） 如果我们想更加深入一步的话，就是持续部署了。通过这个方式

Continuous Integration, Continuous Delivery & Deployment (CI/CD) 持续集成、持续部署&持续交付。 Jenkins就是一个持续集成的工具，开源的，基于 JAVA语言的，需要安装jdk。 jenkins部署.net平台自动化构建 　　在引入自动化部署工具的时候，我们对比了jenkins和gitlab CI，jenkins有非常丰富的插件，配置起来方便。gitlab CI更倾向于脚本配置，当然jenkins也可以使用pipeline实现全脚本化配置（everything is code，哈哈）。我们这里主要讲述jenkins的自动化部署。 　　基本组合是jenkins+git+msbuild+python，实现从代码仓库拉取、编译、打包、部署、自动化测试。（.net core和framework4.6.1可以不依赖msbuild构建，将在下一篇文章中讲述） 一、安装环境 1.jenkins是java生态圈的产品，需要安装jdk 2..net项目依赖.net framework,安装需要的framework版本（如framework4.5.1） 3.安装构建工具msbuild 4.安装nuget 5.安装jenkins 二、配置jenkins 1.安装好jenkins后，进入“系统管理”->“插件管理”

##1.安装 虽然想直接安装到centos上，但考虑学习配置，就先从windows开始。登陆 Jenkins官方网站 下载最新的版本。选择版本的时候下意识的就打开下拉箭头选择了windows。这是个美丽的错误，应该选择war的。 一路安装结束后，启动8080发现已经ok了，然而我并不想要占用8080端口，于是寻找配置端口的地方。百度出来的大多数的Jenkins博客也都是简单介绍，而且多是用war来启动的，使用war启动可以设置端口： java -jar jenkins.war --httpPort=$HTTP_PORT . 然后再安装为windows服务。而我下载的msi一步到位了。又去百度了，没能找到合适的。自己去翻安装好的路径下的配置文件'D:\Program Files (x86)\Jenkins\jenkins.xml'。果然在这里： <service> <id>Jenkins</id> <name>Jenkins</name> <description>This service runs Jenkins continuous integration system.</description> <env name="JENKINS_HOME" value="%BASE%"/> <!-- if you'd like to run Jenkins with a specific

ZTEsoft-方进 1、基于Jenkins的CI过程 一切要从2013年4月开始说起，当我4月份从委内瑞拉回来之后立即投身到国内一个运营商的大型后端建设项目的尾声中（项目历时3年多，当时已经接近尾声），这个项目涉及100多台主机，包含数十个集群，除了传统的WEB应用外，还用到了流程引擎、ESB、规则引擎、搜索引擎以及缓存和日志，是当时比较复杂的体系结构（当然不能跟现在的云平台相比，但在项目开始的年代这还是一个很不错的架构），整个项目当时一两百号人占了局方整整一层楼十几个办公室，我到了项目组之后成为了一个小组的小头目，管个四五个人，小组美其名曰“平台组”，干的都是打杂的事情，包括编译、打包、部署，日常监控以及系统优化等工作，说起来简单，做起来还是很复杂的，当时所有的工作基本上是靠人工的，可想而知，100来台机器的环境一台一台的部署环境，还得靠人工监控，手工检查，四五个到处救火忙得不可开交，当时我虽然还不知道CI为啥物（压根儿就没这个概念），但也下定决心要改变忙乱的状态，累一点不要紧，但是累得跟狗似的还干不好那就白辛苦了。 在2013年的4~8月份，我们主要研究的是自动编译、打包和发布，采用的基本方式是各种脚本，包括windows下的批处理bat、Linux上的shell甚至Python，虽基本上完成了自动从SVN取代码、自动编译

万合ITGo是一款虚拟化运维管理工具，为虚拟化管理员提供虚拟化环境的监控、操作和管理功能。而CMDB是企业的配置管理数据库，讲的是配置项和配置项之间的关系，和传统运维工具不太搭界，可是今天偏偏要说说ITGo和CMDB这两者之间的关系： ITGo可以为CMDB提供虚拟化（例如VMware）环境完整的配置项 ITGo可以为CMDB提供虚拟化环境的配置项之间的关系 企业数据中心，虚拟机的数量可以几百台到几千台，这样对于CMDB项目建设来说，虚拟化CI项的采集是面临的第一个问题，CI之间的关系梳理是第二个问题，CMDB项目建设完成，如何保证虚拟化环境CI和CIR的实时准确性是第三个问题。 有了ITGo，这些都不是问题，这些数据都是实时更新的。ITGo有API接口，可以将梳理出来的配置项和配置关系提供给CMDB使用，降低CMDB建设和维护的难度。 来源： https://blog.51cto.com/031028/2432923

持续集成是一项“一次配置长期受益”的投入，让开发、测试、生产环境的统一变得更加自动高效。 本期 fir.im Weekly 收录了关于 Android、iOS 持续集成的最新实践分享，也有一些开发工具、源码和 UI 动画的分享。 iOS搭建CI持续集成环境 @大慈大悲大熊猫 写的这篇文章总结了自己在 iOS 下的自动化打包，搭建可持续集成环境的实践过程，选择方案是 Jenkins+ Gitlab/Github+Xcode+Fir。文章 传送门 . 对比学习下， @宣X_x 的这篇文章，用 Jenkins+GitHub+fir-cli 搭建持续集成环境 ，看看哪个更适用于你。 使用DaoCloud与FIR.im为CodingAndroid项目开启持续集成的尝试 @痕迹BLANK 把持续集成环境搭建在 DaoCloud 上，通过几步就可以实现 CodingAndroid 项目自动提交，自动编译发布测试包到 fir.im 上。这是一套很新鲜的玩法，感兴趣地可以尝试一下，文章地址☞ http://www.jianshu.com/p/a6ebb0e0c5ae . icon-font-for-multiple-platforms 由 @廖祜秋liaohuqiu_秋百万 分享。 “开源一个项目。我们经常会在项目中使用 Icon Font，比如 Font Awesome。最近做一个项目

英文原文 从2.2 升级到3.0 更新之前先保证网站处于离线状态. 步骤 1: 更新 CI 所有文件 替换 system 目录下所有文件,然后替换index.php文件,如果之前有更新index.php,请在新的文件上做更改. 你必须先删除旧的system/目录，然后把它放到其它 的地方.直接简单的复制过去可能会导致问题. 如果您在这些文件夹中有任何自定义功能的文件，请先复制它们. 步骤 2: 更新你的类的文件名 从CI 3.0开始,所有的类文件名(库,驱动,控制器,模型)必须首字母大写的形式,必须大写字母开头. 例如: application/libraries/mylibrary.php 需要更改成 application/libraries/Mylibrary.php 同样的有,驱动库,扩展和对CI 核心库的扩展 application/libraries/MY_email.php application/core/MY_log.php 上述文件应分别改名为以下: application/libraries/MY_Email.php application/core/MY_Log.php 控制器: application/controllers/welcome.php -> application/controllers/Welcome.php 模型: application

当我们使用术语"类库"时,我们一般指的是位于libraries 文件夹中的类,它们在wiki的"类库参考"这个板块被讨论.在当前这个话题中,我们将讨论如何在 application/libraries 文件夹中建立你自己的类库,并使它们与全框架的资源维持分离. 作为一个额外的功能,当你需要在原始类中简单地添加一些功能时,CodeIgniter能使你的类库extend 自原始类.你甚至可以通过在application/libraries文件夹下安放同名类库文件的方法来完全替换原始类. 总之: 你可以创建全新的类库. 你可以扩展原始类库. 你可以替换原始类库. 以下页面将深入介绍这三个概念. 注意: 除了数据库类无法被扩展或替换，剩余其他类均可。 建立你的类库文件 你的类库文件必须保存在 application/libraries 文件夹,CodeIgniter将在这个文件夹中寻找并初始化它们. 命名约定 文件名首字母大写. 例如: Myclass.php 类声明首字母大写. 例如: class Myclass 类的名字和文件名应符合. 类文件 所有的类应有基础原型(注意,这里我们以 Someclass 这个名字为例): <?php if (!defined('BASEPATH')) exit('No direct script access allowed'); class