GitLab相关

一、Git、Github、GitLab的区别及与SVN的比较

Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。Git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开源版本的版本控制软件。
GitHub是一个面向开源及私有软件项目的托管平台，因为只支持git作为唯一的版本库格式进行托管，故名GitHub。
GitLab是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。
SVN是Subversion的简称，是一个开放源代码的版本控制系统，采用分支管理系统，用于多个人共同开发同一个项目，共用资源的目的。
Git与SVN区别：
1.Git是分布式的，而SVN不是。
2.Git把内容按元数据方式存储，而SVN是按文件。
3.Git没有一个全局版本号，而SVN有，这是Git对比SVN的一个最大特征缺陷。
4.Git内容完整性要优于SVN，存储内容Git采用SHA-1哈希算法，SVN采用FSFS
5.Git下载下来后，在没网状态下可以看到所有Log，SVN不行
6.SVN必须先update才能commit，不合并会出现错误，git还是比较少出现这种情况
7.对具有多个分支的项目来说，克隆一个新的目录，SVN是同时复制5个版本，做五个重复动作，而Git只是获取文件的每个版本元素，然后只载入主要的分支。
8.SVN只能有一个指定中央版本库。当这个库有问题是，其他成员都瘫痪，直到版本库恢复。Git是有无限个版本库，有问题时其他不受影响。
总结：
SVN是简单，只需要一个放代码的地方用是很好的。
git的特点版本控制是可以不依赖网络做任何事情，对分支和合并有更好的支持。

二、自动化Jenkins和GitLab的CI/CD比较

概念：
CI—持续集成：是源代码变更后自动检测、拉取、构建和（大多数情况下）进行单元测试的过程。持续集成是 启动管道的环境（尽管某些预验证——通常称为上线前检查——有时会被归在持续集成之前）。
CD—持续交付：是指某个流程链（管道），它自动监测源代码变更并通过构建、测试、打包和相关操作运行他们以生成可部署的版本，基本没有任何人为干预。
1.Gitlab CI/CD
优势：
轻量级，不需要复杂的安装手段。
配置简单，与Gitlab可直接适配。
实时构建日志，十分清楚，UI交互体验很好。
使用YAML进行配置，任何人都可以很方便的使用。
劣势：
没有统一的管理界面，无法统筹管理所有项目
配置依赖于代码仓库，耦合度没有Jenkins低
2.Jenkins
优势：
编译服务和代码仓库分离，耦合度低
插件丰富，支持语言众多
有统一的Web管理界面
劣势：
插件以及自身安装较为复杂
体量较大，不是很适合小型团队
总结：
Gitlab CI 有助于DevOps人员，例如敏捷开发，开发与运维是同一个人，最便捷的开发方式。
Jenkins CI 适合在多角色团队中，职责分明、配置与代码分离，插件丰富。

三、GitLab CI/CD的过程

CI/CD的大致写法：
一般开始于.gitlab-ci.yml文件，当然这个读取名字可以根据项目的需求发生变化，一般分为以下几步：

1. 定义stage（一般就是指整个CI的生命周期的阶段，避免定义很多的阶段，一般3~6阶段为最好）
2. 定义环境划分（一般至少为dev和prod）
3. 定义触发条件（一般为多项目防止多级触发）
4. 定义job（具体执行stage的任务）
5. 定义stage复用（多环境stage的调用）
6. 调用runner执行
   我们主要用到了三类CI/CD
   - Saltstack 调用类：项目由Runner机器执行打包或者其他命令后，操作Saltstack进行完成。中心思想为在runner机器对项目进行打包，分发预处理，再由salt控制项目中心的更新启停。
   - K8S集群类：K8S集群是runner通过调用K8S的admin.conf中base64后的token完成，里面包含对k8s APIserver地址信息的记录以及对api cert的证书认证相关的信息。核心的思想为不同的runner对应不同的k8s集群，runner在拉起服务块时会针对不同的任务唤起不同的底层镜像，即用即销，产生的产物存在关联的K8s的pvc卷中，一般缓存为maven node以及项目相关的jar包的tmp操作不用的环境。
   - 安卓/IOS打包类：核心思想就是把通过工具构建的操作转化为命令，例如IOS的Xcodebuild，安卓的Grandle配合证书完成打包后推送到相关的测试平台并通知相应的开发人员，对不同的包例如Debug或者Release可以做动态变量处理。

四、示例

1.Saltstack调用类：
项目目录结构

.gitlab-ci.yml指定调用入口，因为parent下项目较多，因此新建一个.gitlab目录存放各项目的ci.yml文件。
具体内容：
.gitlab-ci.yml

stages:
  - build
  - deploy
  - build_app
  - deploy_app1
  - deploy_app2
include:
 - local: /.gitlab/app-test.yml
 - local: /.gitlab/app-online.yml

.gitlab/app-online.yml

.template: &template_online_app
  only:
    refs:
      - master
    changes:
      - parent/app/**/*
  tags:
    - parent

build_online_app:
  stage: build_app
  <<: *template_online_app
  script:
    - echo '开始构建' $CI_PIPELINE_ID
    - cd parent
    - mvn  install
    - ls
    - mvn -pl app clean package -DskipTests -Ponline compile
    - ls qb-app/target
    - scp -P 19999 app/target/app.war root@salt的IP:/srv/salt/parent/apponline
    
deploy_online_app1:
  stage: deploy_app1
  <<: *template_online_app
  script:
    - echo '开始部署app环境1'
    - ssh -p 19999 root@salt的IP "salt -L '部署环境1的IP' state.sls parent.apponline"
  environment:
    name: online
  when: manual

deploy_online_app2:
  stage: deploy_app2
  <<: *template_online_app
  script:
    - echo '开始部署app环境149'
    - ssh -p 19999 root@salt的IP "salt -L '部署环境2的IP' state.sls parent.apponline"
  environment:
    name: online
  when: manual

.gitlab/app-test.yml

在.template: &template_dev_app
  only:
    refs:
      - develop
    changes:
      - parent/app/**/*
  tags:
    - parent

build_dev_app:
  stage: build
  <<: *template_dev_app
  script:
    - echo '开始构建' $CI_PIPELINE_ID
    - cd parent
    - mvn  install
    - ls
    - mvn -pl qb-appconf clean package -DskipTests -Ptest compile
    - ls qb-appconf/target
    - scp -P 19999 app/target/qb-appconf.war root@salt的IP:/srv/salt/parent/apptest
    
deploy_dev_app:
  stage: deploy
  <<: *template_dev_app
  script:
    - echo '开始部署测试环境'
    - ssh -p 19999 root@salt的IP "salt -L '测试环境的IP' state.sls parent.app"
  environment:
    name: test