Gitlab

  • 一直以来都在做团队里的基础性工作,直到最近,成果开始慢慢展现,尤其是上周刚看完《持续交付》这本书后,总结已经做的工作,又有了些新的感悟。

    过去一段时间,我都是围绕着 Gitlab 的一些功能来开展的,从最开的代码与应用配置管理,然后到 CI 系统,提升代码质量,到最后完整的持续交付流程提升团队工作效率。

    那么我就结合《持续交付》这本书的内容,正文开始。

    为什么要有持续交付

    1. 不敢发布新功能:每次发布都会心惊胆战,因为一下子发布了太多功能,测试又没做好,而这时候产品催着要上线。另外按照以往的经验,由发布而出问题的的概率最高;
    2. 线上事故处理时间长:每次出线上事故,不能很快定位问题,如果是由于同事线
  • 前言

    在使用 SVN 的时代,一旦一个文件被锁定,其他人都无法修改的情况时常出现,着实让人头痛。Git 横空出世之后,大家因为它带来的便捷性非常有价值纷纷改为这个:它有一系列非常有意义的功能:回滚与重复修改、强大的分支以及 tag 管理、更清晰的历史修改追踪等等。只是,Git 也是由人来使用的,当单个人使用时,无论怎么折腾都没事,而当多人合作开发的时候,就会有各种各样的问题,比如由于 Git 的灵活性,所带来的分支管理与协作流程的问题。

    Git Flow

    这是最常见的协作流程,并且它已经有现成的工具支持:git flow,简单来说,就是把分支分为:

    • master:主分支,用于追踪线上生产环境
  • 在之前的 CI&CD 实践中,我们一直使用的是 Shell runner,简单来说,就是在一台机器上配置好所有的环境,然后序列地去执行任务。

    很明显,好处是配置非常简单,也很容易 Debug,出了问题,登录到机器上去查找即可;然而坏处就是配置迁移麻烦,也非常容易被破坏环境,而且单台机器上并发比较麻烦,好些的方法是需要配置多个机器,只是这就有些有点浪费资源了。

    因此为了更快,我们需要并行地去执行 CI&CD 任务,这就需要换种更好些的方式了。

    选择其他 Runner

    因此在剩下的几个方式中:

    • Docker:最简单,从 Shell 迁移来说,工作量不大;
    • Docker Machi
  • 不知道,你有没有遇到类似的情况:

    • 不重视测试,开发新功能都是手工测试
    • 每次开发新功能,都会懒得去做回归测试,线上经常出问题
    • 新同事来,不熟悉系统,提交的代码会把系统搞坏
    • 测试覆盖率一直非常低

    这时候,你需要个CI,也就是持续集成。

    我理想中的团队开发流程中,CI是最重要的一环,团队成员按照git flow开发,然后提交,等待CI测试通过,最后提交pull request,让同事Code Review。

    在以后,还可以加入CD,即当提交到master通过之后,构建并打包docker,部署到正式环境。

    好处:

    • 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
  • 一直以来,我没有总结过 Gitlab 的部署,而在以前的文章中,我不止一次提到关于 Gitlab 在我们整个交付流程中起到的基础性作用,以及它为整个公司的开发带来的巨大效率提升:

    • 使用 docker runner 加速 gitlab CI&CD
    • 持续交付的实践与思考
    • Git 协作流程
    • CI 系统搭建

    那么作为一个在公司起基础作用的东西,我们应该如何去对待它?

    有钱就花钱,没钱就认怂,能花钱的,就不要花时间。

    下面开始认怂。

    准备工作

    首先,你需要有一台机器。

    然后,看下 Gitlab 官方对应的配置列表(链接请看下面的 Ref)。一般来说,中小公司(人员 500 以下),2