Gitlab使用总结
gitlab
我们公司选取了gitlab作为代码仓库。
gitlab从头到尾都是模仿github的主要功能，但github的企业版很贵，而且对于公司来说，代码最好是放在自己的server上。gitlab社区版是免费的，很适合中小型公司。gitlan功能很丰富，包含邮件通知，进度看板，issue管理追踪，pipelines管理等。基本可以满足一站式的流程管理需求。
git flow
由于使用了git作为版本管理工具，那么Git flow就是我们协作管理的最好选择。结合gitlab的issue功能，可以引申出 gitlab flow。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。gitlab flow详细介绍可以看阮一峰的博客。
gitlab flow的优点，也是它的缺点。由于有了多个分支对应不同的功能，所以分支之间和明确。新的功能开发、bug修改、测试上线，都可以很好的进行隔离。但与此同时，一个项目要进行多个分支的维护，也是很麻烦的事情，尤其是在项目前期阶段。所以，在项目前期阶段，可以不用很严格的遵循gitlab flow，等到项目稳定后，再使用gitlab flow统一管理。
代码review
代码review在项目开发中是很必要的，可以防止项目代码变得越来越糟糕，或者谁误修改了不该修改的模块。在gitlab真难过，可以设置event事件相关联的webhook，在这些事件发生时通过 HTTP POST 方式通知( 超时5秒) 到第三方应用指定的 Web URL。例如项目有新的内容 Push，或是 Merge Request 有更新等。
在我们的项目使用中，是将主要分支，如develop、release等设置为了protected，除非具有master权限，否则不能直接向被保护分支提交代码，只能通过merge的方式。
对merge事件配置个webhook，具体设置可以看gitlab官网。在bug分支修改好bug后，提交merge request，指派给同组的其他人，同组人review代码后，就可以合并到受保护的分支了。
在使用这套review流程时，需要设置代码的部署只能从受保护的分支进行，否则就失去强制性code review的意义了。
wiki
虽然在项目中使用了swagger，但wiki还是少不了的，比如开发规范、功能流程、环境节点等等，都需要这么一个平台。在我之前的公司是使用wiki，方便好用。不过这是个收费软件，小公司也负担不起，而且gitlab的功能已经能满足大部分公司的需求了。缺点是支持的最好的是markdown文档格式，而且当你在页面上直接输入中文时，会错乱的让你措手不及，附件上传等功能也缺失的比较多。
issue与看板
gitlab与github一样，有issue这个选项。好处是可以和代码管理在同一处，避免了管理工具的分散，而且gitlab有邮件通知功能，issue的指派和回复都会发送邮件给该issue关注人。缺点是issue虽然有个due date的设置，但无法对该日期进行很好地跟踪和管理。gitlab的issue更多的是该项目出现过的需求、功能的备忘列表，而不是类似于jira一样的成熟issue管理工具。
当项目或者团队过大时，gitlab的issue就会很吃力，这时建议选用更好的issue管理工具。
CI
在配置CI时，有一个取舍的问题，当项目由多个模块、多个微服务组成时，有两种选择：
1. 将该项目视为一个project，其中的模块、微服务视为单个文件夹
2. 将该项目视为一个group，其中的模块、微服务视为单个project
选用第一种的好处是在同一个project下issue，tag，branch都容易管理，更清晰。坏处是该project为同一个的大版本，和微服务的原则不是很符合；当进行CI webhook配置时，无论是基于push request的还是基于merge request，都会造成某个模块的代码提交或合并后，项目中的所有模块全部重新构建打包。
选用第二种的好处是更加分离，更符合微服务的规范，坏处自然是因为project增多而来带的治理困难。
对于我们公司来说，选用的第一种模式，因为我们团队没有很好的issue管理平台和看板等功能，当能使用gitlab的功能满足需求时，就会选择更容易使用这些功能的方式。通过webhook与jenkins关联，当merge request成功后，触发jenkins对项目打包。