持续交付的笔记(107)

>我来写笔记

按有用程度 按页码先后 最新笔记

  • 红色有角F叔

    红色有角F叔 (次元の呪い)

    我们倾向于将自动化验收测试限于完全覆盖 happy path 的行为,并仅覆盖其他一些极其重要的部分。 一个好的自动化测试套件应该给你足够的信心执行重构,甚至对应用程序架构进行重构。 你需要监控到底花了多长时间做重复性的手工测试,以便决定什么时候把它自动化。一个很好的经验法则就是,一旦对同一个测试重复做过多次手工操作,并且你确信不会花太多时间来维护这个测试时,就把它自动化。

    2016-07-14 22:51   1人喜欢

  • 大头

    大头

    请将配置信息放在版本控制系统中。这个最简单的动作就是一个巨大的进步。

    2011-10-26 15:33

  • 大头

    大头

    当使用“按发布创建分支”的方式时,有一点非常重要,那就是不要在已有的发布分支上再创建更多的分支。所有的后续分支都应该是从主干上创建的,而不是已有分支上。从已有分支上创建分支是一种“梯型”结构,这样很难发现两个版本之间哪些代码是公共的。

    2011-10-24 20:32

  • 大头

    大头

    将测试、部署和发布活动也纳入到开发过程中,让它们成为开发流程正常的一部分。确保每个人都成为这个软件交付过程的一份子,无论是构建发布团队、还是开发测试人员,都应该从项目开始就一起共事。你应该具有重建生产环境的能力,最好是能通过自动化的方式重建生产环境。   (1回应)

    2011-10-22 22:29

  • 威廉他

    威廉他

    MTBF:平均无故障时间 MTTR:平均修复时间

    2017-09-07 23:42

  • 威廉他

    威廉他

    不要删除旧文件,而是移动到别的位置 不要直接对生产环境进行修改

    2017-09-07 23:41

  • 威廉他

    威廉他

    在单元测试中避免异步 使用mock技术

    2017-09-07 23:07

  • 威廉他

    威廉他

    超大项目必须指定一个构建负责人

    2017-09-07 23:06

  • 威廉他

    威廉他

    提前频繁地做让你痛苦的事情 将所有东西自动化 对所有内容进行版本控制

    2017-09-07 23:04

  • 威廉他

    威廉他

    构建失败之后,不要提交新的代码

    2017-09-07 23:03

<前页 1 2 3 4 5 6 7 8 9 ... 10 11 后页>

笔记是你写在书页留白边上的内容;是你阅读中的批注、摘抄及随感。

笔记必须是自己所写,不欢迎转载。摘抄原文的部分应该进行特殊标明。

持续交付

>持续交付