zoukankan      html  css  js  c++  java
  • Jenkins多环境持续集成架构实践

     

         自动化部署主要是为了解决项目多、环境多、持续集成慢、部署操作麻烦、手动操作易出错、自动化运维等问题。

    Jenkins是开源CI&CD软件领导者, 提供超过1000个插件来支持构建、部署、自动化, 满足任何项目的需要。

    目标

    l  支持多分支、多环境、多项目、多套配置文件、多编程语言

    l  支持一键构建、集群发布

    l  支持一键回滚历史版本

    l  快捷配置添加新的部署项目

    l  支持多个项目使用同一个job发布或回滚

    另外:也可以根据需要加入gitlab自动触发构建、自动化测试、钉钉通知、邮箱通知等需求

     

    本实践使用到的技术,可参考:《[CI&CD]jenkins自动化工具使用教程》

    技术关键词:jenkins master-slavejenkins 插件(multijobEnvInject),rsync工具,powershelldotnet core cliicacls工具等等

    拷贝文件权限解决方案:方案一:使用 icacls 工具赋权。    方案二:指定 jenkins服务 的运行账户

     

    目录

    最终效果图... 1

    目录设计... 2

    约定及规范... 3

    架构设计... 4

    #、CICD架构图... 4

    #、项目映射配置文件设计... 5

    #、一键发布job设计... 6

    #、一键回滚job设计... 8

    #、简易多环境CICD流程... 8

     

    最终效果图

    一键发布

     

     

     

    一键回滚

     

    目录设计

    Jenkins相关目录设计

    ----jenkins-ex		jenkins构建时使用到的目录
    ------software		Jenkins安装目录
    --------master
    --------slave
    ------backup		jenkins备份目录
    --------master
    ------module		功能模块,每一类功能相关的文件放在对应的子文件夹中
    --------common
    ----------script		各模块公用的脚本
    ------publish		发布功能
    --------settings
    ----------config	构建时配置文件。Eg: jenkins_profile.pubxml、项目配置文件等
    ------------test-publish-template-app-config.json	项目映射配置表
    ----------script	Jenkins job构件时调用的脚本(方法封装)
    ------source-code	拉取的源代码存放目录
    --------test
    ----------系统标识 
    ------------应用名
    ------build-result		构建产物(编译后的结果)
    --------test
    ----------系统标识 
    ----------应用名
    ------temp-file	临时文件,job执行过程中产生的文件
    --------builder-history	构建历史记录文件
    --------job-params		构建过程中传递参数的文件
    ------app-config  应用对应的环境配置文件
    --------test
    ----------系统标识
    ------------应用名
    ------other-sub-module
    ……

     

    约定及规范

    jenkins job命名

    #job名全小写,多单词用”-”分割。(egpublish-template-onekey-deploy

    #job命名约定:模块名-环境-功能名。(egpublish模块,publish-test-onekey-deploy

    #、模块中组件job命名约定:模块-c-组件名。(egpublish-c-pull-code

    #job输入参数以”p_”为前缀

     

    Jenkins job中的脚本命名(egpowershell

    #、变量全小写,多单词用”_”分割

     

    规范约定

    #、代表路径的变量值,以””结尾

    #、备份名字中用“#”做分隔符,还原时好取参数(egp_app_key#2019-1219-1503

     

    架构设计

    #CICD架构图

    CICD过程主要在两个局域网中执行:构建服务器(开发内网)和部署服务器(生产内网)

     

         jenkins CICD架构图

    #、项目映射配置文件设计

    想要实现使用一个job,通过下拉来发布|回滚不同的项目,我们需要一个灵活的项目配置映射文件,类似如下:

    config

     

    配置文件选项含义从命名上可以识别,主要包括:环境、代码分支、部署路径、拷贝排除文件列表、项目信息(项目唯一标识、目录文件夹名、源代码路径、开发语言、集群节点信息…)等等

           app_config节点下的配置,可以覆盖父节点配置,适配项目特定的部署要求。

           app_config是数组节点,可以轻松添加新的部署项目,实现新项目的快速CICD

     

    #、一键发布job设计

    一键发布主要经历的阶段有:组合项目相关参数>>获取最新代码>>编译打包>>推送应用文件到服务器>>应用备份>>拷贝到Temp文件夹>>发布到部署目录

    为了更好的实现和控制一键发布这些阶段,设计了如下输入参数:

    publish-02

     

    参数名

    类型

    默认值

    说明

    p_publish_model

    下拉单选

    reality

    取值:realitydrill

    发布模式
    reality
    :正常发布,发布到应用服务器应用文件夹,做真实应用发布部署

    drill:演练。发布到应用服务器temp文件夹后结束

    p_app_key

    下拉单选

     

    通过这个key到配置文件里面找站点的具体配置信息

    p_do_code_pull

    Bool

    True

    拉取最新代码

    p_do_build_package

    Bool

    True

    是否重新编译打包

    p_do_backup

    Bool

    True

    是否执行备份

    p_publish_content

    多选

     

    取值:app-fileconfig

    发布文件列表(多选)

     

    app-file:应用文件(不包含config文件)

    config:配置文件

    p_restart_daemon_process

    Bool

    True

    是否重启守护进程(如果是IIS,勾选则重启应用程序池,不勾选则回收应用程序池) 为避免文件被占用,发布失败,所以这里默认勾选。如果只是新增页面文件,可以不勾选

    p_remark      

    String

     

    备注信息

     

    #、一键回滚job设计

           实现思路:在一键发布时,将发布记录存到文件中,存储key为:p_app_key#2019-1219-1503。执行回滚时,选择要回滚的历史项目,先解析出p_app_key再获取项目配置信息,再回滚此项目的特定历史版本。顺序:解析项目信息>>回滚到Temp文件夹>>回滚到部署目录。

    设计的输入参数如图:

     

     rollback-02

     

    参数名

    类型

    默认值

    说明

    p_history_item

    下拉单选

     

    每一次一键发布成功,都会生成一个对应的历史记录

    p_restart_daemon_process

    Bool

    True

    是否重启守护进程(如果是IIS,勾选则重启应用程序池,不勾选则回收应用程序池) 为避免文件被占用,回滚失败,所以这里默认勾选。

    p_remark      

    String

     

    备注信息

     

    #、简易多环境CICD流程

           一般软件公司对于软件的开发、测试、发布都有好几个环境,所以针对各个环境都会有对应的CICD流程,这边设计了一个简易的多环境CICD流程图,如下: (在线画图工具:processon.com

     jenkins多环境简易发布流程

           自动触发CICD还是手动触发CICD???我认为:

          开发环境采用手动触发:因为对于开发环境,提交代码比较频繁,而且有时候提交到git也并不想触发CICD。可以采取每晚定时自动触发CICD,便于异常代码及时抛出

          测试环境采用自动触发:因为测试代码的 git 分支合并是有条件限制的,合并频率比较少

          生产环境采用手动触发:因为生产环境的发布比较复杂,合并分支后是不能直接自动触发CICD的。比如有严控发布时间、负载隔离(蓝绿部署)等要求,所以手动触发控制力强

     

     

    over,谢谢查阅,觉得文章对你有收获,请多帮推荐。欢迎向我提供更好的资料信息。

     

  • 相关阅读:
    数独
    面向对象程序设计课第七次作业
    面向对象程序设计课第六次作业
    软件工程课总结
    第四次作业:四则运算界面
    psp记录个人项目花费时间
    作业三:代码规范,代码复查
    编写一个能生成小学四则运算题目的运算
    目前流行的源程序版本管理软件和项目管理软件有哪些?有什么优缺点
    课程进度总结
  • 原文地址:https://www.cnblogs.com/heyuquan/p/jenkins-multi-env-cicd-architecture.html
Copyright © 2011-2022 走看看