对初创阶段公司来讲，最重要的是让产品或服务快速“下水”，以最快的速度在市场和用户中验证。无奈口袋紧紧是常态，再加上身处人才洼地，这让我们不得不先打造一个以junior developer为主要战斗力量的技术团队。
而为了能让产品快速“下水”，我们需要打造良好的持续交付能力。简单来说，持续交付能力是一种在保证代码品质的前提下，快速上线的能力。这里有两个关键词：品质、快速。品质的保障主要取决于测试，而能否快速取决于测试、集成以及部署上线的自动化水平。也就是说，如果测试（单元、集成、系统测试）越充分，各环节自动化水平越高，自动化运行速度越快，持续交付能力就越有保障。所以打造团队的持续交付能力，除了整个团队，在意识形态上要拥抱持续交付之外，还需要打造一个高度自动化的work flow: 一个让工程师把代码“写”上线的流程。
在打造这个work flow的过程中，我们需要完成对flow中各个环节（比如代码仓库，代码评审，问题跟踪，持续集成，持续部署等）的打造，并将他们有机的串联起来。这里不仅涉及流程的设计，还涉及很多软件技术的实现。那么问题来了：
我们是该选择撸起袖子自己“造车”呢？还是买一辆现成的？
尽管每个男孩大概或多或少都有一个自己造车的情结，但作为技术管理者的我们，不应该让这样的情结左右决策。对于我而言，如果在命中以下一个或以上的情况下，我会大概率放弃自己造车：
- 预研（学习 + 搭建test bed + 运行范例 + 性能评测）总估算时间超过2个月
- 预研过程中，团队成员普遍觉得难以掌握
- 预研过程中，团队发现运维成本较高（配置麻烦，debug较困难）
以上这些情况的判定主要依赖团队的能力。如果脱离团队的能力和意愿去做决策是不明智也不现实的。侥幸让test bed顺利运行不意味着日后在正式使用过程中你就游刃有余、得心应手。大多数我所经历得或看到的硬着头皮自己上的结果，到后来往往都是心力交瘁。
在大概率选择放弃自己造车的情况下，我会转而去了解那些现成产品。如果一个产品满足以下几个特征，我会大概率考虑采购：
- 定价合理（比如按使用量收费）
- 符合技术发展趋势（比如拥抱DevOps)
- 良好的交互体验
- 良好的客服响应
- 良好的业界口碑
- 知名企业背书
大概率考虑采购并不意味之一定会采购，如果在命中以下一个或以上的情况下，采购的概率会大大降低：
- 产品还在beta阶段
- 采用的核心技术尚不成熟
- 产品功能过于复杂或工作流配置过于繁琐
作为小团队的负责人，我乐于拥抱新技术，但并不意味着我想做第一个吃螃蟹的人。毕竟安全可靠是产品研发的第一常识。产品是否采用较为成熟的技术也是一个考量因素。随着团队的成长，我们会对work flow中的应用技术进行升级。如果采用了较为成熟通用的技术，团队成员的技术经验迁移也会相对容易些。
我始终认为创业公司应该近乎疯狂地专注在产品和服务的提升上。所以有现成的产品能解放工程师们的生产力，让他们回归到真正的创造性工作上来，那何乐而不用呢？