大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
如何处理单个项目的多个代码版本
作者 Mark Levison 译者 郑柯 发布于 2008年6月4日
一旦产品发布了第一个版本，你的团队将面临下面的困境——如何在继续发布新版本的同时维护第一个版本。对于这个问题，Target Process 公司的CEO兼创始人Michael Dubakov，在“是否应该在项目中采用并行方式进行发布和迭代？”这篇文章中分享了他们的经验。
在Michael的例子中，他打算对1.0版本进行修复，继续1.5版本的工作，并为2.0版本开发新功能。同一个项目的工作应该由同一个团队来完成吗？在这样的团队中，是否该让某些开发人员发布2.0版本，其他人从事1.5版本的工作，并让Joe（具有牺牲精神的开发人员）挤出时间来修复1.0版本的重要问题？Michael得出的结论是：让浪费最小化，而且不在2.0上进行开发。针对进行1.5版本开发的程序员，我们减少了他们需要同时处理的任务，并尽量拖延作决定的时间（到2.0版本开始的时候，一些现在看来2.0所必备的功能可能已经不再需要了）。
根据Steve Campbell的经验，这个问题最好的解决方式是：将所有的任务（包括所有的版本）放置在单独的Sprint Backlog中。这样一来，任何一个团队成员都可以选取一个任务（不管是哪一个版本），然后开始工作。Steve继续讨论了这种情况下的分支策略：要么不要任何分支（采用运行时切换机制来区分不同的版本），要么只在重新开发组件的时候再做分支。
来自Eclipse 软件系统公司的Matt Swaffer采用的方法与之迥异。他的团队不发布补丁程序，实际上他们要保持主干的稳定，如果修复了bug，他们会邀请用户下载最新的版本。另外，他们还会为每一个版本打上标记，一旦发生严重的bug可以回溯到原来的版本进行修复。他们的终极目标是每周发布新版本。
说到基于同一个代码库发布多个产品的问题，《Implementation Patterns》的作者Kent Beck谈到一个例子：他参与了两个项目，团队需要支持七个客户。除了核心逻辑之外，每个项目都有大量的自定义代码。其中一个项目为每个客户保留了独立的代码库，每当有新客户时，他们会克隆一个“最新鲜”的分支，并继续进行开发。正如Kent所指出的，这样一来，他们被合并所带来的工作量淹没了。而另外一个项目中，交付给每个用户的是单独的二进制文件，这种方式保证每个客户执行的都是自己需要的代码。Kent认为这两个项目关键的不同之处在于：
关键在于找到方法推迟关联。我发现从一开始就要定好原则——我们将使用独立的代码库。这种方式减少了一些设计上的选择，但是仍然留有很大余地。还有另一个重要的原则，在第一个案例中我们不介意有一些重复的代码，如果能够明确如何消除重复代码，我们愿意这么做，但现在还没有，我们仍然希望能找到清晰的解决方案。
最后来自N-BRAIN的John A. De Goes这样说：
分支是浪费的一种形式，我们的目标是消除分支。我们采用单独的代码库，只支持最近发布的一个版本，每次发布都强行推送给所有用户，并频繁发布（理想情况是，一次发布增加一个功能，或移除一个缺陷）。采用SaaS的方式实现起来会更简单。
查看英文原文： Handling Multiple Versions in a Single Project Team?
译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。
这是每家企业都要遇到的问题
发表人
xiao jun
发表于
Re: 这是每家企业都要遇到的问题
发表人
blogbin avatar
发表于
分支还是需要的
发表人
Guo Ford
发表于
Re: 分支还是需要的
发表人
Guo Ford
发表于
如果分支无法避免
发表人
Saint Arion
发表于
-
这是每家企业都要遇到的问题，可惜这里也并没有提到好的解决方案。毕竟每家企业都是不一样的
-
只要测试->修复-〉发布的能力足够快，理论上抛弃分支。
-
如果你的产品只有一个用户的话，可以没有分支，但是如果有不同的用户的话，也许分支还是解决不同用户的需求的一个必要保障吧，毕竟你不能强迫每个用户强制升级你的系统。
-
不过，分支是应该要尽快很快的合并到主干，否则就象kent所说的，会被合并所淹没的。
-
我想如果就Michael的例子的解决办法是：
1把1.5作为trunk
2那为2.0的新功能做一个或多个实验分支
3为1.0开一个bug fix分支
这样大部分的人在1.5的trunk上工作，同时可以在1.0的分支上fix bug,并且及时的合并修复到trunk,同时一部分人可以为2.0的新功能工作。
Eclipse的办法并不适用于所有的情况；
Kent Beck的例子比较极端，可以把trunk作为vender分支来尽量减少合并所带来的工作量。
当然最好的办法仍然是减少分支:)
5 条回复
关注此讨论 回复