|
部署 软件设计师一旦提交他们的代码到版本控制库中，那么他们所有的测试都将顺利通过。 如果他们要求改变后端服务的代码(如数据库模式更改)，这可以通过迁移做到。一个迁移能改变它如何制作和回滚。当部署一个新的软件版本时，运行任一未 运行的迁移模式。同步的代码版本依赖于其后备服务。在回滚之上，迁移同时又被回滚。这意味着后备服务与代码总是同步的。 几乎所有的新代码都是致力于开发的主线的(又名主干或HEAD)。这就避免了不同的开发分支合并后的痛苦。因为任何大的变化都应作为一个实验来实现， 如果一个变化没有完成或者没有准备好，就很容易被大多数实验外的用户关闭。如果代码准备好了，则更多的人可以加入到实验组而这种拴牢最终将被删除。 一旦提交到版本库，版本库就会自动建立、释放、并在一个新的测试环境中运行这些代码并 自动测试它们 。 然后，就应该尝试运行代码，并迁移对生产支持服务的完整副本(read：数据库)，尝试通过运用和回滚的迁移这两种方式确保测试通过 如果它们全部都通过了，它就应该发布出来。为了确保一些莫名其妙地通过了测试的断码不发布出来，你应该有一个免疫系统去监控部署。系统会查看你的主要 创新指标(寻找新的收益，新的用户等等)，以确保他们没有受到不利影响的部署。如果是这样，它会自动回滚，并提醒团队。 为了确保还没有被产品所有者审查的代码不发布出来 ，你应该给它们着手 控制实验 。 新功能应该在最初时没有任何人的实验中投入生产 。 产品所有者可以添加自己的实验， 或把实验放在预览服务器让 每个人来测试它 。 QAs也可以测试。当所有人都快乐了，就会有越来越多的人加入到实验中 。 如果指标看起来很棒 ，甚至可以增加更多 ，直到最终100 %的用户都参与到实验里来和有控制可以从代码库中删除的力量 。 发布 有些人会鼓励你举行一个大的如同好莱坞式的发布会，在软件推出的几个月前就开始大肆宣传发布日期。 这种方式也许在好莱坞很好用——如果你的电影在首映周票房高唱，影院心甘情愿的多放映几周，且你的电影被誉为“本周最佳影片”。但对于软件开发者，这是极 其荒谬的。你的软件并非在影院发布，它发布在互联网上。你的软件不比担心被影院展示一周就下架。你可以年年推送，培养用户群。 一场盛大发布会的问题在于，除非你是完美的，发布当天总会出现一些你忽视掉的 BUGs 和概念错误。现在，数以百万计的人正在访问你的产品，体验这些错误。(也许你的错误时没有适时的加载和测试服务器，导致网站宕机。) 相反的，你应该视你的发布会为另一场实验，并在表现良好的时候缓慢增加允许访问的用户数量。学习Gmail的例子：邀请极少的人，针对他们的使用和反 馈测试你的设定，当他们开始喜欢上的时候，允许他们邀请另一些人加入。慢慢增加人数，直到所有期待邀请的人都已被邀请，整个世界都将是你的试验场。 祝你好运! 致谢 此文最初是由 Aaron Swartz编写的，是他和其他人很多不同的想法的组合 。 需求和想法的讨论可能受到Paul Graham 的影响 。招聘是改编自Aaron的 我如何雇佣程序员 ，这涉及到Joel Spolsky的作品 (他的书被称为聪明地把事情办好)。假定是改编自精益创业 和丰田生产系统。团队和开发是基于极限编程 的想法 。 架构明显是基于12-要素的应用 。The Chaos Monkey是来自于Netflix 。 从Rails迁移是一个长期的过程。部署通过蒂莫西· 菲茨来IMVU的连续性免疫系统。发布的部分是改编自如何启动软件。 |
