学习资料：拉勾课程《大前端高薪训练营》
 阅读建议：搭配文章的侧边栏目录进行食用，体验会更佳哦。
 内容说明：本文不做知识点的搬运工，技术详情请查看官方文档。
 
 
自动化构建 并不是一个句子，有必要在行文前先说明一下它在本文中的宾语是前端工程。
 
一：认识自动化构建
 
随着前端需求和项目的日益复杂，出于提高开发效率、用户体验以及其它工程上的需要，我们通常会借助很多更高阶的语法或者工具来帮助我们更快更好的开发、部署一个前端工程。
 
那么如何理解构建以及自动化构建呢？个人观点，简单务实点说，构建就是指项目从源代码到一个能按需运行的工程（开发环境、生产环境）所需要做的所有事情。通常来说，项目多次构建的每次构建过程都包含很多任务并且基本一致，按照任何简单机械的重复劳动都应该让机器去完成的思想，我们应该自动化去完成工程的构建，提高构建效率。
 
那么如何实现自动化构建呢？个人理解，前端工程构建其实就是一个任务流，完成了这个任务流中的所有任务即完成了构建。说到任务以及任务流，我们有必要先好好认识一下它们。
 
1.理解前端构建过程中的任务
 
对比于JavaScript的函数，个人对任务是这么分类的：
 
单任务：同步任务和异步任务
多任务：并行任务、串行任务
 
同步任务和异步任务无须解释，这里说说并行任务和串行任务。任务并行可以用于缩短多个任务的执行时间。因为node是单线程执行的，我认为它并不能缩短多个同步任务并行的执行时间，但是构建过程中的任务通常都会涉及到IO流，所以大部分任务都是异步任务，IO任务并行可以避免IO阻塞线程执行，进而缩短多个任务的执行时间。
 
而任务串行可以保证任务之间的有序执行，比如在开发环境下，我们肯定要先执行编译任务，然后才能执行启动开发服务器的任务。
 
理解了构建过程中的任务之后，下面再列举一些在日常开发当中，我们常见到的构建任务。
 
2.前端构建过程中的常见任务
 
任务名
任务职责
Eslint检查
统一代码风格
babel转换
ES6 -> ES5
typescript转换
Ts -> Js
sass转换
sass -> css
less转换
less -> css
html、css、js压缩
.html -> .min.html、.css->.min.css、.js->.min.js
web server
开发服务器
js、css兼容
兼容不同浏览器
…
…
除了上述表格中列举的任务之外，在不同的项目中还会有不同的构建任务，这里不再一一赘述。上面说到自动化构建其实就是一个任务流，再理解和认识了常见任务之后，我们再来理一理什么是前端的构建任务流。
 
3.理解前端构建任务流
 
构建是为工程服务的，而工程又是为用户服务的。对应于开发环境和生产环境，前端工程可以分为开发环境工程和生产环境工程，其中开发环境工程为开发者服务，生产环境工程为用户服务。
 
满足工程使用者的需求是我们构建工程的终极目的，所以有必要投其所好，根据工程的使用者不同，完成他所需要的的一连串任务，也就是任务流。这时可以根据构建后工程的目标使用者来划分，把任务流分为开发环境构建任务流和生产环境构建任务流两种。
 
4.理解开发环境构建任务流
 
开发环境构建任务流构建后的工程是为开发者服务的。开发者需要开发调试代码，所以开发环境任务流构建的工程需要实现以下功能：
 
功能项
包含任务
语法检查
Eslint
语法转换
ES6 -> ES5、Sass -> less、Ts->Js等等
模拟生产环境
web开发服务器：devServer
易于调试
sourceMap
…
…
开发者需要不断修改代码查看效果，所以除了满足功能之外，还需要加快构建速度并且自动刷新，以保证良好的使用体验。
 
优化方式
实现方案
加快构建速度
devServer热模块替换
自动刷新
devServer 监听源代码
…
…
关于web开发服务器devServer
 
使用web开发服务器可以模拟像使用nginx、tomcat等服务器软件一样的线上环境，它在功能以及配置上都与nginx以及tomcat类似， 最简单的配置就是指明资源路径baseUrl以及服务启动ip和端口port即可。在开发环境启动本地服务时，配置代理可以在符合同源策略的情况下解决跨域问题。
 
开发服务器除了可以模拟线上环境之外，更加强大的一点是它可以监听源代码，实现热部署和自动刷新功能！
 
