再见 phabricator, 拥抱 gitlab
原因
团队使用phabricator大约有小半年的时间, 从使用的情况来看, 效果并不好.
首先, phabricator功能强大, 尤其是它的项目管理功能, 非常灵活, 功能丰富. 但是, 我们的团队规模不大, 但项目并行严重, 所以人力上并不充裕, 很多时候, 项目经理担当着开发的角色, 所以, 项目经理对phabricator的看法是, 用起来比较复杂.
其次, phabricator的代码审查功能没能推动, 团队大约10人的情况下, 同时开2-3的项目, 每个项目上堆积的任务很多, 代码审查前置堵塞提交, 后置审查对我们来说效果并不理想, 这个问题不是phabricator的问题, 是团队管理的问题, 没能切实的做好代码审查的工作.
再次, phabricator的持续集成功能不是很健壮, Harbormaster使用较为复杂, 使用jenkins对我来说又有点太过繁琐了, 所以持续集成这部分完全没有实现.
最后, phabricator在我们的团队中只是充当了代码仓库, 维基和简单项目管理的工具.
改变
因为phabricator的推动是我主导的, 之前代码是托管在svn上的, 为了使用git, 参考了phabricator和gitlab, 但是, 当我看到wikimedia phabricator之后, 我觉得phabricator更适合我们.
然而, 我的决定是错误的, phabricator使用灵活带来的就是更高的管理能力, 或者使用者的自治. 然而以上两点我们都不具备.
现在, 我尝试切换至gitlab, 理由很简单, gitlab更专注于代码本身, 简单的milestones和issues足以支撑小型团队的使用, 而且复杂度更低.
优势
专注于代码
gitlab的功能专注于coding, milestones和issues功能对比phabricator的projects和maniphest功能略显薄弱, 但对小型团队, 已经够用.
更多的惊喜来自于其gitlab-ci-multi-runner, 使用起来类似Travis CI, 配置简单, 使用起来非常顺手.
gitlab-flow
对比phabriactor, 实现git最佳实践的方式是使用arc工具, 而对应gitlab, 它提供了围绕持续集成模式的gitlab-flow.
实际上, arc非常强大, 在命令行中可以轻松执行大量的操作, 但是, 在windows上体验不佳(尤其是显示中文), mac一点问题都没有. 鉴于开发组中, 大量的小伙伴喜欢使用windows(别问我为什么, 我也不知道), 所以arc的一直就没推动. 没有了arc的phabricator可玩性少好多…
gitlab-flow围绕着CI的这种实践给我的感觉就是更加易用, 特性分支开发完成, 提交MR(就是github中的PR), 在确认合并前, 可以代码审查, 以及检视持续集成是否成功等等, 感觉整个流程很合理.
更多的第三方集成
gitlab的第三方集成更加丰富一些, 例如sentry和mattermost已经成功的集成.
更好的用户体验
gitlab的界面更具有亲和力和现代感, 如果和github比较的话, 其实gitlab也不差.