<h2>软件交付的问题</h2>
一学期最用心最紧张的时间是考试周，最近课程设计最担心的是星期四因为那天要检查代码了，同理，我们可以轻易理解，程序员最紧张的就是软件发布的当天。
抽丝剥茧，我们来一步一步走进发布的过程然后对症下药让发布尽可能的变成轻松的事。
<h4>一些常见的发布反模式</h4>
<h6>手工部署软件</h6>
顾名思义，这种部署应用程序步骤是由个人或小组去执行，每一步都是凭借经验凭借记忆力去实现。
那么，如果部署的那位员工离职了怎么办？部署中文档记录不全面或者文档没有及时去更新怎么办？
这本身就是一个高度紧张有压力的方式，而且其中还有很多不确定的因素容易导致出错。
<h6>开发完成之后才会向类生产环境部署</h6>
第一次看到这个名字，我就想到了不愿意期中考试的我们，明明知道期中考试对我们来说是有优势的，它可以减少期末考试的压力，它需要复习的知识不是很多，但是，我们就是不愿意去面对考试，所以也去抗拒期中考试。
这种孤注一掷的模式容易出现很多难以预料的bug，而前期的开发人员与部署人员沟通若不及时，那就很难下手去解决这些事。
<h6>生产环境的手工配置管理</h6>
这个呢就是部署人员宠着开发人员，好啦好啦，你需要什么环境我给你创造什么环境，依赖的版本补丁的级别，你别担心别担心，我为你改，我为你改。
什么！滚回到上一个版本？再见，好走不送！
哈哈，上面的场景虽然是我想象的，但是这个模式确实很难回到上一个环境，而且这样改生产环境只能解燃眉之急并不是长远之计，万一只在测试环境通过，到了实际生产环境gg了怎么办。
<h6>我是一道光</h6>
上面提到了很多模式但也被我们否定，现在我们提出推荐的部署模式——自动化部署。
<h4>如何实现目标</h4>
我们的目标：<strong>尽快</strong>向客户交付<strong>可工作</strong>的软件。
那如何实现我们提出的自动化部署，重点！画重点：
<strong>1.自动化：</strong>把所有工作流程化，让出错几率变小，也可以解放人力，缓解压力。
<strong>1.频繁做：</strong>不停的去发布，随时可以会滚，可以缩小出错范围。
<h4>收效</h4>
这样部署的收效如何？
首先整个流程是可重复的、可靠的、可预见的，所以每一次出错的范围都是可循的。
其次，整个过程中，开发人员、测试人员、运维人员等都是参与的，沟通也是及时的，工作效率当然也是高效的。
最后，部署是随时的，出错是有范围的，那当然就是缓解了压力，让发布不再那么可怕。
<h4>候选发布版本</h4>
候选发布版本：每一次的修改后的版本都有发布的可能性。
在这个模式中，每一次提交代码都可能产生一个可发布的版本。如果发布版本是一件烦恼的事情，那就反复去做这件事。
<h4>软件交付的原则</h4>
1.为软件的发布创建一个可重复且可靠的过程。
2.将几乎所有事情自动化。
3.把所有的东西都纳入版本控制。
4.提前并频繁地做让你感到痛苦的事。
5.内建质量。
6.“DONE”意味这“已发布”。
7.交付过程是每个成员的责任。
8.持续改进。
前四条我们前面一直在重点强调，后面两条也是容易理解，这里单独解释一下中间两条。
内建质量——尽早的解决所有发现的bug，不要等到最后一刻迫不得已才去修改。
“DONE”意味这“已发布”——代码写完不代表可以松懈，只有到项目彻底发布，客户满意了，才意味这完成。
<h4>思考</h4>
第一章读了好几天才读完，总是读不下去感觉内容太生硬，但是就在刚才写完书评时才觉得其实也没有那么难，环环相扣，都是可以去理解的。万事开头难，不只是走一步，坚持多走几步就好了。
<h4>疑问</h4>
强调的是频繁发布，那每一步走多大才算合适？
