终于谈到了跟这个标题比较吻合的内容了！最后一个月上线前该做些什么事？
在本系列（一）中，我提到了无论如何最后一个月是测试期。这一个月又分
close alpha的对象事开发组以及运营组人员，也是与核心较为相关的组别。此时针对的测试目标是这个project业务上应该被实作的functionalty。比如说食谱网站，就应该可以
如果是讨论区，要应该可以
另外测试组时需要拟定使用未登陆会员、登入会员、营运权限、admin权限各测一次。
因为开发组成员在撰写功能时，为了方便，几乎都是以admin账号在开发，如果不制定测试步骤和角色，很容易没测到死角。
此时的修复重点放在feature complete（或取舍）以及functionaly是否正常运作。
请注意：不要在此时进行任何UI动线调整。
close beta的对象是全公司所有人，公司员工的亲朋好友，可以信赖的死忠会员等等...etc。此时针对的测试目标时这个project的UI动线。
如果是讨论区：
此时已经是视同上线了（所以close alpha阶段的资料会清掉），虽有运营组的人必须视同运营状态一样运营网站，以避免正式开站遇到状况时一片手忙脚乱。
PS：这一招是在参访一电视时学到的。当时一电视快开台时受邀去内部参访，当听到他们内部测试run报新闻run了一年时，震撼非常...xd
我在开发阶段时，最长向RD宣导的事情是：我不想管你这个功能是怎么写出来的，但是我要你准时交出来。（但最少要符合内部写程式规范，有办法读懂）
原因是：网站最重要的是Deliver上线。而不是站上的feature用了用了多屌的技术，用了多棒的best practices，没有用户会在意这件事情。而贪玩迟交会砸了一切。
直到Open Beta期，Optimized这件事都不会被提到。因为在网站稍微stable之前，所以的optimized都毫无意义，做了也白做。因为会发生效能瓶颈的地方，永远在你想不到的地方。
如何做Performance Tuning？
幸运的是，我的专案都是rails project，有New Relic这套软体可以用。它可以帮你找出你的网站哪一段Ruby Code特别美效率，哪一段code制造出来的SQL query特别slow
其他技巧请看：Repid development with Rails p.54-p.59
这是其他题目了。有空我会再整理update一篇Rails Performance Tuning的文章。
既然已经进入Open Beta期了，这时候手上应该可以拿到这个网站最常造成访问和效率最差的页面。
可以使用ab去对网站进行压力测试。
再决定是要refactor slow code或者是先上cache档着先。
影响网站使用者感受最大的其实不是backend的效率，而是Browder side的效率。上线前我会
其他技巧看：
以上说的都只是Performance。但是这跟实际运营没有那么大的正相关。我擅长的是内容站点和社群站点，这一类的网站重点其实是SEO以及社群穿透力。
比如说：这是T客邦累积出来的两套Gem。
网站的每一个页面都会确保分享至社群网站是正常的。
靠广告赚钱，所以要调整广告位
跟user的互动...etc。
这些都确认没什么问题了，然后才是开站。然而开站不是这一切的结束，还有其他事情需要作...