5.理解生产环境构建任务流
 
生产环境构建任务流构建后的工程是为用户服务的。与开发环境相比，它也需要语法检查以及编译功能，但不需要考虑修改以及调试代码的问题，它关注的是浏览器兼容以及运行速度等问题。
 
功能项
包含任务
语法检查
Eslint
语法转换
ES6 -> ES5、Sass -> less、Ts->Js等等
语法兼容
不同浏览器的js、css语法兼容
下载速度
资源压缩与合并
…
…
生产环境的优化除了资源的下载速度之外，还可以从很多方面入手，下面是其中的一些方面以及实现方案。
 
优化方面
实现方式
下载优化
treeshaking、代码分割、懒加载
运行优化
代码上优化性能
离线访问
pwa技术
…
…
终于把任务以及任务流浅显粗陋的讲完了，接下来我们先是使用npm scripts来实现简单项目的自动化构建，而后学习一下Gulp工具如何实现复杂项目的自动化构建。
 
二：npm script实现自动化构建任务流
 
任务流由任务组成，任务由脚本实现。在定义好任务脚本或者安装好任务cli模块之后，我们只需在package.json的scripts选项中配置一条script，就可以方便地调用任务脚本或者任务模块。对于任务流的npm script定义，我们可以借助一些可以帮助任务组合的库，这样就可以实现多个任务之间的并行和串行。
 
这里不得不提一下node_modules/.bin文件夹，我们在项目中安装的cli模块都会有一个cmd文件出现在这里。当我们在项目中需要调用这些cli模块时，只需yarn/npx cli模块名的方式就可以很方便的调用这些cli模块。
 
好的，通过上面的分析之后，我们接下来展开讲述一下npm scripts如何实现任务以及任务流的构建。
 
1.npm script实现任务、任务流构建
 
单任务构建
 
对于单任务的构建，只需配置一条简单的script即可，如以下sass和ES6转换的script示例（package.json）：
 
  "scripts": {
    "sass": "sass scss/main.scss css/style.css",
    "es6": "babel es6 --out-dir es5",
  },
  "devDependencies": {
    "@babel/cli": "^7.12.8",
    "@babel/core": "^7.12.9",
    "sass": "^1.29.0"
  }
 
配置以上scripts之后，我们就可以使用以下命令执行任务：
 
# sass转换
yarn sass
# es6转换
yarn es6
 
这里提一提在执行上述命令之后到最后调用sass和es6编译工具的调用过程：
 
 
yarn sass -> sass scss/main.scss css/style.css -> node_modules/.bin/sass.cmd -> node_modules/sass/sass.js -> …code
 
 
yarn es6 -> babel es6 --out-dir es5 -> node_modules/.bin/babel.cmd -> node_modules/@babel\cli\bin\babel.js -> node_modules/@babel\cli\lib\index.js -> …code
 
 
任务流构建
 
对于任务流的构建，除了准备基本任务之外，我们还需要考虑这些任务之间是否有序，如果有序我们借助任务串行实现，如果无序我们通过任务并行加快构建速度。通常我们会借助npm-run-all 这个库来实现任务的并行和串行，如以下通过任务并行实现sass转换以及ES6转换的简单示例（package.json）：
 
  "scripts": {
    "sass": "sass scss/main.scss css/style.css",
    "es6": "babel es6 --out-dir es5",
    "build": "run-p sass es6"
  },
  "devDependencies": {
    "npm-run-all": "^4.1.5",
    "@babel/cli": "^7.12.8",
    "@babel/core": "^7.12.9",
    "sass": "^1.29.0"
  }
 
配置以上scripts之后，我们就可以使用以下命令执行任务：
 
yarn build
 
执行yarn build之后，就可以借助npm-run-all库的nun-p.cmd实现sass和es6任务的并行。对于任务的串行，则通过npm-run-all库的nun-s.cmd实现。
 
好的，在通过以上两个示例理解了npm script实现构建任务以及任务流之后，我们接下来通过npm script实现一个简单前端项目的开发环境自动化构建和生产环境的自动化构建。
 
2.npm scripts构建工程示例
 
1):需构建的项目源代码
 

 这个项目很简单，它只包含一个html文件，一个使用了ES6语法js文件以及一个使用了sass语法的样式文件，接下来我们就用npm script来实现这个简单项目的自动化构建（也即开发环境构建任务流和生产环境构建任务流）。事实上，简单项目的自动化构建就是npm script实现自动化构建的使用场景。
 
