网站上线管理101-第二件:网站部署

收藏文章 点赞鼓励

第二件事:application deployable from day 1

在进入开发准备阶段,我会做的第一件事:make application deployable

也就是:专案开始第一天,就必须又个production直接运行(可以锁密码,当测试sever)才行。(我在rails101这本书最后一章,加入了capistano作为必练技能,就是这个缘故。)

为什么专案需要deploy?

提前控制风险:开发环境和线上环境的不同

在一般的经验中,往往当专案开发进入尾声网站快上线之时,才会注意到一个可能使专案时程大爆炸的事情,开发端和线上端的环境通通不一样

在开发环境中,所有人都只专注专案在自己的机器上能不能动,这是常态。专注在实现功能,东西又缺就现在local上塞假的资料。在最短时间内将feature尽可能写完是第一要务。

但很可惜,写完并不等于放在正式环境上可以动。

网站上其实非常多功能需要被真人测试,才会知道有没有问题。有一些测定,甚至开发环境与线上环境完全不一样,(以rails为例来说,其实就差很多,比如说程式class会不会被cache,asset有没有optimize,上传路径以及第三方接轨的设定等等......)

如果拖到最后一个月才做deploy这件事,因为到底有多少不一样完全是一个未知数,原本够用的一个月测试期,被这样一压缩就完完全全不够用了,而且因为专案截止日期已尽,随之而来而来的压力更加大了犯错的可能性。

一个透明的已知进度

Day 1就有一个可以直接测试的站台,还有一个很大的好处,能够确保专案上所有人都知道现在的进度,与规格书上的东西到底差多少。就可以尽早提出修改意见,下架等等,节省大家宝贵的开发精力。

如果专案截止日最后十五天,大家才知道很多东西是根本做不出来的,或者跟原本想象的东西相差太多,这时候会陷入相互指责,一片慌乱的状况。

绝对注意:捍卫进度

不过这一招的使用,专案经理或者是RD主管要特别注意。因为Day1就有一个可以直接看的网站,不少完全不懂技术的专案参与者(通常是企划或者老板),会对网站的裸站状态感到极度的恐慌,他们会挑剔UI,会不满implement细节,进而想要实际插手进度修改内容。请务必坚持住,坚持到进入最后一个阶段:测试修饰期才可以让他们修改(通常进入完工阶段,裸站状态也消失了,当初挑剔的东西几乎在这个阶段会不复存在,故也没有修改的必要。)

ps:可以架设一个issue tracking system,把他们提出的修改事项统统记下来,但通通不要实作。等到接近测试期,再来看看这些当初的建议到底还有哪些实际需要被执行。

只有完全不合实际应用的东西,或者是可以让实作方式更合理的东西可以再整个开发期,被 丢入排程中。

否则,他们的恐慌,会害这个专案完全结不了案。

参考文章

网站程式上线前需要准备的事(二)

评论区