项目管理实践

发表于 | 分类于

前言

学校教过软件工程，但最后除了文档内容&规范其他剩下的并不多(形成了写文档的习惯)，真正具有实践指导意义的项目流程理解还需亲身经历。这里简记下具有实践意义的内容。

持续集成

这可能是对开发人员最有意义的内容了。
做的事情就像团队的一个中立的第三者，审视着团队的每一次代码变更，尽早的暴露集成问题，但是暴露集成问题需要一些自动化手段，包括自动化测试、代码扫描等，做好持续集成最核心的是自动化测试。

直接说应该怎么做:

  1. 除了每个人的开发机外，应该有一个持续集成服务器，功能有:远程仓库、构建、安全扫描、测试、（可选:加固、发布）
  2. 使用源码管理系统(git等)，只维护一个源码仓库，应该把所有东西放进去，保证可以在一台干净的计算机上重做所有过程。尽量少使用branch(仅维护和临时实验)。一般一个mainline就足够了。
  3. 每个程序员的工作:下拉最新代码、写代码、写测试代码、本地启动自动化build、提交代码仓库(若期间mainline变动了需要先把其他人的修改更新到本地，并解决冲突，返回本地测试直到提交不会冲突且本地build成功）、在mainline的环境中做自动化build、集成完成。
  4. 第三步的周期应该是每个人一天最少一次

须知

  1. 源码管理系统存放的东西应该保证可以在一台干净的机器上构建
  2. build需要自动化，节约时间且减少错误，build使用脚本，而非ide
  3. build应该自动测试
  4. 每人每天至少提交一次完整的集成
  5. 每次提交最终都需要在集成计算机中做build(使用mainline)也就是说始终保证mainline的健康。build应该在每次提交后，可再加上定时任务
  6. 当mainline上build失败时，第一时间修复就成了头等大事。可以放一个报警器在工作室
  7. build的速度应该保证，否则会拖慢整个的进度-可以采用分阶段的形式
  8. build包含一定的测试，并有生产环境测试
  9. build状态应该一直被显示，放个灯在工作室
  10. 提交前本地一定要解决冲突与build测试，不要污染主线

好处

频繁的集成可以保证:

  1. 每个人都及时跟进总任务进度，任务进度永远是可预见的，降低风险
  2. 错误发现及时，错误发现的越及时就越好改
  3. 产品是一直可预览的

持续交付

在持续集成的基础上，更进一步，持续交付系统上点击一个按钮就可以完成从编译到版本上线的动作。
技术侧是要能做到每一次代码提交都要可交付的。

此时集中服务器应该还管理证书、异常上报SDK自动接入、发布相关功能的管理等功能

持续部署

对于每一次代码变更，都要能部署到生产环境。
特别需要热更新的基础支持。

git相关再记

虽然一直用但没怎么记录和深入理解过…

fetch下拉远端的分支到本地，但是不进行与本地库的合并，可以检测本地库是否可提交(合并)到远端库
pull后会将本地支合并到下拉的远端支，此时本地的修改可以成为远端支上的一次提交，此时可以push

pull时:
原:
1 2
1 2

如果本地什么都没做，远端有修改(提交)
本地变为远端的样子
1 2 3
1 2

此时如果本地有修改没有提交到本地支，远端有修改(其他提交)
会提示本地修改需要提交，否则会失去
1 2 3
1 2(有修改未提交)

此时如果本地有修改没有提交到本地支，远端无修改(其他提交)
一样的状态，所以什么都不会发生
1 2
1 2(有修改未提交)

如果此时修改的在本地并且已经提交，远端也有修改，则分俩种:
有冲突:需要修改冲突进行合并，此时相当于在远端拉下的之中进行了修改提交的支
无冲突:修改部分不同，可以直接合并，成为基于远端拉下之中进行修改提交的支
1 2 3
1 2 4

如果此时修改的在本地并且已经提交，远端无修改，
本地不变，因为比远端的多了一次提交，可以直接push
1 2
1 2 3

有修改提交代表着有新的节点，以线上的节点形容好理解些

实际使用时

下班时的样子:
1 2
1 2

上班时的样子:
1 2|1 2 3
1 2|1 2

pull即可成为:
1 2 3
1 2 3

写代码，成为上面的6种之一，pull，修改，成为:
1 2 3
1 2 3 4

之后build测试、push。
push仅在pull之后成为如下时:
1 2 3
1 2 3 4

补充

分支一般用于新功能研发和破坏性测试。以及个人的分支一般用于提交前的build测试。

主干必须严格把控，一般主干提交代码前先交CR。

git为分布式，svn集中管理。
git内容按元数据存储，svn按文件。
svn的分支就是版本库中的另外一个目录。
git性能更优。

svn的操作:
必有svn中央服务器，在这里称为远端
svn比git简单些，客户端下载好后右键就集成了所有操作。
步骤:

  1. 找到自己的分支，从远端中央检出
  2. 开发、及时更新，提交
  3. 远端trunk定期合并(同步)到远端分支，一般会提供相关管理功能
  4. 持续集成
  5. 最后完成模块时远端分支合并到远端trunk。