互联网公司构建与发布如何管理才能做到所测即所发？

hbxtly

有弄过所测即所发的朋友，帮忙看下流程，提下意见，谢谢


背景：

1、  环境：

a)        线下（测试环境、开发环境）、预发布、线上（预发布数据库与线上数据库一致，站点及服务程序不同）

2、  项目情况：

a)        项目周期短，1~3天的都有；

b)        多个开发人员同一个站点、不同项目的情况长期存在；

3、  现在的发布过程：

                              

目标：

所测即所发：希望线下、预发布测试的同一套代码，通过后发布到线上也是同一套代码。

授客

大体流程好像还不错呀，你是哪里出问题了？

18612201214

你的这个流程，让我看到了微软O365项目的周更新计划的影子。

zhouzj3979

多项目同时进行时，代码是提交到同一线下环境，还是拉多个线下分支？多个项目都要到预发布环境测试时，怎么处理的？需要排队吗？代码已经更新到预发布环境了，这是突然有紧急代码要发布到线上环境，怎么处理呢？代码合并有冲突，先前发布的功能有必要全面回归吗？

hbxtly

zhouzj3979 发表于 2015-2-11 13:30
多项目同时进行时，代码是提交到同一线下环境，还是拉多个线下分支？多个项目都要到预发布环境测试时，怎么 ...

谢谢回复，你所写的就是目前遇到的问题。
线下是环境是一套，即多个项目分支在一起测试，预发布如果出现插队的情况，只能将之前的代码抽出来，将需要发布的更新上去，再发布。现在做合并是强制合并，发布到线上会再做一次回归。
所以这里就造成了，无法保证测试质量，毕竟线上回归覆盖面是有限的。
所以才想看有没有办法改造，做到所测即所发

zhouzj3979

hbxtly 发表于 2015-2-12 09:23
谢谢回复，你所写的就是目前遇到的问题。
线下是环境是一套，即多个项目分支在一起测试，预发布如果出现 ...

我们现在的做法是这样的。日常需求以周为迭代周期，代码提交线下环境，如果一周之内处理不了，以项目形式处理，拉项目分支，代码提交到项目分支，在合并到线下环境。在需求评审立项的时候尽量避免多个项目同时更新预发布环境，或者按项目优先级排队（这一步项目分支合并线下环境时控制好），就是保证线下环境，预发布环境和线上环境都是同一套代码。如果有插队情况两个选择：1，插队代码提交线下环境，挑版本合并至预发布环境（我们现在做的，但是是我反对的）2、先回滚线下环境代码，在提交插队代码（我提议的，开发反对的）。
其实最主要的还是你的发布流程和发布策略要公开透明，最好能形成一个政策。遇到需求扎堆的时候可以拿这个说事，至于优先级，就交给业务部门pk

hbxtly

zhouzj3979 发表于 2015-2-13 09:36
我们现在的做法是这样的。日常需求以周为迭代周期，代码提交线下环境，如果一周之内处理不了，以项目形式 ...

你说的政策我非常认同，有政策好说事。
你建议的方式有一个前提，就是插队代码必须是先测试完，先上线的。
而我们有些项目是先做，上线不确定。
有些项目到了预发布测试完，都不一定保证能上线，当然这种情况非常少。

槑丫头Testing

zhouzj3979 发表于 2015-2-13 09:36
我们现在的做法是这样的。日常需求以周为迭代周期，代码提交线下环境，如果一周之内处理不了，以项目形式 ...

关于插队代码这里，谈下个人看法。如果有插队代码，那必须在线下环境测试通过后才允许合并至预发布环境，这样的好处在于如果线下环境测试不通过，那就不要发布或者项目整体延期，既保证了插队功能的正确性同时也是对预发布环境中的代码一种保证，不然如果未测试通过合并只预发布环境后，会引起其他功能的不可用。对于您说的第二种方法（先回滚线下环境代码，在提交插队代码）这样的成本较大，而且回滚后需要重复在线下环境重复测试之前已经测试过的代码，发布至预发布环境后还得测试，延长了测试周期。