对新创项目而言，是idea更重要，还是执行力更重要？在没有用户时，我们该如何冷启动？团队、人、技术、产品、推广和拜春哥，哪一个更重要？到底是什么决定了一个项目的生存或者毁灭？

    来吧，一起书写51daifan的成长史吧。51daifan是一个同事之间分享午餐、特产的公益平台。每天带饭的同学，可以多带几份爱心便当，分享给身边的同事。大家中午一起热饭，一起桌上足球，一起品尝同事带来的爱心便当。让午餐变成每天最快乐的时光。

    51daifan从5月底开始有想法，一周后6月初web版本上线，四周后7月中旬android版本上线，现在，8月初，ios版本即将上线。2个月时间，有过快乐，有过迷茫，也有过痛苦。它到底会不会成功，谁也不知道，这也许就是生活最富有魅力的部分吧。关注我们的微信公共号，一起来品味产品成长中的酸甜苦辣吧：

    一起来品味产品成长中的酸甜苦辣吧，每周一，我们将把51daifan上周所有滋味倾诉在这里：产品的运营数据、开发进度、对产品方向的思考、产品运营遇到的问题和想法。加入我们，一起来决定产品的进程吧，把你的想法告诉我们，我们一起来尝试，不管结果如何，当我们的额头爬满皱纹，我们能做到的就是，不让它们也爬在心里。

一、产品源起

产品想法缘起每天的午饭：

但是，我们周围还有这样一群人：

于是，我们想：

产品运营&数据

    目前产品上线8周，注册用户160人，app下载用户22人，日活跃用户在25人。有过订饭/带饭行为的用户为62人，订饭数据371人次。

产品运营分为3个阶段：

1. 6月份中上旬在部门里试用，用户数到达30人，日活跃用户在20人，2人带饭，日均订饭数12；
2. 6月下旬在公司BBS进行了第一次推广，一周内注册用户数达到90人，但带饭人数依旧是2人，拓展新的带饭同事困难（之前假设妹子有时间带饭的路证明是不通的），日均订饭数16；
3. 7月开始转换思路，同时鼓励同事可以分享自己家产的特产，进行了两次自家蜂蜜和蜂王浆的团购，产品推广集中在bbs发帖，人数缓慢增长到160，一位带饭的同事退出（确实是太累了，纯爱心活），为了增加网站粘度，增加了711免费带饭服务，但效果并不明显。因为没有找到新的带饭同事，目前日均订饭数下降至10。

    对当前产品运营来说，最重要的工作就是如何找到更多愿意分享的同事。目前有两种思路：一是降低分享的门槛，例如我们可以分享自己15分钟家常菜的菜谱，通过降低门槛拉动社区的活跃度；二是推广我们的网站，认为没有更多分享同事是因为我们用户数还很少。

    9月份有个大的分享活动是nanana同学家在五常，10月她家新稻米收割，我们会组织一次团购，五常稻花香大米在超市的价格在10元左右是陈米并且一定掺有其他米（这已经是所有大米收购时就有的潜规则），我们初步考虑的价格在7元左右，成本在于物流，真是个大问题，目前考虑是长途车送至四惠客运站，然后再包车拉到公司（可行性还在讨论）。

 

对产品方向的不懈思考

    我始终认为产品大的方向绝对正确，就是基于社交关系的O2O（这里是同事关系）。在这个全国造假、连政府信用都已经破产的当下，冷漠、造假似乎是我们这个时代的代名词。我们一定能做点什么，通过基于社交/同事关系的O2O，我们认为一定能重建人们之间的关心和温暖。一方面我们能获得绿色、环保、健康的食品，另一方面，能够拉近同事间的关系。

 

当前开发进度

    目前web、android、ios开发全部在同步进行，全部是业余时间开发，代码开源在：https://github.com/ronghao100。Android第一个版本已经发布，第二个版本将包含上传图片和消息通知，计划下周发布，ios本周提交审核，计划一周后发布。

 

对这个项目发展你有什么想法，来吧，一起决定它的未来！扫描二维码立刻关注我们的微信公共账号：

 

一、我们要解决的问题

无论是什么样的解决方案，一定要牢记我们要解决的问题是什么，切不能将解决方案当做问题本身。具体到过程改进，不管是何种方式的改进，它们所要解决的问题永远只有一个：缩短从产品想法到可用软件之间的时间周期。自动化发布正是如此，如果软件发布只做一次，我们说根本不需要自动化，但如果三次以上，那么软件开发的黄金法则DRY就必须遵守，让时间真正用到开发当中去。

 

