持续交付第一章

概括本章

第一章作者交待了本书是旨在讲述一套流程化的部署模式——构建、部署、测试、到发布整个过程自动化实现。然后列举了一些反模式:

1. 每次通过手动部署软件，消耗大量时间和人力以及资金
2. 开发时将测试、部署人员抛在一旁，开发完成才开始部署项目
3. 对生产环境的配置管理也是手动来管

这样的反模式引发我们思考，如果这一切都是自动化呢？为了让软件开发周期短并且开发出来的软件带给客户价值，我们需要频繁地自动化发布软件。

我们要抓住软件交付的原则：

1.软件发布可以重复并且可靠
2.将几乎所有事情自动化
3.将构建、部署、测试、发布所需的东西进行版本控制
4.痛苦难做的事要提前并频繁地做
5.一旦发现了缺陷，尽早解决
6.满足客户的需求，这张功能卡就算DONE
7.交付是每个成员的责任
8.通过反思总结持续改进

提问题

记得上次给胡老师showcase时，老师推荐我去看持续交付，在读这本书之前，我给自己设了几个问题：
1.持续交付的目的是不是为了能够及时给客户交付软件并让客户满意呢？
2.我们在项目中采取什么流程来做到持续交付？
3.联系我们组内的项目，我们有哪些地方可以改进？比如能不能确保每次提交代码后，项目都是一个可发布状态。哪些地方做的好？比如两周组织一次retro

感悟

• 文中提到一个反模式，就是说开发完成之后才去部署代码，我才意识到每次做项目我们都把测试部分和部署部分放到最后，导致项目做的周期更久，并且也得花一定时间解决bug.那么，我们可以在一开始让测试和部署同步我们的开发，确保大家成为交付中的一份子
• 用版本控制工具比如github来管理我们项目中需要测试代码，开发代码等
• 小步提交方便我们回退到上一个版本，以后提交时要记得小步提交
• 每次我们提交后，拿什么来验证变更？
  可以检查源代码的规范；
  测试能不能跑过，以及查看测试的覆盖率；
  看功能验收是否符合；
  非功能测试是否成功，比如用户安全性方面的需求；
  多探索有没有潜在的缺陷；