通读《构建之法》与CI/CD工具尝试

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业的要求在哪里	作业要求
我在这个课程的目标是	积累软件开发经验，提高工程能力
这个作业在哪个具体方面帮助我实现目标	通读课本，了解基本教学方向；初试CI/CD，为以后的项目做准备

一、阅读提问

1. 对于书中4.4代码复审部分提到的

   复审者有权提出很多看似吹毛求疵的问题，复审者不必亲自调查每一件事，开发者有义务给出详尽的回答。

   我不反对复审者需要随时向开发者提问关于代码实现方面的问题，毕竟这可以大大节约复审者的时间，方便他更好地理解代码（虽然同时也耽误了开发者的时间），但是首先一个小问题：这种提问是否能通过查看开发者规范的代码注释达到呢？

   另外，我的疑问是：既然代码复审如此重要，那么如若复审者不去仔细地读每一行代码，而是直接对开发者提问的话，一方面，书中也提到开发者对自己总是过于自信，那是否会存在一些被开发者自认为 完成/正确 的细节部分被忽视 ，从而遗漏到开发后期呢？

   另一方面，理论上来说，复审者的思考也不是全面的，尤其是在不了解开发细节的情况下，那在这时，如果复审者自认为已提问了此部分代码的全部可能出差错的问题，然后就pass了这部分代码，是否很也有可能造成一些未思虑到的细节上的遗漏呢？

2. 在书6.2敏捷流程的问题和解法中，提到了每日例会的重要性，在一个公司的团队开发中，因为每人都有一整天的时间在从事这项工作，且他们在公司中想要找个地方开个会也很方便，但是对于我们这种情况，由于日常还要上课，也同时有别的任务，且每人的安排不同，若仍强调每天开会汇总进度的话，首先可能我们一天的进度很小甚至有人没有，其次要聚在一起开会也是一件要花许多时间的事情，就像8.6计划和估计中的PM说的

   我们本来是可以按期完成的，现在开了一天会，我们已经延期了一天。

   所以这个时间跨度是不是可以放长一点呢？

3. 在6.5敏捷的故事中有这样一个场景

   软件团队开会, 领导说: 我们要采用敏捷的开发流程. 很简单, 就是木有计划, 木有文档, 马上写代码, 随时发牢骚。

   工程师问: 培训有木有?

   领导说: 有, 刚才就是培训. 散会! 现在可以写代码和发牢骚了.

   我放在这里也不是纠结于它草率的语言表达的问题（虽然我并不能理解，但可能它就是个笑话），而是单纯地对敏捷开发仍有一些概念上的疑问，书中说

   ”敏捷流程”是一系列价值观和方法论的几何。

   百科定义说

   敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

   似乎强调了”以用户需求为核心“，还有一些”方法论“、”分而治之”等思想，这看起来都是在普通的软件工程的项目流程中也会强调的，所以敏捷开发到底是什么呢？它到底特别在哪里呢？

4. 在书中11.6的讨论3中，有这样一个提问与回答

   问： 在项目开始之前, 有很多队员还没有接触过编程语言（例如C#），导致PM在分配任务时很难用时间来衡量，就拿写一个Web Service这一模块来说，一个熟练的程序员可能只需要两个小时，而对于初学者来说，就得先花两天来理解Web Service的实现机制和原理。在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。这时应该怎么办？

   阿超： 对于这些队员，可以考虑在他们自己的任务估计值之上再乘以4。另外，如果你是写一个商业项目，请不要让连开发语言都没有接触过的队员进行开发工作。并不是非得 “写” 程序才是对项目有贡献，有时不写也有很好的贡献。如果他们有热情，就从测试开始学习吧。

   那么就这种情况来说，如若在公司中，团队总是面对着商业项目，倘若不给机会，新加入的队员如何能快速地在实践中学习技术呢？如若放在我们这门课上， 可能队友之间的能力也存在着一定差异，如若让本就精通的同学去开发，那小白岂不是在一定程度上失去了上这门课的意义，但倘若将开发任务交给不熟悉的同学，似乎也并不合理，也会拉跨团队的进度，这样又该如何解决呢？

5. 在16.4魔方的创新故事中，最后说道

   二柱这玩意技术含量太低了, 这小子压根还不会玩六面呢!”很多同学热衷于技术和技术的创新, 但是当大家在埋头搞技术的时候, 是否注意到自己是用屁股对着目标用户?

   在这个故事里，二柱创新了“公主魔方”，赢得了女孩子们的欢心，但是自己却根本不会转魔方；而大牛可以盲拧魔方，却不会讨女孩子的欢心。这似乎是一种创新型人才与技术型人才的矛盾，这里看似推崇的是二者兼得的人才，但这是不是又显得要求过于严格呢？一个团队中的人本就应该各扬所长， 充当不同的角色，这不才是团队合作的意义吗？

6. 在17.3绩效管理中提到

   如果成员的行为只影响自己, 或者是探索式的行动，则不是坏事。 例如有些成员自行探索最新的技术, 但是最后决定不采用此技术。

   看到这里有些疑惑，作为我们这个层次的学生，在开发过程中应该会有很多“探索式的行动”，这代表了一种思维的活跃与创新，如果可以产生好的效果，为什么不能采用这种新的技术呢？难道评判标准不应定为是否对项目产生了不好的作用吗?

   在网上查到了一种说法

   引入新技术通常会导致软件成为遗留系统，因为不同的方法会导致系统演变成东拼西凑的混合体，这会增加不必要的复杂性。此外，随着不断加入新的技术，旧技术就会过时。过时的代码量逐渐增加，而软件最终会变成遗留系统。

   但是这也有很明显的一个问题，如果一直不求创新，那又如何追求进步呢？新技术意味着新发展，在某种意义上不应能为企业带来更大的经济利益吗？何况软件本来就是版本一直在更新迭代，除了功能上的扩展完善，为什么不能加上计技术的创新呢，况且软件的更新应该也不是十万火急的事情。

二、调研源代码版本管理软件

由于只用过GitHub和GitLab，所以只对这两种的异同之处进行了调研。

1. 相同点

• 基于web的Git仓库
• 提供了分享开源项目的平台，为开发团队提供了存储、分享、发布和合作开发项目的中心化云存储的场所

2. 不同点

• GitHub是一个基于Git实现的在线代码仓库，而GitLab是一个基于Git实现的在线代码仓库软件，可以用GitLab自己搭建一个类似于GitHub一样的仓库，但是GitLab有完善的管理界面和权限控制，一般用于在企业、学校等内部网络搭建Git私服。

• GitHub同时提供公共仓库和私有仓库，但如果要使用私有仓库，是需要付费的。而GitLab可以在上面创建私人的免费仓库

• GitLab让开发团队对他们的代码仓库拥有更多的控制，相比于GitHub，它有不少的特色，可以让开发团队拥有更多的安全性和灵活性的选择：

  • 允许免费设置仓库权限
  • 非常便捷的用户界面，在同一界面上获取到：projects，最近的projects，用户，最近的用户，群组和状态
  • 允许用户选择分享一个project的部分代码
  • 可以设置获取到团队整体的改进进度
  • 受保护的分支允许用户设置project的获取权限，一个团队中只有特定的人可以push，force push或者删除一个分支的代码
  • 通过innersourcing让不在权限范围内的人访问不到该资源
  • 可以设置获取到团队的整体的改进进度，而不是个人进度
  • 开发者通过打上“仍在进行中”状态标签让其他成员知道代码没有完成，从而阻止未完成的代码合并到其他的代码中

• 从代码私有性方面来看，GitLab有更强的隐私性。但对于开源项目而言，GitHub依然是代码托管的首选

三、调研持续集成/部署工具

1. Gitlab-CI

之前部署过rails项目，这次使用的是oo课程pre2 task0的代码（代码库地址)

配置成功后的结果如下

• 运行build部分

  

• 运行test部分的详细信息界面

  

• 运行成功

  

Gitlab-CI是Gitlab官方提供的持续集成服务，通过在仓库的根目录下新建.gitlab-ci.yml文件，自己定义持续集成流程模板，并且在Gitlab中配置runner，在之后的每次提交或合并中将会触发构建，并且可以通过Gitlab的hook, 在代码提交的各个环节自动地完成一系列的构建工作，总之对于一些非复杂性的集成需求，都是可以满足的。

在GitLab-CI中，一次 Pipeline 相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。任何提交或者 Merge Request 的合并都可以触发Pipeline。

2. GitHub Action

将相同的代码上传到GitHub仓库，先使用github的第三方工具自动生成一个maven项目配置的模板，然后进行一定的修改，同样先进行编译后进行测试

• 编译结果

  

• 测试结果

  

可以在 GitHub Actions 的仓库中自动化、自定义和执行软件开发工作流程，可以发现、创建和共享action以执行任何作业（包括 CI/CD），并将action合并到完全自定义的工作流程中。

与Gitlab-ci不同，GitHub Actions 是事件驱动的，可以在指定事件发生后运行一系列命令，而且有各种类型的工作模板，同时也可以使用其他仓库的action，这一点上是它的一大优势。

3. Gitlab CI与GitHub Action的异同 (参考)

Gitlab CI的优势：

• 亲子管道同时运行，配置可以划分为较小的子管道，可以缩短构建和测试代码的时间，降低复杂性
• 先进的合并训练处理逻辑使主要开发分支保持绿色 ，消除代码更新错误和冲突
• 自动开发提供开箱即用的管道配置，减少初始配置时间和学习曲线

	GitLab CI	GitHub Action
配置	AutoDev Ops 更容易上手，随着项目发展可进行微调，自动检测语言并建立整个pipeline，提供并支持模板	提供了一个市场，可以轻松地选择由第三方工具/插件构建的模板，但它们需要进行编辑。 不支持的插件，维护和支持成本很高
数据包注册表	集成Docker映像和软件包发布，内置在CI / CD管道中，无需第三方工具/插件	Docker映像和程序包发布所需的插件，不支持第三方工具/插件，维护和支持成本很高
安全性	内置于CI-CD管道中的安全扫描，合并请求运行时将安全扫描内置到管道中，支持插件，但不需要；启用安全团队协作，为安全团队提供一个安全控制板，以概述一个项目或一组项目中的所有漏洞	安全扫描需要第三方插件， 可以将CodeQL扫描集成到Github的CI中，作为LGTM的门；安全团队控制板，没有集成的团队协作功能

4. 使用感受

通过体验这两个持续集成工具，我最大的使用感受就是：

• gitlab-ci配置理解起来容易，而github action有多层字段要求，使用起来不太好上手
• github action有非常好用的模板，大大简化了编写，很好弥补了它配置困难这一缺点，而且它的UI界面更加清楚（把每个字段的执行结果都分步显示出来）
• 针对这两个相同的项目相同的编译、测试功能来说，似乎github action执行得更快一点