先就事论事地说，如果项目规模不大，也没什么客户，那么什么时候上线都行。但如果项目有一定的规模，这意味着上线时间不会很短，再结合客户量很大，那么一般真得找个客户访问量少的时间点上线，一般是凌晨，有些甚至是周末凌晨。具体是否应该在凌晨上线本文不想展开，本人呆过外企和互联网公司，本文就将以此为例，详细说说项目上线的步骤，先说外企的。

1 在上一年的年底一般会定好下一年上线日期（release day），每个上线日之间会间隔1个半月，这一个半月就相当于敏捷开发里的迭代周期。当然如果各业务组有需要，可以通过走上线流程，在规定的上线日之外再走发布流程。

2 对应地，每年都有代码冻结期，即code freeze period，一般是12月会冻结一个月，因为这个月是圣诞假期，对方公司维护人员放假，出了问题不大好处理，所以干脆就不让发布，这个期间如果要发布，得拿到很高级别领导的批准。

3 一般分为测试，集成测试和生产环境，测试环境每个组怎么发布都行，集成测试环境，需要写邮件给专门的support支持组，告知项目编号和jenkins版本，让support组发布，至于生产环境，一定是发布日才能懂。

发布时一般是叫“one click deployment”，即一键部署，一般各开发组先在jekinks或udeploy等部署组件里写好脚本，然后请support组评审，support组看了没问题，就会把集成测试环境和生产环境的部署权限（即jenkins按钮权限）收回，这样各开发组只能通过jenkins把自己代码部署到测试环境，在测试环境上好了以后，就先部署到集成测试环境，一切测试好了以后再发布到生产环境。

4 在发布日的前一周周五，先会封闭集成测试环境，原因是，各开发组应该在发布前一周，把待发布的代码部署到集成测试环境并且已经通过测试，确认没问题，这样发布时风险会最小。

当然在发布这周，通过测试发现集成测试环境上的代码有问题，需要重新部署测试，那就需要部门领导的审批邮件。也就是说，在发布前一周，所有的代码和（更改数据库等的）脚本，应该全在集成测试环境上测试通过，而且要持续运行一段时间。

5 发布一般是在美国时间周五下午9点，（中国时间周日上午9点），在发布的这周内，各组要填写发布申请报告，一般是通过service now这个工具来填写，无非是写要发布什么内容，有什么风险，然后要拿一些审批，到了周五下午（中国时间），各组就开始写邮件给support team，告知service now上的流程都已经拿全了，然后告诉他们该发布哪个版本。

比如用jenkins工具，会有个build号，这个build应该在集成测试环境上测了许久，发布的时候就告诉support team，让他们到jenkins上点下这个build号，这样就发布到线上了。

6 其实发布的support team就是在美国时间周五晚9点（上海时间一般是周六上午9点），点一下jenkins等工具，他们其实是不知道业务的，或者按流程，到数据库里去更改表。他们发布好以后，会陆续给各组写邮件，意思是我们发布好了，你们去确认吧。

收到这个邮件以后，各组就开始到生产环境上去确认，一般这会用jira等工具列好确认点，确认了没问题，就回个邮件，大致就说没问题，发布成功，support组就凭这封邮件，认为该组发布成功。

7 发布时如果遇到问题，一般就要看，如果仅仅是自己组内的问题，不影响其它业务，一般不会回退，其实由于待发布的代码已经在集成测试环境上测了许久，一般不会有问题。本人在这个公司干了若干年，没见过有发布回退的情况。

一般来说，一些小公司的发布流程和上述流程很相似，都是走敏捷开发流程，都会在发布前在测试环境上测代码，而且发布前代码会封版，从而确保待发布代码的质量。

其实如果一些初级开发感觉没法证明自己做过真实的商业项目，那么在面试中如果说下上述发布的流程，说明几个要点，比如jenkins,jira,发布审批流程，集成测试环境，那么应该能有效证明自己的商业项目经验。

但是，如果是互联网公司，项目里一般会包含高并发组件，比如redis集群，kafka等，那么在发布过程中不仅要管代码，更要重启这些中间件，或者用这些中间件清洗或导入数据，这个过程还要复杂些，甚至可以这样说，如果能在面试中证明自己参与过发布，并且解决过发布中的问题，那么一定能有效证明自己。

本人有其它的事情，这篇文章先写到这里，后面有时间再写互联网公司的发布流程，以及对应地该如何准备面试说辞。