您的位置:www.85058.com > 互联网资讯 > Pre-commit和post-deploy已死,请用Git分支

Pre-commit和post-deploy已死,请用Git分支

发布时间:2019-11-03 06:44编辑:互联网资讯浏览(68)

    此外,偶尔性检查代码库也没有意义。

    Stages

    Stages表示构建阶段,说白了就是上面提到的流程。我们可以在一次 Pipeline 中定义多个 Stages,这些 Stages 会有以下特点:

    • 所有 Stages 会按照顺序运行,即当一个 Stage 完成后,下一个 Stage 才会开始
    • 只有当所有 Stages 完成后,该构建任务 (Pipeline) 才会成功
    • 如果任何一个 Stage 失败,那么后面的 Stages 不会执行,该构建任务 (Pipeline) 失败

    因此,Stages 和 Pipeline 的关系就是:

    +--------------------------------------------------------+
    |                                                        |
    |  Pipeline                                              |
    |                                                        |
    |  +-----------+     +------------+      +------------+  |
    |  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
    |  +-----------+     +------------+      +------------+  |
    |                                                        |
    +--------------------------------------------------------+
    

    每个阶段包含有一个或多个工序(jobs),比如先购料、组装、测试、包装再上线销售,每一次push或者MR都要经过流水线之后才可以合格出厂。而.gitlab-ci.yml正是定义了这条流水线有哪些阶段,每个阶段要做什么事。

    Jobs表示构建工作,表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs,这些 Jobs 会有以下特点:

    • 相同 Stage 中的 Jobs 会并行执行
    • 相同 Stage 中的 Jobs 都执行成功时,该 Stage 才会成功
    • 如果任何一个 Job 失败,那么该 Stage 失败,即该构建任务 (Pipeline) 失败

    所以,Jobs 和 Stage 的关系图就是:

    +------------------------------------------+
    |                                          |
    |  Stage 1                                 |
    |                                          |
    |  +---------+  +---------+  +---------+   |
    |  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
    |  +---------+  +---------+  +---------+   |
    |                                          |
    +------------------------------------------+
    

    图片 1

    untitled1.png

    端到端部署

    https://v.qq.com/x/page/z03959pwc0r.html

    图片 2

    http://115.28.84.155/org/index.do
    http://123.56.64.36:9000/projects
    http://115.28.86.238/
    

    随着新业务的增加和老业务的不断优化,项目中的代码也在一直增加,当代码量达到几十万行的时候,人工审查肯定会费时费力,所以有了 SonarQube代码质量管理平台,通过配置审查规则,让程序帮你检测代码中潜在的bug,让耗时操作通过机器完成,节约人力成本

    sonarQube能带来什么?
    1.Bugs和漏洞
    检测代码中的bug和漏洞

    2.坏味道
    检测代码中潜在的错误

    3.重复
    显然程序中包含大量复制粘贴的代码是质量低下的 sonar可以展示源码中重复严重的地方

    4.结构
    检测代码行数,代码的组成成分,和占用的百分比

    5.注释量
    检测代码注释的量

    6.依赖关系
    项目结构

    图片 3

    图 1. 质量纬度

    图片 4

    图 2. SonarQube 的服务架构

    Pre-commit预提交审核

    分支管理策略

    一、主分支 Master

    首先,代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。

    master分支上存放的应该是随时可供在生产环境中部署的代码,它承担的责任就是:仅在发布新的可供部署的代码时才更新到master分支上的代码。当开发活动告一段落,产生了一份新的可供部署的代码时,master分支上的代码会被更新。同时,每一次更新,最好添加对应的版本号标签(TAG)。

    二、开发分支 Develop

    主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做Develop。

    develop分支是保存当前最新开发成果的分支,它承担的责任就是功能开发完毕等待最后QA的验收,通常这个分支上的代码也是可进行每日夜间发布的代码。当代码已经足够稳定时,就可以将所有的开发成果合并回master分支了。

    三、临时性分支

    除了常设分支以外,还有一些临时性分支,用于应对一些特定目的的版本开发。:

    辅助分支是用于组织解决特定问题的各种软件开发活动的分支,它的生存周期伴随着它的功能完成而消失。辅助分支包括

    • 功能(feature)分支
    • 预发布(release)分支

    • 修补bug(fixbug)分支

    这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。

    四、功能分支

    第一种是功能分支,它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。

    图片 5

    img

    功能分支的名字,可以采用feature-*的形式命名。

    创建一个功能分支:

    # 这里x可以定义为自己名字的缩写,比如hxg
    git checkout -b feature-x develop
    

    开发完成后,将功能分支合并到develop分支:

    git checkout develop
    
    git merge --no-ff feature-x
    

    删除feature分支:

    git branch -d feature-x      
    

    五、预发布分支

    第二种是预发布分支,它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。

    预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支。它的命名,可以采用release-*的形式。

    创建一个预发布分支:

    #这里版本号可以定义为3位,
    git checkout -b release-1.2 develop
    

    确认没有问题后,合并到master分支:

      git checkout master
    
      git merge --no-ff release-1.2
    
      # 对合并生成的新节点,做一个标签
    
      git tag -a 1.2
    

    再合并到develop分支:

    git checkout develop
    
    git merge --no-ff release-1.2
     
    

    最后,删除预发布分支:

    git branch -d release-1.2
    

    六、修补 bug 分支

    最后一种是修补bug分支。软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。

    修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。它的命名,可以采用fixbug-*的形式。

    图片 6

    img

    创建一个修补bug分支:

     git checkout -b fixbug-0.1 master
    

    修补结束后,合并到master分支:

    git checkout master
    git merge --no-ff fixbug-0.1
    git tag -a 0.1.1
     
    

    再合并到develop分支:

     git checkout develop
    
     git merge --no-ff fixbug-0.1
    

    最后,删除"修补bug分支":

    git branch -d fixbug-0.1
    

    工具:

    TortoiseGit,SourceTree

    gitlab DevOps全生命周期管理

    issue

    issue是项目管理中的重点,主要包括以下功能:

    1. 用于登记bug与需求
    2. 可以按照issue类型不同打上不同的tag
    3. 每个issue在每个project中有唯一的id
    4. 项目负责人可以@相应的开发进行开发
    5. 在经过单元测试和code review后,如果功能点符合,可以关闭相应的issue
    6. 可以通过gitlab的web界面进行相应的分析,比如按照tag和assignee进行筛选

    git、github、gitlab的基于git分支流程之前虫虫的文章曾经专门介绍过,最后在此介绍下gitlab基于git分支的代码审核流程。gitlab的分支流程以master分支为基础,只有master接受的commit才可以合并得到其他分支

    Gitlab 可以做什么

    • Gitlab 是 Git 服务端的集成管理平台,提供了:
    1. 代码托管服务
    2. 访问权限控制
    3. 问题跟踪,bug的记录、跟踪和讨论
    4. Wiki,项目中一些相关的说明和文档
    5. 代码审查,可以查看、评论代码
      1. 持续集成

    熟悉版本控制的人知道,在项目源代码控制流程中Pre-commit预提交和部署后代码审查(post-deploy)是用来做代码提交控制,提高代码质量的有效的方法。这些方法在Git大流行的今天还有意义么?前一段时间著名Git服务器厂商Gitlab公司CEO Sid Sijbrandij撰文发表了他的看法认为"Pre-commit和post-deploy已死,应使用更有效的Git分支,本文虫虫跟大家一起来解读下sid的观点。

    git

    Git是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件

    图片 7

    Pipelines

    Pipelines 是定义于.gitlab-ci.yml中的不同阶段的不同任务,里面可以包含多个流程,如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。

    任何提交或者 Merge Request 的合并都可以触发 Pipeline,如下图所示:

    +------------------+           +----------------+
    |                  |  trigger  |                |
    |   Commit / MR    +---------->+    Pipeline    |
    |                  |           |                |
    +------------------+           +----------------+
    

    我把[Pipelines]理解为流水线,流水线包含有多个阶段(stages),

    gitlab MR列表

    持续集成

    持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件。

    1. 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
    2. 防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。

    [Gitlab-CI]是GitLab Continuous Integration(Gitlab持续集成)的简称。
    从Gitlab的8.0版本开始,gitlab就全面集成了Gitlab-CI,并且对所有项目默认开启。
    只要在项目仓库的根目录添加.gitlab-ci.yml文件,并且配置了Runner(运行器),那么每一次合并请求(MR)或者push都会触发CI [pipeline]

    在gitlab流程结合cicd自动化栈实现了全栈DevOps生命周期管理。

    commit

    commit message可以用于追踪问题,所以
    对于Git的commit的message,尽量详细的说明本次提交主要干了什么,是fix 什么bug,开发什么特性,还是update 某个功能点,这同样有助于进行code review

    Git分支更有效率

    Git 使用原则

    • 不建议留任何未提交文件就去拉取,fetch也好,不要贪拉
    • 拉取不成功,解决冲突,提交不成功,解决冲突,解决不了冲突,请联系队友
    • commit 写好注释

    图片 8

    Git tips

    #查看提交暂存区和版本库中文件的差异
    git diff--cached
    
     gitlog --stat             #查看简单的diff结果,可以加上--stat参数
    
    git tag -a v1.4 -m 'my version 1.4'
    git log --oneline
    #放弃工作区的修改
      git checkout <file-name>
    #存储当前的修改,但不用提交commit
      git stash
    
     # 切换到Master分支
      git checkout master
      # 对Develop分支进行合并
      git merge --no-ff develop
      
    #删除feature分支:
      git branch -d feature-x
    #删除远程分支:
      git push origin --delete <branchName>
    

    一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找。

    [git 版本管理]http://www.ruanyifeng.com/blog/2012/07/git.html

    共同的事

    Gitlab基于Git分支的代码审核流程

    Gitlab-runner

    Gitlab-runner.gitlab-ci.yml脚本的运行器,Gitlab-runner是基于Gitlab-CI的API进行构建的相互隔离的机器(或虚拟机)。GitLab Runner 不需要和Gitlab安装在同一台机器上,但是考虑到GitLab Runner的资源消耗问题和安全问题,也不建议这两者安装在同一台机器上。

    Gitlab Runner分为两种,Shared runners和Specific runners。
    Specific runners只能被指定的项目使用,Shared runners则可以运行所有开启Allow shared runners选项的项目。

    ![](file:///C:/Users/pbh/AppData/Local/Packages/Microsoft.Office.OneNote_8wekyb3d8bbwe/TempState/msohtmlclipclip_image001.png)

    GitLab-Runner就是一个用来执行软件集成脚本的东西。你可以想象一下:Runner就像一个个的工人,而GitLab-CI就是这些工人的一个管理中心,所有工人都要在GitLab-CI里面登记注册,并且表明自己是为哪个工程服务的。当相应的工程发生变化时,GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示:

    图片 9

    img

    stages:
    
      - build
    
    Job:
    
      stage: build
      only:
        - develop
        - master
      script:
        - echo "aa"
    

    .gitlab-ci.yml 是配置CI用你的项目中做哪些操作, 这个文件位于仓库的根目录。

    https://gitlab.com/gitlab-org/gitlab-ci-yml

    post-deploy部署后代码审查

    图片 10

    本文由www.85058.com发布于互联网资讯,转载请注明出处:Pre-commit和post-deploy已死,请用Git分支

    关键词: