五项提示帮您迈上持续交付的阳关大道

Codeship公司CTO Florian Motlik客座文章

对于任何一家初创企业而言，行动灵活、迭代迅速并且以早期用户及客户反馈为导向进行产品调整可以说是其一路成功发展的必要前提与核心手段。AWS社区英雄兼Netflix成功迁移至AWS云基础设施的幕后功臣之一Adrian Cockcroft就一直在强调“速度赢得市场”这一理念。时至今日，初创企业面临着来自方方面面的竞争压力，而这种压力也迫使他们对自身产品作出变更与改进。

面对来自方方面面的竞争压力，初创企业需要对自身产品作出变更与改进。

要保持初创企业跟上不断变化的市场发展节奏并达到与之等同的速度提升效果，持续集成与持续交付无疑是必不可少的两大最佳实践。

持续集成与持续交付是什么？

持续集成是指在任何将代码提交至代码库时运行整体测试套件的过程。这种方式能够帮助大家确保自己的应用程序按照预期般正常起效，且其中的变更内容不会带来意料之外的状况。

持续交付则意味着确保我们的代码始终处于可部署状态，甚至能够在我们向主代码库作出变更的任意时间点被发布至分期及生产基础设施当中。这一机制当中还包括运行测试，也就是让持续集成成为持续交付流程的组成部分。这能帮助大家快速将新功能与新改进提供给客户，同时从后者处快速得到反馈意见。

拥有一套出色的软件开发与交付流程对于初创企业而言可谓意义重大，这一点我们在之前的工作流最佳实践电子书当中已经进行过阐释。

考虑到上述情况，在今天的文章中，我们将共同分享五项提示——我们的多家客户已经将其纳入实践当中，并在长期执行的过程中借此获得成功，包括实现快速响应并打造出卓越的产品成果。

1.测试的目的在于提高用户满意度而非验证软件本身

在我看来，人们对于测试工作的最大误区之一在于，大家往往认为测试的目的在于验证软件是否能够正常起效。事实上，保证用户满意度才是测试的核心诉求所在。

当构建一款产品时，客户通常会对我们提出两大预期：

i.  不断创新以支持新的需求类型。他们希望依赖产品供应商，要求后者能够打造出适应其未来一到两年当中各类实际需要的方案。

ii.  不要对原有系统造成破坏。

适当的测试手段能够帮助我们确保在应用程序开发的同时，不至于给用户带来持续不断的负面影响。此外，理想的测试机制还能为大家带来更为自由的发挥空间，因为只要能够顺利通过所有测试项目、即代表着我们不会对用户的业务流程造成损害。换言之，理想的测试机制为我们提供快速迭代所必需的速度与安全性保障。

在这方面，很重要的一点就是保证在测试结果全部通过的情况下，大家能够完全信任测试套件的考查机制并将成果立即加以部署。具体来讲，当测试结果一切正常时，我们需要充分信任这一结论，只有这样才能实现持续交付的核心原则——随时部署现有成果。在这种情况下，即使在周五晚上跟朋友们出去放纵一下也没关系，因为测试套件的可靠性给了我们充足的信心。以此为前提，我们才能实现更快捷的实验性尝试并将新功能推向市场。

对于初创企业而言，用户是推进产品开发与业务增长的主要动力所在。因此，我们必须尽可能避免不断破坏自己的现有应用方案，因为这往往会令客户感到失望甚至愤而离去。

2.让库驱动基础设施

在开发人员的日常工作当中，他们不应该将太多精力浪费在大规模生产基础设施身上。相反，他们的注意力应该始终集中在代码、或者说哪些代码存在于哪些分支等问题上。当不同分支间的代码进行合并后，成果应该马上得到部署。

举例来说，将来自某功能分支的代码合并至另一分期或者生产分支当中，这意味着我们希望将其部署到基础设施当中的各个对应层面。开发人员应该能够始终关注代码本身，并在代码内容无误时立即开始进行下一项任务——而不必担心如何将其纳入生产体系。

从我们的经验出发，库机制是实现这一理想工作流的绝佳方式之一——我们不断使用这种方式，而且并没有出现任何冲突。确保任何一点只存在有最后一次提交的代码内容。通过这种办法，开发人员能够始终关注代码与库本身，而这也正是他们应该投入全部时间与精力的部分。

3.建立一套恒定的基础设施

对于基础设施这样一套长时间运行的体系来说，我们很难对其进行复制，而这往往会引发一些潜在问题——例如bug需要数周时间才能彻底得到解决。有时候，基础设施甚至会在毫无记录的情况下发生变更。正是这一切消耗掉了开发人员的大量宝贵时间，而这些时间本应被用在处理他们的本职工作——也就是产品开发身上。