2):实现开发环境自动化构建任务流
 
通过上面我们对开发环境构建任务流的认识，我们先理一理在这个项目中，开发环境任务流至少应该包含哪些任务：
 
需要web开发服务器模拟生产环境以及实现源码监听和自动刷新。
对于sass文件，需要实时sass转换，并且监听源码变化重启开发服务器、刷新浏览器。
对于ES6文件，需要实时babel转换，并且监听源码变化重启开发服务器、刷新浏览器。
对于html文件，需要监听源码变化重启开发服务器、刷新浏览器。
…
 
对于sass和ES6修改源代码后的实时转换，我们可以通过加上一个watch参数实现。而对于所有这些需要监听变化的文件，我们则统一放入temp文件夹下（角色好比如nginx和Tomcat的应用存放目录），而后让web开发服务器监听这个temp文件夹下所有文件的变化，一旦变化即重启并刷新浏览器。
 
好的经过上面任务分析之后，我们可能会把package.json的scripts以及devDependencies写成如下样子：
 
  "scripts": {
    "sassDev": "sass scss/main.scss temp/css/style.css --watch",
    "babelDev": "babel es6/script.js --out-dir temp/es5/script.js --watch",
    "copyHtmlDev": "copyfiles index.html temp",
    "serve": "browser-sync temp --files \"temp\"",
    "start": "run-p sassDev babelDev copyHtmlDev serve"
  },
  "devDependencies": {
    "@babel/cli": "^7.12.8",
    "@babel/core": "^7.12.9",
    "browser-sync": "^2.26.13",
    "copyfiles": "^2.4.1",
    "npm-run-all": "^4.1.5",
    "sass": "^1.29.0"
  }
 
3):实现生产环境自动化构建任务流
 
通过上面我们对生产环境构建任务流的认识，我们先理一理在这个项目中，生产环境任务流应该包含哪些任务：
 
删除上一次构建结果任务
编译任务
html模板信息注入任务
文件压缩任务
…
 
  "scripts": {
    "sass": "sass scss/main.scss dist/css/style.css",
    "babel": "babel es6 --out-dir dist/es5",
    "copyHtml": "copyfiles index.html dist",
    "build": "run-p sass babel copyHtml"
  },
  "devDependencies": {
    "@babel/cli": "^7.12.8",
    "@babel/core": "^7.12.9",
    "browser-sync": "^2.26.13",
    "copyfiles": "^2.4.1",
    "npm-run-all": "^4.1.5",
    "sass": "^1.29.0"
  }
 
上述代码实现不全，按道理说，在生产环境下，至少需要做代码的兼容以及压缩。这时我们就需要找到对应的工具库或者自己实现，另外对于压缩而言至少需要在编译之后完成，所以需要注意多个任务间的关系。思路很简单，博主偷个懒当前就不花时间去实践了，需要时再实现就行。
 
3.npm scripts构建总结
 
在介绍Gulp之前，我们有必要再重申一点。在项目以及构建需求不复杂时，npm scripts就可以满足我们的构建需求了，无需借助其它工具。
 
三：成熟工具Gulp实现自动化构建任务流
 
1.简单认识Gulp
 
Gulp是一个基于流的自动化构建工具，相比较于Grunt，它的构建速度更快，任务编写也更加简单灵活（Grunt博主没用过也不感兴趣）。要使用Gulp，首先需要在项目根目录下创建一个Gulp入口文件gulpfile.js，然后在这个入口文件中通过暴露函数的方式注册任务。
 
对于一个工具，其它的不多比比，我们接下来看看它是怎么实现前端项目的自动化构建的。
 
2.Gulp实现任务、任务流构建
 
1):实现同步任务和异步任务
 
对于新版本的Gulp来说，所有任务都是异步任务，所以任务需要告诉Gulp什么时候执行结束。以下是gulp异步任务实现的几种方式（关注它们是如何通知Gulp异步任务结束的）。
 
// 方式1：调用done方法主动通知任务结束
exports.foo = done => {
  console.log('foo task working~')
  done() // 标识任务执行完成
}
// 方式2：返回Promise，通过它的resolve/reject方法通知任务结束
const timeout = time => {
  return new Promise(resolve => {
    setTimeout(resolve, time)
  })
}
// 方式3：返回读取流对象，流完即自动通知任务结束
exports.stream = () => {
  const read = fs.createReadStream('yarn.lock')
  const write = fs.createWriteStream('a.txt')
  read.pipe(write)
  return read
}
// 更多方式
 
