Steins;Lab

某团的自留研究所

经历记录:在团队中推广Git版本管理系统

近期,所在的4人小型团队完成了一个重大节点。在这几个月中,我尝试在团队中推行Git,作为代码版本管理和项目跟进的工具。总的来说,不算成功也不算失败。虽然尝试推广的是一个工具,但也许会给其他类型的技术推行提供参考。

 

1. 背景

离开背景谈经历也许是耍流氓。

团队人员为4人,在这个规模沟通起来是比较容易的。沟通的方式我们没有采用企业OA系统,就是最普通的聊天工具——微信。

团队成员背景更偏重于汽车电子软件项目,对汽车行业的嵌入式软件开发流程比较熟悉,但是没有进行过其他类型的软件开发工作。在这个背景下,开发人员更注重的模型代码、功能安全、可靠工具链、V型开发流程、HIL硬件在环测试等内容,对于现代IT企业的敏捷开发、DevOps等概念了解较少。

但本项目的要求不同于汽车电子软件项目。随着项目推进,软件开发本身带来的效率和沟通、文档需求,一些先进的软件工程的方法论和工作流需要被提上日程。

另外,该项目内容不100%为软件开发,意味着也需要一个工具来对整个项目进行项目跟踪和管理。

简短来说:

  • 4人小型团队
  • 无现代软件开发背景
  • 代码管理和项目管理需求

因此,就有了这篇在团队中推广Git版本管理系统经历记录。

Git这个工具虽然早已司空见惯,不过笔者作为一名刚刚下山的菜鸟,本文更想探讨的内容是这次经历本身,例如对项目的影响、成员的反馈、行动阻力等等。

本文的行文分为两条线索:

  1. 工具(Git),包括选型、建设、推广
  2. 经历,包括阻力、影响因素和心得

 

2 建设

 

自我实践

想要推广技术,我的想法是首先自身积累一定经验。自己信服后,才能说服他人。

18年9月,个人最开始使用的Github作为自身的学习积累和代码管理平台,并产出博文。

Git初阶使用笔记(1) – Start Up

如下:

  • PAT机考代码纪录 & 考点管理
  • Git Playground
  • Reinforcement Learning Playground
  • 个人小车 – RaspTank代码库

通过实际使用,掌握了常用的工作流和使用方法。

平台选型建设

回归工具本身,少不了调研和建设的过程。

因为较早接触了Git先入为主,考虑熟练和推广就没用考虑SVN等平台。

对于团队需要的版本管理系统,有如下方案:

1.公有平台的企业服务:

这一类服务商就比较多了,从Github的私有库套餐,到国内Coding.NET和Gitee,都提供了私有团队的托管服务。

2. 自建服务

典型的自建服务器使用Gitlab等软件。

 

最终选择了购买小型云服务器,使用Gogs自建Git平台。

  • 项目周期在5月末即结束
  • 代码安全与隐私
  • 牵扯精力
  • Gogs相对Gitlab硬件要求低,部署简便

如果团队更大,基础设施这部分可能就会涉及到一个部门的职责了。

说安全性,这类自建平台的安全性也不可控。恰好前段时间的Github部分私有库被脱,归根结底还是社会工程学和安全意识的问题。

GitHub源码被黑客洗劫和勒索事件 微软也未能幸免

 

二次评估

我需要明确的是,我在这里折腾的动机是什么?是要解决代码版本管理和项目跟踪管理的根本需求。

所以,我进行了二次评估:使用这套工作流程,真的会解决问题吗?

如果读者是一位很熟悉Git的人,你的答案很可能是Yes。不过结合背景,考虑到工期,熟悉上手时间,或是更不可控的反弹呢?

我专门和前项目负责人(指师兄)进行了探讨。达成的共识如下:

  • 结合一直以来容易发生的问题,我们确实急缺版本管理系统
  • 提高效率,会大大节省工作时间,反而划算
  • 但不要追求完美,可以在本次普及部分功能,由有经验的人指导主管,形成工作流的习惯

回想起来,个人觉得最后一点很重要,即普及部分功能,一旦节省出的时间>学习工具的时间,就是划算。

经过二次评估后,这件事可以做。

 

3 运行

技术交流会

作为起步,整理了一份分享在小型碰头会上分享,主要内容:

  • 系统介绍
  • 优势
  • 代码版本管理和项目管理需求

得到的反馈非常积极。

然后着手准备了一次培训会,主要是

  • 工具链的版本控制系统(其实本来用的工具链中就集成了SVM和Git)
  • 拉取、分支、合并
  • issue使用
  • wiki使用

现在觉得感谢战友的耐心和理解。

 

实际使用

实际使用中,涉及的部分如下

版本管理

基本的代码版本管理功能。分支创建合并由1人负责进行。

项目跟踪

使用issue进行重要节点、里程碑设定。

项目问题讨论、发现、追踪。

文档编写

使用内建Wiki系统作为文档系统。实际使用简洁又方便。

 

尾声与总结

在中期,工作流使用习惯发展得比较理想,现在回想,一个重要原因是 大家还有心情去习惯新的工作流方式。

之前提到了“不算成功也不算失败”,在后期,进入了1周时间的集中办公,导致之前养成的工作流习惯受到极大影响。

  • 本项目不是100%的软件开发,所以会分许多精力到其他事宜上(客观原因)
  • 后期的工作状态逐渐失调,进入赶工状态,步调被打断。在代码整洁之道和一些博客中常常提到这种不健康的工作状态(主观原因)

接下来,可能会做以下事情

  • 将工作流整理成共同守约,不能因为步调失稳废弃,得不偿失
  • 将工作流维护上升成团队共同负责

 

 

 

 

5
说点什么

avatar
3 Comment threads
2 Thread replies
4 Followers
 
Most reacted comment
Hottest comment thread
4 Comment authors
fandySPtuanJohn Raymondrepostone Recent comment authors
  Subscribe  
最新 最旧 得票最多
提醒
fandy
游客
fandy

狠啊,我现在还经常忘记更新本地代码版本导致和远端仓冲突,造成一片混乱又不好合并的尴尬局面,最后只能备份代码删库重建2333 (快更香港游记)

John Raymond
游客
John Raymond

太狠了 DevOps工程师

repostone
游客

居然还自带漫画。