git开发过程——Release开发

题记：

• 开发（Development）偏向于软件工程（Software Engineering）这一端，涉及到进度管理，软件架构，交互设计等等，侧重于团队，目标在于让团队按时交付可用的软件。

• 学校里侧重编程，公司里侧重开发。

• 编程为开发提供理论基础，开发把编程转化为商业价值。

---《新人入职100天，聊聊自己的经验&教训》

 

正文：

多人协作开发的目标： 让开发者之外的人，感觉就像一个人在开发那样：

首先，code是”次序“累积的。

每一段code，其在code层面的assumption都是唯一的（不同的assumption会导致不同的代码）。这样，程序才不会有”二义性“。

其次，在一段时期内，每个人负责一个模块的开发、bugfix。

软件是复杂因而脆弱的。复杂，决定了对于开发者来讲，为了理解、修改一个功能，必须花很多时间，阅读源码（向大脑中载入缓存）、寻找触发功能所有可能的入口（领域知识）、修改所有的code path、手动测试所有的code path。

同时，一条 code path，也会涉及到其他module的 条件。

因此，脆弱：修改一条path，可能引入新的bug。

所以，

原则：

如果 QA/PM 要求改一个你不熟悉的模块（尤其是产品要上线的时候），让其提给这个module的当前负责人。

 

Release开发的主要任务：

（1）快速实现原型 => 推翻产品的设计，衍生出新的需求，从而完善：修改代码。

（2）

 

开发还没开始时，PM 会通过JIRA 建立 feature。feature的粒度，是同一个module的不同功能点。

注意：

之所以这样， 是遵循 small step by step。有这样的好处：

（1）对于QA，分成小块，意味着对”小块“的测试时间更多，这样，

a. 避免”空当”期（让他们忙碌起来）。

b. 测试更细致。

c. 发现错误更早。

（2）在QA测试之后，对于PM，如果可能，及早“纠正”不现实的想法，修改产品设计。

（3）对于开发，由于模块存在”耦合性“，不排”代码级别的dependency“。这样，小的迭代，可以更快地在 Release分支，体现出来，让其他的code看到。

 

新的Release开发阶段

第一件事，从develop分支“新建release分支”。

新的feature分支在 “新建release分支”上开发。每个feature，单独成为一个“feature分支”。

操作：

（1）JIRA上修改状态。

（2）基于Release分支，local create”新建feature分支”。

注意：1. pull 最新的 Release 2. create branch based on Release

（3）向remote推送“新建feature分支”。（这一步，为了今后的 code review： 正常过程，remote 总是落后于 local 一个 commit，

在diff的时候，就可以直接比较 base 和 git/origin/feature分支名字。）

 

feature分支的任务：新需求的开发、测试、bug修正。此时，处于feature functional testing 阶段.

当一个feature 通过了 QA testing之后， 就应该 immediately 合入 Release分支。

（1）及早呈现修改后的最新的代码。

（2）避免大的merge（rebase）。

通常，一个Release中，一个开发者通常要开发多个feature，之前的习惯：feature 累计在 ”总的feature分支“中，QA全部通过测试之后，才提交到代码目录中去。

这样，通常对代码的改动，其他开发者要延迟很久（所有feature的排期！）之后，才能看到code发生了变化。

因此：

操作：

（1）arc land –onto Release/xxx ( 删除old的feature分支，合并入 Release 分支）。

（2）lync通知QA，可以测试。（QA负责多个模块，可能会爆满）。

 

feature通过functional testing之后，来到 integrated testing 阶段，首先删除feature分支，之前将feature分支合入“新建release分支”。

现实：

(0) 通过 functional testing之后，几乎

(1) 每个开发者feature分支 通过测试，进入合包点的时间有先后。

(2) 每个feature是有”耦合“的：逻辑上（比如进度条覆盖了提示条）、代码功能。

=>

(1) 整包测试要反复进行（每当几个feature集中到一起）

(2)