2):实现并行任务和串行任务
 
并行任务和串行任务可以通过gulp提供的series（串行）, parallel（并行）实现。
 
const { series, parallel } = require('gulp');

const task1 = done => {
  setTimeout(() => {
    console.log('task1 working~');
    done();
  }, 1000)
}

const task2 = done => {
  setTimeout(() => {
    console.log('task2 working~');
    done();
  }, 1000)  
}

exports.bar = parallel(task1, task2); // 并行任务bar

exports.foo = series(task1, task2); // 串行任务foo
 
3):Gulp插件任务和自定义任务
 
插件任务
 
Gulp生态中有很多成熟的gulp任务插件，使用它们可以很好地提高效率，如以下示例：
 
const { src, dest } = require('gulp');
const cleanCSS = require('gulp-clean-css');
const rename = require('gulp-rename');

exports.default = () => {
  return src('src/*.css')
    .pipe(cleanCSS())
    .pipe(rename({ extname: '.min.css' }))
    .pipe(dest('dist'))
}
 
自定义任务
 
如果需要定制任务，或者对于我们的需求没有较好的gulp插件，那么我们就需要自定义任务，如下示例：
 
const fs = require('fs')
const { Transform } = require('stream')

exports.default = () => {
  const readStream = fs.createReadStream('normalize.css');
  const writeStream = fs.createWriteStream('normalize.min.css');
  // 文件转换流
  const transformStream = new Transform({
    // 核心转换过程
    transform: (chunk, encoding, callback) => {
      const input = chunk.toString();
      const output = input.replace(/\s+/g, '').replace(/\/\*.+?\*\//g, '');
      callback(null, output);
    }
  })

  return readStream
    .pipe(transformStream) // 转换
    .pipe(writeStream) // 写入
}
 
3.Gulp实现开发环境和生产环境自动化构建
 
gulp只是一个帮助我们实现自动化构建的工具，思想在上文中已经探讨了很多，而且对比于gulp，个人对后面的webpack更感兴趣，这个示例我就不多做叙述了。
 
好吧，都是借口，现在已经深夜了，用心地写了那么长，我坦白我熬不住了。对了，如果认可文章内容，点赞收藏鼓励一下吧，每周一篇，后面会有我的更多学习记录哦。
 
下例是经过个人整理过的，课程中老师使用gulp对开发环境和生产环境自动化构建的示例实现：
 
const {
  src,
  dest,
  parallel,
  series,
  watch
} = require('gulp')

const del = require('del')
const browserSync = require('browser-sync')

const loadPlugins = require('gulp-load-plugins')

const plugins = loadPlugins()
const bs = browserSync.create()

const data = {
  menus: [{
      name: 'Home',
      icon: 'aperture',
      link: 'index.html'
    },
    {
      name: 'Features',
      link: 'features.html'
    },
    {
      name: 'About',
      link: 'about.html'
    },
    {
      name: 'Contact',
      link: '#',
      children: [{
          name: 'Twitter',
          link: 'https://twitter.com/w_zce'
        },
        {
          name: 'About',
          link: 'https://weibo.com/zceme'
        },
        {
          name: 'divider'
        },
        {
          name: 'About',
          link: 'https://github.com/zce'
        }
      ]
    }
  ],
  pkg: require('./package.json'),
  date: new Date()
}
// css编译  src => temp
const style = () => {
  return src('src/assets/styles/*.scss', {
      base: 'src'
    })
    .pipe(plugins.sass({
      outputStyle: 'expanded'
    }))
    .pipe(dest('temp'))
    .pipe(bs.reload({
      stream: true
    }))
}
// js编译   src => temp
const script = () => {
  return src('src/assets/scripts/*.js', {
      base: 'src'
    })
    .pipe(plugins.babel({
      presets: ['@babel/preset-env']
    }))
    .pipe(dest('temp'))
    .pipe(bs.reload({
      stream: true
    }))
}

// html模板解析     src => temp
const page = () => {
  return src('src/*.html', {
      base: 'src'
    })
    .pipe(plugins.swig({
      data,
      defaults: {
        cache: false
      }
    })) // 防止模板缓存导致页面不能及时更新
    .pipe(dest('temp'))
    .pipe(bs.reload({
      stream: true
    }))
}

// 串行编译、模板解析
const compile = parallel(style, script, page)

// 开发环境开发服务器
const serve = () => {
  watch('src/assets/styles/*.scss', style)
  watch('src/assets/scripts/*.js', script)
  watch('src/*.html', page)
  // watch('src/assets/images/**', image)
  // watch('src/assets/fonts/**', font)
  // watch('public/**', extra)
  watch([
    'src/assets/images/**',
    'src/assets/fonts/**',
    'public/**'
  ], bs.reload)

  bs.init({
    notify: false,
    port: 2080,
    // open: false,
    // files: 'dist/**',
    server: {
      baseDir: ['temp', 'src', 'public'],
      routes: {
        '/node_modules': 'node_modules'
      }
    }
  })
}

// 开发环境构建流：编译 + 启动开发服务器    src => temp
const develop = series(compile, serve)



// 生产环境下清空文件夹
const clean = () => {
  return del(['dist', 'temp'])
}
// 生产环境js、css、html压缩后构建  temp => dist
const useref = () => {
  return src('temp/*.html', {
      base: 'temp'
    })
    .pipe(plugins.useref({
      searchPath: ['temp', '.']
    }))
    // html js css
    .pipe(plugins.if(/\.js$/, plugins.uglify()))
    .pipe(plugins.if(/\.css$/, plugins.cleanCss()))
    .pipe(plugins.if(/\.html$/, plugins.htmlmin({
      collapseWhitespace: true,
      minifyCSS: true,
      minifyJS: true
    })))
    .pipe(dest('dist'))
}
// 生产环境图片压缩后构建   src => dist
const image = () => {
  return src('src/assets/images/**', {
      base: 'src'
    })
    .pipe(plugins.imagemin())
    .pipe(dest('dist'))
}
// 生产环境字体压缩后构建   src => dist
const font = () => {
  return src('src/assets/fonts/**', {
      base: 'src'
    })
    .pipe(plugins.imagemin())
    .pipe(dest('dist'))
}
// 生产环境静态资源构建
const extra = () => {
  return src('public/**', {
      base: 'public'
    })
    .pipe(dest('dist'))
}

// 上线之前执行的任务   src => (temp =>) => dist 
const build = series(
  clean,
  parallel(
    series(compile, useref),
    image,
    font,
    extra
  )
)

module.exports = {
  clean,
  build,
  develop
}


 
 
 
本文结束，谢谢观看。
 如若认可，点赞收藏。
 

系列文章目录
 
 
第一章 Ubuntu部署Jenkins服务端
 第二章 Linux节点的Python服务自动化构建
 第三章 Windows节点Python服务自动化构建
 第四章 Vue服务自动化打包构建
 第五章 监控服务自动化构建
 
 


 
文章目录
 
系列文章目录
监控服务自动化构建
定时构建
构建
构建后操作
邮箱配置
开始构建
构建日志
 

 
 
监控服务自动化构建
 
配置丢弃旧的构建
配置限制运行节点
设置定时构建触发器
选择Http Request构建 （需要 HTTP Request Plugin 插件）
配置异常邮件通知列表 （需要 
 Email Extension Plugin 插件）
 
定时构建
 
定时构建语法
 
* * * * *

第一颗*表示分钟，取值0~59
第二颗*表示小时，取值0~23
第三颗*表示一个月的第几天，取值1~31
第四颗*表示第几月，取值1~12
第五颗*表示一周中的第几天，取值0~7，其中0和7代表的都是周日
 
示例表示每十分钟构建一次
 
 
构建
 
安装完 HTTP Request Plugin 插件后 可以在 增加构建步骤 中看到 HTTP Request 选项，每次构建时会触发一次HTTP请求。
 
可以指定
 
请求路由
请求方式
认证信息
Header
请求参数
上次文件
请求响应
 
示例是一个简单的请求，正常响应返回 OK 字符串
 
 
 
 
构建后操作
 
这个是一个监控任务，每10分钟请求一次目标路由，正常响应OK 不走其他操作，响应异常时给用户发送邮件通知。
 
收件人是多个时用空格分隔。
 
 
邮箱配置
 
系统管理 -> 邮件通知 点击高级
 
 我使用的是qq邮件，使用SMTP认证需要在发件人邮箱进行配置
 
登录发件人邮箱
邮箱设置
账户
POP3/IMAP/SMTP/Exchange/CardDAV/CalDAV服务
开启POP3/SMTP服务
获取授权码
将密码填写到 使用SMTP认证 的密码栏中
通过发送测试邮件测试配置
查看测试邮件
 
开始构建
 
如果想手动测试任务的配置，可以点击 立即构建
 
 
构建日志
 

系列文章目录
 
 
第一章 Ubuntu部署Jenkins服务端
 第二章 Linux节点的Python服务自动化构建
 第三章 Windows节点Python服务自动化构建
 第四章 Vue服务自动化打包构建
 第五章 监控服务自动化构建
 
 


 
文章目录
 
系列文章目录
Linux节点的Python服务自动化构建
Linux节点配置
节点列表
节点列表
新建节点
  
SVN操作
创建目录
创建Tags
  
创建任务
新建任务
构建参数
源码管理
构建
  
构建任务
构建时的效果
构建日志
 

 
 
Linux节点的Python服务自动化构建
 
首先介绍下前提条件：节点服务器有Python运行环境
 
Linux节点配置
 
节点列表
 
可以点击 构建执行状态 进入节点列表
 

 也可以点击 系统管理 的 节点管理 进入节点列表
 
 
节点列表
 
 
新建节点
 
填写节点名称 选择固定节点 或者 复制现有节点的 配置
 
 
执行器数 是服务器可以同时进行构建的个数，单一服务器上的部署的项目比较多时，可以增加执行器数量来加快构建速度
远程工作目录 是Jenkins远程的服务，采集器、项目工作目录都会创建在这个工作目录下
用法 我选择的指定机器的任务
启动方式 Launch agents via SSH 没有这个选项的查看下已安装的插件
添加服务器凭据 
 
配置好就可以 保存 并 上线节点了
 
上线后的节点 就可以在点在列表中看到了
 
此时登录服务器 可以看到远程工作目录下会有 如下的文件
 
 
SVN操作
 
有权限的SVN URL 和 用户账户信息
在项目服务下创建 master 目录 作为开发目录使用
在项目服务下创建 release 目录 作为Tags目录使用 在下面的构建参数 svn_release 中使用
创建 Tags 到 release 目录
 
创建目录
 
 
创建Tags
 
填写要保存的 版本名称 和 版本描述，点击 OK
 
 
创建任务
 
新建任务
 
新建任务 填写 任务名称 选择 构建一个自由风格的软件项目
 
 
构建参数
 
构建参数我这里添加了：
 
gunicorn_path(启动FastAPI项目)
port 启动端口 下面的构建 shell 中有用到
workers 启动线程数端口 下面的构建 shell 中有用到
main_file 项目构建时 代码会更下在 workspace 目录下的 有任务名称命名的目录下，$JOB_NAME 是获取任务名称，这样可以方便重启时定位进程 下面的构建 shell 中有用到
app_name 意义不大 下面的构建 shell 中有用到
deploy_env 执行的操作 分为 restart start stop
svn_release 加载项目的 tags，展示最新的 50 tags 没有这个参数时 需要安装 Jenkins SVN 插件 下面的源码管理 URL 中有用到
 

 
 
 
 
源码管理
 
源码管理这个的 SVN URL ，每次构建时会在工作目录下 更新 选择的svn_release版本对应的 源码，以实现 版本控制的 效果。
 
 
 
构建
 
 
执行shell 分为三个情况，执行情况由构建参数 deploy_env 决定
 
start 使用gunicorn启动项目
restart 根据 main_file 杀死旧的进程并启动新的代码
stop 根据 main_file 杀死旧的进程
BUILD_ID=dontKillMe解决 Jenkins shell 无法后台运行的问题
 
echo $deploy_env
case $deploy_env in
	start)
    	echo "start: $deploy_env"
        cd .. \
        && BUILD_ID=dontKillMe $gunicorn_path/gunicorn $main_file:$app_name -b 0.0.0.0:$prot  -w $workers -k uvicorn.workers.UvicornH11Worker --daemon
        ;;
    restart)
    	echo "restart: $deploy_env"
		pid=` ps -ef|grep $main_file|grep -v "grep"|awk '{print $2}'`
        for id in $pid
        do
            kill -9 $id  
        done
        cd .. \
        && BUILD_ID=dontKillMe $gunicorn_path/gunicorn $main_file:$app_name -b 0.0.0.0:$prot  -w $workers -k uvicorn.workers.UvicornH11Worker --daemon
    	;;
    stop)
    	echo "stop: $deploy_env"
		pid=` ps -ef|grep $main_file|grep -v "grep"|awk '{print $2}'`
        for id in $pid
        do
            kill -9 $id  
        done
		;;
    *)
    exit
    ;;
