软件工程综合实践专题——第四次团队作业

时间:2021-03-24 21:56:02

 

 

 

1.你的团队的源代码控制在哪里?用的是什么系统?

  答:我们会把所有的代码都会上传一份最新的版本到GitHub上,在windows10系统上操作。

2.一个代码文件被签出之后,另一个人可以签出这个文件,并修改么?有几种设计,各有什么优缺点?

  答:有两种设计:①签出文件后,此文件就加锁,别人无法签出。②所有人都可以*签出文件。一个代码文件被签出,另外一个人可以迁出这个文件并修改。

  优缺点:为了最大化效率,我们没有对文件迁入迁出进行过多的限制。将文件在迁入迁出时加锁,显然可以保证源代码修改的同步性,减少不必要的冲突和错误,但是这样的缺点是显而易见的,由于缺乏了并行性,项目开发的效率就被极大地降低了,极端情况下很有可能因为一个人的失误,导致全队项目的搁浅。反之,我们采用*迁入迁出的方式,则与前者的优缺点互反了。针对这两种设计,我们认为第一种可以保证项目代码版本控制更加合理,不会有类似读“脏数据”的情况出现,但是这样也会花费更多的时间,操作稍微会繁琐一些;相反第二种设计文件不加锁的时候,修改方便,适合我们现在这样刚起步的小项目,但是代码上会出现一定程度上的错乱。

3.如何看到这个文件和之前版本的差异?

  答:使用git diff即可看到文件和之前版本的差异。

git diff:是查看working tree(工作目录)与index file(暂存区)的差别的

git diff --cached:是查看index file(暂存区)与commit(本地仓库)的差别的。

git diff HEAD:是查看working tree(工作目录)和commit(本地仓库)的差别的。

  另外,在Github中,也可以通过可视化的界面来看到每次修改的代码(包括增加,删除)文件与修改的具体位置,修改的具体内容。可以看到每次修改的文件路径、文件的内容、红色代表删除掉的内容,绿色代表添加的内容。

4.如果某个文件在你签出之后已经被别人修改,那么你如何合并不同的修改(merge)?

  答:使用git-merge命令将两个开发历史合并在一起。Git可以方便地对有简单不同的修改进行合并,但对于有逻辑冲突的部分将会给出conflict的提示,这时需要手工修改。针对文件的不同状态给出不同的颜色提示。使用分支,保持主分支的整洁。在分支进行提交,然后切到主分支更新(git pull —rebase),再合并分支、推送。这样的流程会避免交叉合并的情况出现(不会出现共同祖先节点为多个的情况)。

但是,Git会在发生冲突的地方打个标记。比如这样式的:

  <<<<<<< HEAD

  test in Local

  =======

  test in Remote

  >>>>>>> 17c805…(Commit的Hash值)

  ==分割线上方是本地数据库的内容

  ==分割线下方是远程数据库的某次产生冲突的commit所修改的内容。

  这时候我们需要识别哪些都可以保留,哪些保留远程数据库的内容,哪些保留本地数据库的内容。在将文件冲突的内容合并后,删除掉<<<<< 和=====,>>>>>这样的东西,重新add,commit,push,即完成了一次手工合并。

这就需要我们在分配任务时遵循一个原则:尽量不让两个人的任务在同一个文件上产生重叠。每个人修改的文件范围或者其他都固定化,尽量不让两个人同时修改同样的文件。当然,像前端和后端在修改时大部分时候都会产生冲突,这时候我们就会使用另一套机制来帮我们避开这一点:新建分支与分支合并。一般情况下,git pull后git会自动合并Git修改的部分,自动的Merge。但是,也存在无法自动合并的情况:比如像远程数据库和本地数据库的同一个地方都发生了修改的情况,此时Git无法判断要选用哪一个修改,所以就会发生冲突。但是,Git会在发生冲突的地方打个标记!

5.你有20个文件都是关于同一个功能的修改,你要如何保证这些文件都同时签入成功(修改的原子性)

  答: 在签入代码之前,本人应当现在本机上测试,测试通过,便可以很放心的将代码直接签入其中,如果测试不通过,就继续在本机上测试修改知道解决版本冲突问题。在Git中,所有在本地仓库中修改的文件都要统一经过commit为新的本地版本后,再push至远程分支。这保障了本地修改提交的原子性,同时git服务器远程提供的修改操作也具有原子性。这样就保障了整体修改的原子性。可以直接对工程文件进行整个的签入挂起的更改,或者在修改之前为将要修改的文件都上锁,防止在签入的时候进行签出操作。

6.你的PC 上有关于三个bug 的修改, 但是都没有完成,这时你要紧急修改第四个bug,如何把本地修改放一边,保证在干净的环境中修改第四个bug, 并签入修改?

  答:使用branch解决任务切换问题。建一个自己的分支去修改和调试代码, 如果别人或者自己发现原有的分支上有个不得不修改的bug,我们往往会把完成一半的代码 commit提交到本地仓库,然后切换分支去修改bug,改好之后再切换回来。使用'git stash'就可以将你当前未提交到本地(和服务器)的代码推入到Git的栈中,这时候你的工作区间和上一次提交的内容是完全一样的,所以你可以放心的修 Bug,等到修完Bug,提交到服务器上后,再使用'git stash apply'将以前一半的工作应用回来。

git stash

Saved working directory and index state WIP on master: sxu Merge branch 'mas

ter' of https://github.com/siyux/buytickets

HEAD is now at 5655bdc Merge branch 'master' of https://github.com/siyux/buytickets

这时候就会发现,add了以后的东西都被"雪藏"起来,现在的工作区非常干净,我们这时候可以在一个干净的环境中修复紧急的bug并提交,签入,在push后,再使用git stash apply 或者 git stash pop来将保存起来的内容取出来继续开发。