二、与发布相关的问题

所谓自动化只不过是将原先手工做的工作谦让给机器做，所以自动化之前一定要先清楚与发布相关的问题有哪些，即使不自动化，这些工作也一个也不能少：

1. 应用程序如何打包？ 发布包能否追踪到SVN版本号？
2. 对目标机器环境有什么样的要求？
3. 配置信息是否需要根据目标机器信息做出调整？
4. 应用程序如何安装和启动？
5. 应用程序启动后如何切流量？
6. 应用程序如何升级？ 旧版本程序数据如何迁移？
7. 升级过程中和结束后如何切流量？
8. 应用程序如何卸载？

 

三、我们的方案

李安的少年Pi正在狂刷票房，我们的自动化发布方案也要跟上潮流：Puppet+CI我们的少年Pi。

Ø 使用CI自动化打包，追踪每个发布包的SVN版本；

Ø 使用Puppet管理发布包、目标机器环境、应用程序配置信息以及应用程序线上生命周期；

Ø 使用伽利略系统提供应用程序的命名服务和进行流量切换。

现在应用程序的发布需要两步：CI一键打包、puppet指定应用程序版本SVN提交。

 

四、具体方案

具体方案也就是如何解决与发布相关八个问题的过程。

1.         如何安装、升级和卸载应用程序

我们使用操作系统原生包管理系统来安装、升级和卸载应用程序，我们的应用程序打出RPM二进制包。免安装，所有机器自带，绿色的，有机的。

打包：rpm -ba ./team_member-1.spec

安装：rpm –ivh team_ member-2.0.1-48.x86_64.rpm

升级：rpm –U team_ member-2.0.1-49.x86_64.rpm

卸载：rpm –e team_ member-2.0.1-48.x86_64.rpm

程序升级前要停旧版本服务怎么办？旧版本数据要做处理怎么办？RPM已经帮我们料理好这一切，只要写出spec文件，剩下的交给我们。尽情的插入吧：

 

2.         如何管理目标机器环境和应用配置信息

应用程序已经打好rpm包了，但这还不够，应用程序发布到哪台机器上？应用程序对目标机器有什么要求？发布时需要修改哪些配置和参数？实际发布如何执行，难道需要登陆到每台目标机器运行rpm命令吗？

我们使用Puppet来搞定这一切，Puppet是现在应用第一的devops工具，它通过master/agent的工作模式管理机器。我们通过声明来控制我们的机器达到目标状态。同时，所有puppet文件全部在SVN里，所有对机器的修改全部codereview和可审计。

 

如何管理应用程序发布到哪台机器上？在回答这个问题前我们必须将应用程序在线上的生命周期再进行一次封装。

应用程序TeamMember被我们封装成一个puppet module，配置文件和参数被封装在对应templates和files里，每次发布前都要修改配置文件和传递不同的参数？out了吧，puppet帮你传参搞定:

Teammember.conf文件内容：

封装完成后的效果是这样的：

最后在管理部署的site.pp文件里声明一下，应用程序TeamMember的2146版本就被自动部署到10.128.34.141.test.back.shequ这台机器上了，我们后续的工作也就是维护这个site.pp文件了，所有应用程序的部署信息都在SVN被集中管理起来：

登陆到每台目标机器运行rpm命令？No!现在TeamMember已经被封装，我们修改完毕site.pp并提交后，puppet就自动执行命令了，要不怎么说是自动化呢。（现在puppet默认在agent每半小时同步一次，但同时支持马上触发执行）。

 

3.         如何追踪每次发布的SVN版本号

我们使用CI进行应用程序的打包，将build号作为包命名的一部分：

 

4.         如何在发布过程中切换流量

这是另外一个很大的话题，参见伽利略计划。

 

五、下一步工作

使用CI将环境的自动化部署与自动化测试串联起来，搭建起整个研发流程自动化平台：

 

六、小结

没有银弹，自动化所做的只是将之前手工工作交给计算机完成，需要做的工作一个都不能少，此外，我们还要多做一些封装或脚本工作，但是，当我们需要重复做这些事情的时候，价值就出现了。我们的目标永远是缩短从产品想法到可用软件之间的时间周期。让时间真正用到开发当中去。