esac

 
构建任务
 
选择要构建的版本
选择要执行的操作
点击开始构建
 
构建时的效果
 
 
构建日志
 
执行顺序：
 
拉取源码
执行shell
构建后操作（这里没有配）
 

工程自动化构建部署
 
前言
 
​ 随着需求越来越多，以及相关代码分支权限的流程规范化，团队内部的项目上线部署复杂度提升，基于现有的环境和市场上主流的软件，打造了一套基于gitlab+docker+harbor+kubernetes的自动化构建部署流程(CI/CD)，目前团队内部流程基本走通，整理了一份相关文档分享出来。写的糙的地方，轻喷。
 
概念
 
GitLab CI/CD
 
​ GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。与之对应的有GitHub和Gitee，公司内部使用一般使用GitLab作为代码管理工具。
 
​ GitLab CI/CD 是一个内置在GitLab中的工具，用于通过持续方法进行软件开发：
 
Continuous Integration (CI) 持续集成
Continuous Delivery (CD) 持续交付
Continuous Deployment (CD) 持续部署
 
​ 持续集成的工作原理是将小的代码块推送到Git仓库中托管的应用程序代码库中，并且每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。
 
​ 持续交付和部署相当于更进一步的CI，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。这些方法使得可以在开发周期的早期发现bugs和errors，从而确保部署到生产环境的所有代码都符合为应用程序建立的代码标准。
 