7.如何给你的源代码建立分支?

  答:直接点击 Branch,然后在弹出的文本框中添加自己的 Branch Name 例如sxu然后点击蓝色的Create branch就可以了,这样一来,你这个项目就有2个分支了(master 和sxu),下面显示了创建过程以及创建后而界面

软件工程综合实践专题——第四次团队作业

软件工程综合实践专题——第四次团队作业

软件工程综合实践专题——第四次团队作业

 

分支是为了将修改记录的整体流程分叉保存。分叉后的分支不受其他分支的影响,所以在同一个数据库里可以同时进行多个修改。分叉的分支可以合并。在数据库进行最初的提交后, Git会创建一个名为master的分支。因此之后的提交,在切换分支之前都会添加到master分支里。在Git中可以*地建立分支。但是,要先确定分支  的运用规则才可以有效地利用分支。

 还有一种是在Git命令管理分支,具体操作如下:

  1)Git init (在本地工程目录下),生成.git 文件

软件工程综合实践专题——第四次团队作业

 

  2)git branch命令查看本地分支

软件工程综合实践专题——第四次团队作业

 

  3)用 git branch  sxu本地创建新分支

软件工程综合实践专题——第四次团队作业

  4)git checkout sxu 切换到新分支

软件工程综合实践专题——第四次团队作业

  5) git checkout -b aut

软件工程综合实践专题——第四次团队作业

  6)git push origin 将新分支推送到github

软件工程综合实践专题——第四次团队作业

  7)git branch -d sxu 删除本地分支,注意不能删除当前分支,要先切换再删除

软件工程综合实践专题——第四次团队作业

8.  一个源文件,如何知道它的每一行都是什么时候签入的?

  答:针对一个源文件的每一行是在什么时候签入,在github里有非常好的支持,如下图:

软件工程综合实践专题——第四次团队作业

9.如何给一个系统的所有源文件都打上标签,这样别人可以同步所有有这个标签的文件版本?

  答:使用git来打标签这件事,在Github中是可以很方便来做这件事。每次发布到一定成果后,就需要发布一个realease版本,但是这样的话,是对commit本身打标签。在git里,标签分为两种类型:轻量标签和附注标签。轻量标签是指向提交对象的引用,附注标签则是仓库中的一个独立对象。

想查看tag的话,可以使用git tag来查看,如下:

软件工程综合实践专题——第四次团队作业

如果想回到某个标签时某个文件的状态,那么只要使用git checkout tag(标签名) 即可,如下面这个gif所示:

软件工程综合实践专题——第四次团队作业

10.你的团队是否能部署自动构建的任务 

  答:当我们提交代码到GitHub后,可以在Jenkins上执行构建,但是每次都要动手去执行略显麻烦,今天我们就来实战Jenkins的自动构建功能,每次提交代码到GitHub后,Jenkins会进行自动构建。

Jenkins是一个非常有名的CI工具,开源、免费,通过jenkins我们可以更加智能、快速的持续集成,尽早的发现代码里的问题并及时的部署上去。

首先先下载Jenkins,网址:https://jenkins.io/download/ 

软件工程综合实践专题——第四次团队作业

 

运行压缩包中的msi文件,直接根据提示进行安装,安装好后,在浏览器上打开http://localhost:8080/,jenkins网址,获取并输入管理员密码,密码可在界面上的路径中获取,Jenkins默认无需登录即拥有所有权限,这肯定是极不安全的。这里简单的配置一下,让用户登录后才可以操作。

 

配置后的最终结果截图:

软件工程综合实践专题——第四次团队作业

 

  新建任务:在左侧栏选择新建,填上名称,选择构建一个*风格的软件项目,点击保存,进入到配置页。这个页面涵盖了对这个任务的所有配置。

软件工程综合实践专题——第四次团队作业

  源码管理:选择Git, Repository URL里填上Github的地址,Credentials -> Add,填上Github的用户名密码。这个是Jenkins拉取源码时需要的凭证。 "Branches to build"填上分支名,表示Jenkins将拉取该分支的源码,后面触发器也只针对该分支。

软件工程综合实践专题——第四次团队作业

  构建触发器:表示在什么情况下构建项目,如果选择“Poll SCM”,然后在日程表里填上cron表达式,例如"H/5 * * * *",表示每5分钟检查一次,有代码变更就构建项目。这里我们不选Poll SCM,而是用Gitub插件来做到实时构建。在“构建”配置里,选择“增加构建步骤”,选择“Execute shell”,即可填写你要执行的构建命令。对于Java项目,这里一般是Ant或Maven命令。对于我们项目,主要是执行shell命令。

软件工程综合实践专题——第四次团队作业

构建后操作

构建后操作分两种情况:

  • 构建成功后,将程序部署上去;

  • 构建失败后,发送通知邮件。

但是无论是部署程序还是发送邮件,在“增加构建后操作”里都找不到对应的选项。所以还需要安装一些额外的插件。

按照上面所说的安装插件的方法,安装以下两个插件:

  • Post build task

  • PostBuildScript

这两个插件都是用来执行shell脚本的,不同的是Post build task插件可以根据不同的构建输出做不同的动作,当前面构建失败时,可以通过匹配失败的输出来执行发送邮件操作。

构建成功后自动部署

增加构建后操作步骤 -> Execute a set of scripts,在Command里填上部署脚本,并勾上Execute script only if build success。这样就实现了构建成功自动部署。完成以上配置后,就实现了项目的CI/CD。Jenkins非常灵活,以上步骤需要根据自己的实际情况做调整。