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发起人或项目负责人完成合并