​ GitLab CI/CD 由一个名为 .gitlab-ci.yml 的文件进行配置，改文件位于仓库的根目录下。文件中指定的脚本由GitLab Runner执行。
 
Docker
 
​ Docker 是一个开源的应用容器引擎，基于Go语言开发并遵从 Apache2.0 协议开源。Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口,更重要的是容器性能开销极低。
 
Harbor
 
​ 虽然Docker官方提供了公共的镜像仓库，但是从安全和效率等方面考虑，部署公司私有环境内的Registry是非常有必须要的。
 
​ Harbor是由VMware公司开源的企业级的Docker Registry管理项目，相比docker官方拥有更丰富的权限管理和完善的架构设计，适用于大规模docker集群部署提供仓库服务
 
​ 它主要提供Docker Registry管理界面UI，可基于角色访问控制，镜像复制，AD/LDAP集成，日志审核等功能，重点是完全支持中文。
 
Kubernetes
 
​ kubernetes(简称k8s)是用于自动部署、扩容和管理编排容器化应用程序的开源系统，该系统由Google设计并捐赠给Linux基金会来使用。
 
​ 它旨在提供“跨主机集群的自动部署、扩展以及运行应用程序容器的平台”。 它支持一系列容器工具，包括docker、containerd等。
 
搭建GitLab-Runner
 