相比之下，恒定基础设施当中包括大量恒定组成部分。每次进行部署时，设施都会根据需求更换各组件，而非像过去那样对现有组件进行升级。这些组件皆源自一套通用型设计原型，此原型会在每一次部署操作时得以构建，并能够接受测试与验证。此外，如果大家希望在意外状况之下由更新版本回归至早期版本，这些原型甚至可以进行重新部署。此类通用原型可以通过自动化方式建立，不过如果各位愿意，以手动方式完成亦无不可。

恒定服务器就像乐高积木：不要费力修复，拆掉重装最方便。

这种恒定性不会因为建立访原型所使用的任何工具或者工作流而受到影响。其最佳用例应该运行在云或者虚拟化环境当中。尽管也可以被引入非虚拟化环境，但在这种条件下恒定机制的优势将受到严重影响，或者说收益将低于支出。

建立这样一套恒定基础设施要求大家的技术团队以自动化方式完成任意组件的设置与部署工作，因为各组件会不断被替换并因此产生庞大的工作量。当某台服务器由于某种原因而发生故障时，大家可以立即将其替换掉——正如玩乐高积木时那样。

通过直接替换任何运行状态与预期不符的服务器，大家可以轻松实现基础设施的自我修复，也就是在运行过程中的任意时间点对组件进行更替。

Docker及其它容器技术方案通常能够在这方面工作当中起到良好作用，不过大家也不要忽略掉Packer等非容器工具在构建AMI时所发挥的优势——我们已经在这方面进行了长期验证。将AWS CloudFormation与userdata及cloud-init配置相结合则构成了另一套工具，能够帮助各位利用保存在代码库中的代码实现系统的构建与配置工作。

4. 测量一切，记录一切

在实现各部分组件部署工作的自动化之后，大家还需要确保引入适合的记录与测量机制，从而了解整套基础设施在任意时间点中的运行状态。

这些数据将成为保障基础设施运维及稳定性的关键所在。我们需要在任意时间点上保持查看当前系统状态并添加额外测量指标的能力。另外，大家还需要引入相关报警方案，这样一来当基础设施组件发生故障时，团队成员能够轻松访问到全部相关数据而不必再将时间浪费在不断跳转当中。需要强调的是，单单对数据进行收集还远远不够。如果无法保证每位团队成员都能轻松加以访问，那么这些数据的存在将变得毫无意义。

目前可供选择的日志记录与测量指标服务很多。AWSCloudWatch就同时支持日志记录与测量指标这两项功能。

利用AWS CloudWatch深入了解基础设施的运行状态。

AWS ElasticBeanstalk支持面向Amazon S3存储服务的日志记录功能。除此之外，Papertrail以及Librato Metrics（也就是我们所使用的方案）等服务亦能起到同样的作用。最重要的是，大家应该选择一家服务供应商，并立即开始自己的指标与记录收集之旅。

在将测量指标与日志记录部署到基础设施当中之后，请确保代码库中的每一项变更都受到所嵌入方案的正确记录与测量。对代码进行运维可以说是了解基础设施运行状态的重要一环，我们应当在代码审查的过程当中对每一项代码变更进行认真权衡。

5.关闭指向设备的访问通道

随时开放指向生产基础设施会给团队带来非常负面的引导效果，也就是说成员们会不愿在早期的中央位置出发着手进行指标与日志记录收集工作。此外，大家还需要在基础设施的设计方案中考虑到对生产环境的调试需求。

为了对团队进行正确鼓励，我们能够采取的最佳举措之一就是直接关闭掉指向生产基础设施的访问通道。或者，至少确保团队成员需经过多次跳转才能加以访问。另外，为了彻底消除这种访问能力，大家可能还需要将SSH私人密钥从AWS服务器当中完全移除。

如此一来，团队中的每位成员就不得不对需要被保存在中央指标系统内的数据进行收集，从而顺利完成调试工作。再次强调，对基础设施直接进行访问相当于保留了一条捷径，其极具破坏性而且存在着巨大的安全隐患。消除这种访问通道可以切实缓和可能出现的安全问题。

总结

对于任何一家软件初创企业而言，向持续交付过渡并最终实现卓越的软件开发流程都是一项非常重要的根本性任务，因为其能够在加快开发速度的同时确保大家不会对产品乃至客户造成破坏性的影响。这种不影响应用程序本身而实现持续迭代并获取客户反馈的方式将帮助大家在市场竞争当中力压群雄、脱颖而出。

因此，请大家确保将充裕的时间及人力资源投入到持续交付工作的实现当中，如此一来各位将在企业运营的每分每秒享受到由此带来的可观回报。

原文链接：

https://medium.com/aws-activate-startup-blog/five-tips-to-get-started-with-continuous-delivery-c292cfd60970

核子可乐译