工程管理与工作流

1 统一开发环境/ 协作工具

你知道开发环境指的是什么吗？ 

开发环境：

工程运行环境、开发工具/ 编辑器 、开发依赖环境、 配置文件 

软件环境：

“仿真预演”环境 Staging 

生产环境前最终验证、 这一环境尽可能的仿真了真实的生产环境 、另一个关键是用于性能测试，特别是加载时间 

开发环境 Development 

往往创建在开发者的设备上 、软件环境软件在这个环境下开发 、一个沙盒环境 

生产环境 Production 

也被称为线上环境 、向生产环境部署是最为敏感的步骤 、生产环境出现问题会导致严重的后果工程运行环境 

测试环境 Testing 

允许人类测试者采用自动化或非自动方式进行测试 、如果测试失败，测试环境会将这部分 并通知对应开发者 

你所了解的协作工具有哪些？ 

你们之前开发环境都选用过哪些呢？ 

为什么要对它们进行统一呢？ 

2、工程管理与工作流

在软件项目管理中我们关心什么 

需要关注钱的问题吗？ 

需要关注时间吗？ 

还需要关注什么呢？ 

关心：

在预算之内 、在计划时间之内 、工程质量良好 

W5HH 计划 

这个功能为什么要被开发？ 

将要做什么，什么时候完成？ 

谁负责来实现？ 

他们的机构组织位于何处？ 

从技术和管理上这个功能可以怎么被完成？ 

有哪些资源应该被需要到？

Umbrella activities ：

测量 & 数据矩阵 

预估

风险

排期

追踪与控制 

做好工作的拆解：

将任务拆解为多个部分 ：

产品、过程、组织 、自上而下的拆解 、考虑全局的分析与组织 、确保没有遗漏 、考虑现实性 

做好排期 ：

问：一个项目是怎么会延期了一年的呢？ 

答：每次遇到问题延迟一天就足以导致这个结果

工作流是什么？ 

我们做开发是怎么做的呢？ 

需要按哪些步骤进行？ 

每个步骤之间关系是什么？ 

项目级的工作流 ：需求 、评审 、设计 、开发、审计与测试 、部署与监控 

有了工作流之后

开发切忌偷工减料 

工作流是提升效率的，而不是降低效率的 

在执行前要有约定好的惩罚性、奖励性措施 

3、需求来自哪里

探索性项目需求 、针对性项目（用户需求不明确 ）、针对性项目（用户需求明确）

 

4、Git 

我们面对的问题：

多个人需要共同参与一个软件开发
一个软件可能有多个要支持的版本
一个软件可能会用多种不同的运行环境

版本的基准：

根据质量管理所需确定的阶段性规格说明，这个说明应是被正式评审认可的。 

之后的开发过程都应该要遵循“基准”的要求进行。 

对于基准的修改是要极为慎重的，要通过严格的变更流程。 

例子： 

Baseline A ：所有接口应被完备的定义，各方法的内容为空。 

Baseline B ：所有的数据访问方法应该被实现并测试。 

Baseline C：GUI 被完成

基准的命名：

基准的命名有一个非常常用的三点命名法。
A.B.C（如9.3.1）
A：从用户（消费者）角度看到的发布出的标记数(Release)
B：从开发者角度看到的关键的版本(Version)号
C：从开发者角度关注的修改版本(Revision)号

术语定义：发布(Release)     版本(Version)     修改(Revision)
版本(Version)：最初发布或再发布的“代码及其附属品”的组合，它应该是可被完整编译或被认定为完整可用的。不同的版本表现出不同的功能特性。
修改(Revision)：对于一个版本的修改，只做了代码设计的错误修正，对于已经“附属品”中文档所描述的功能特性没有任何改动。
发布(Release)：被批准的面向用户进行分发的版本。

本地Gt仓库的三个分区：

01     工作目录（修改/没修过的文件）working directory
02     暂存区（暂存的文件）staging area
03     Gt仓库（提交的文件）repo

基本的Git使用：

配置一个Gt仓库：
Git init创建Git仓库，让当前目录处于Gt管理之下
Git clone将一个已经存在的Git仓库克隆到本地
Git config对Gt的基本配置进行设置（如邮箱、姓名）

 

 

创建仓库
01在当前目录下创建   git init
在指定的目录创建
02git init<指定的目录路径>
03创建一个bare git仓库   git init --bare myrepo.git

 

 

 

 

 

 

 

 

Git 的多人协作 / 远程仓库:
 

分支

01查看现有分支  git branch  创建分支
02  git branch<分支名>
03  切换分支   g it checkout<分支名>    创建并切换到分支
04  git c   checkout-b<分支名>    删除分支
05 git branch-d<分支名> 

合并的默认行为

只执行g it merge时，如果可以fast-forward,则fast-forward,否则进行non fast-forward merge。
在non fast-forward merge过程中，会尝试合并修改
如果发生不能自动合并的冲突，则需要手动解决冲突。

 

 

 

 Gitlab 工具

任务管理与计划:

在 Group 中建立 Milestone 

在Group / Repo 拆分任务，建立 Issue 关联 Milestone、设置 Deadline，并评估完成时间 在开发过程中关注任务计划 

 

Issue的使用

01Group中的ssue:不具体到某一个部分的开发
02 Repository中的Issue:具体到某一个部分的开发
03无论是哪个部分的Is$ue都应该是可以被完成、关闭的 

 

 

 

 

 

3、代码提交与测试、审计

 写完代码提交有什么要求
01一个分支关联一个1ssue,一次提交只做一件事情
02提交的内容应该与分支目的相关
03提交信息首字母要大写、要关联到Issue

持续集成与Code Review
01发起Merge Request后测试会自动跑
02在自动化检测通过后，我们可以进行人工Review
03人工Review后可以批准修改，之后可以由对MR发起人或项目负责人完成合并