服务器要求
 
最少一台runner服务器，建议最低配置为2C4G以上
gitlab服务
 
配置CI/CD的Runners
 
点击项目，左侧的Settings---->CI/CD---->Runners---->Expand，如下图所示
 
 
 
登录runner服务器，安装gitlab-runner
 
curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64"

chmod +x /usr/local/bin/gitlab-runner

##添加用户，此处可以不添加，如果用root权限的话，建议直接指定root用户。防止后续持续性集成的时候出现权限问题
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
## 切换到root用户  --user=root
gitlab-runner install --user=root --working-directory=/home/gitlab-runner
#gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
 
gitlab-runner start
## 也可以后续调整配置文件
vim /etc/systemd/system/gitlab-runner.service
 
 
配置文件 ： /etc/systemd/system/gitlab-runner.service
 
[Unit]
Description=GitLab Runner
ConditionFileIsExecutable=/usr/local/bin/gitlab-runner
After=syslog.target network.target

[Service]
StartLimitInterval=5
StartLimitBurst=10
ExecStart=/usr/local/bin/gitlab-runner "run" "--working-directory" "/home/gitlab-runner" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" "--user" "root"

Restart=always
RestartSec=120
EnvironmentFile=-/etc/sysconfig/gitlab-runner
[Install]
WantedBy=multi-user.target
 
 
重启服务
 
systemctl daemon-reload
systemctl restart gitlab-runner.service
 
 
注册到gitlab上
 
​ 说明：
 
gitlab-ci-multi-runner register：执行注册命令
Please enter the gitlab-ci coordinator URL：输入 ci 地址
Please enter the gitlab-ci token for this runner：输入 ci token
Please enter the gitlab-ci description for this runner：输入 runner 名称
Please enter the gitlab-ci tags for this runner：设置 tag
Whether to run untagged builds：这里选择 true ，代码上传后会能够直接执行
Whether to lock Runner to current project：直接回车，不用输入任何口令	
Please enter the executor：选择 runner 类型，这里我们选择的是 shell
 
 
执行注册：（后面在GitLab的UI中更改）
 
gitlab-runner register
##输入gitlab的地址，以下信息在上图中有体现，图中4的位置
Enter the GitLab instance URL (for example, https://gitlab.com/):
https://gitlaball.nicetuan.net/
##输入token
Enter the registration token:
*********
##输入runner的描述，一般可以设置为runner的hostname
Enter a description for the runner:
do-runner-004
## 输入与Runner关联的标签
Enter tags for the runner (comma-separated):
master
##输入Runner执行程序，一般选择shell，根据真实情况选择
Enter an executor: docker+machine, parallels, shell, ssh, virtualbox, kubernetes, custom, docker, docker-ssh, docker-ssh+machine:
shell
##执行完毕
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
 
 
刷新刚刚的CI/CD页面，发现已经添加runner机器成功
  
 
配置gitlab-ci.yml文件
 
​ 注意：此处demo是演示的go版本，可以根据具体的项目环境进行调整脚本操作，大体操作是不变的
 
项目添加.gitlab-ci.yml
 
​ 此处默认为该文件名，如有调整，可以从GitLab项目中的Settings---->CI/CD---->General pipelines中修改
 
before_script:
  - go env -w GOPROXY=https://goproxy.cn,direct
  - go env -w GO111MODULE=on
stages:
  - build
  - test
  - lint
  - docker-deploy
build:
  stage: build
  allow_failure: false  
  script:
    - go mod tidy
    - make
  only:
    - tags
    - branches
  retry: 1
test:
  stage: test
  script:
    - go test -test.v  ./...  -nacosDir=$PWD/conf  -logDir=$PWD/
  only:
    - tags
    - branches
  retry: 1
lint:
  stage: lint
  allow_failure: false
  script:
    - golangci-lint --version
    - golangci-lint run -v
  only:
    - tags
    - branches
  retry: 1
docker-deploy:
  stage: docker-deploy
  script:
    - make
    - docker build --rm -t bigdata-harbor.nicetuan.net/risk/riskclient:$CI_COMMIT_REF_NAME .
    - docker push bigdata-harbor.nicetuan.net/risk/riskclient:$CI_COMMIT_REF_NAME
  only:
    - tags
 
 
 
说明：
 
 
触发build、test、lint 流程： 当branchs和tags变更的时候。注意allow_failure: false ，设置是否允许该job失败。
 
 
触发docker-deploy 流程：当项目打tag版本的时候，触发docker编译和推送到公司私有仓库上。此处需要特别注意：
 
 
1：代码的tag版本需要严格按照发版操作，vx.y.z。因为下面的docker 镜像就是根据这个版本来创建，同时生产环境升级也是根据此情况来执行。
 
 
2：runner服务器如果已经登录过私服，则可以不执行docker login 192.168.1.1 -u admin -p 123456，否则会推送到仓库失败
 
 
3：如果上面执行gitlab-runner 的用户不是root，则此处有可能会出现权限问题，因为docker是用root启动的。
 
 
提交代码到gitlab
 
​ 观察项目此时会有pipline的日志流程，可以点进去看每一个job的执行日志
 
 
 
查看docker 私服
 
 
调整k8s版本
 
由于程序升级的时间需要根据具体的情况进行发布，故此处操作为手动调整镜像版本进行升级
 
 
登录k8s系统
 
地址：http://192.168.0.1:30080/sso/auth/default?req=hrg7iwz6aioxwnp5ol7frvew3
 
账号：admin
 
密码：****
 
 
选择命名空间 riskclient
  
 
进行版本升级
 
​