IT女孩的日常

做IT女孩的这些年，熬夜发布已经是家常便饭。别说IT女孩了，客户验收也是陪同到三更半夜。

见过软件园清晨五点的样子，当时还激动得想出去吃个烧烤；同事不卸妆蓬头垢面的脸，也一清二楚。

有在试图想办法改变团队的整个状态，让全员尽量正常负荷工作。以下就用尽毕生呢个的加班经验，来讲讲。

Tips1 明确目标

1.上线时间

通常在一个版本或者迭代开始前，我们就该规划好上线时间，以便于团队调整工作的优先级，全力冲刺，或者留点时间提前去寺庙烧烧香。

发版时间一般由客户和团队协商决定，通常这个时间是经过反复权衡，所以承诺了的日期，团队就该按期完成。

2.发布功能范围

除了时间，团队更在意的是“上什么功能”。以便于BA以及QA或者TL，安排任务优先级，专注于当前功能。

这种东西，除了可以在看板上体现，也非常建议直接简单粗暴的打印在团队都可以看到的地方

Tips2 提前准备，降低风险

1.足以覆盖场景的回归测试案例和测试数据

碰到过发布异常顺利的项目，线上回归各种造数据耗费时间，团队都等着一起被消耗。

就在最近，碰到某项目上完线，发现没有满足条件的账户用来验证功能，不得已临时修改数据库，遍历排查谁的账户有符合条件的数据。

在设定好发布时间和功能范围后，可以由QA主导根据回归场景，提前准备好测试数据。案例也需要提前准备，为的是可以分派给团队的所有人来协作完成线上回归。质量是团队的事情，而非QA一人。

2.提前通知相关支持部门（运维/运营/第三方等）

所有的IT项目，几乎都离不开和第三方外部系统打交道。彼此之前的改动，也会影响到产品的稳定性。

做好充份的告知准备，可以避免很多突发事情的来临。

PM可以提前邮件告知上线时间，协商发布秩序。

有的公司，无法做自主发布，发布是交给运维团队的，提前给运维团队通知也显得事关重要。这事，谁找不到人谁着急谁心痛。

3.发布checklist

checklist主要用来记录一切上线前需要充份准备的事情，全员由责任完善并执行。可以是某个上线中发布顺序 的强调，可以是每个参数的提前索要.....总之怕忘记什么写什么。

过checklist这个事项，在临近上线前确认，每个事项安排到具体人去跟踪，确保万无一失。如图是案例。

Tips3：测试是保障

1.规划好环境的使用

由于成本的原因，很多时候产品的各个环境底层服务是不一样的，环境的差异会带来惊为天人的bug。所以在测试中，规划好环境的使用非常重要。

dev环境，通常用来开发结卡验收用；

sit环境，通常用于正式的功能测试

uat环境，通常是最接近生产环境，可以用来做回归测试和验收

pro环境，生产。

2.分支策略要清晰

团队中，同一个项目并行的任务越多，就可能出现很多分支。要大家合在一起发布吧？？有bug就不太好整。不及时合分支吧，临近上线合并又怕冲突，真的是左右为难。

我这边建议大家

1.高质量的代码和小的功能，可以先合起来，不能一次性规避风险，我们就尽量去规避。

2.团队要确保，提前一天把要发布的分支合并到一起，且尽可能保证该分支稳定。至于怎么做到这点，大家细品。这里面涉及到太多太多剪不断理还乱的东西了，开发会说安排不合理，BA会说效率不行。

3.功能测试要精而全

市场上面试，动不动鼓吹自动化能力。要我说，谁能离得开点点点的功能测试。

案例不要多，要精而有用，这个通常和经验和对项目的了解程度有关。

4.自动化测试

当然，有自动化测试更好啦。上完线，UI测试跑一跑，api测试跑一跑，还是能睡安稳觉的。

常见问题，关于团队对我的灵魂拷问

作为pm和ba，真的是太难吧！！每天接受无数致命拷问~

Q1：团队说：夜间发布压力大

A1：说实话，我也不想半夜发布。只是出了生产事故，这个锅我背不起！

业界比较主推的：

1.蓝绿部署。通俗易懂来说，正在发布的东西对线上来说无感知，不影响正常使用。发现有问题也能无感知的回滚上一版本。这个首先要团队有技术能力和经费做这个事情，做了一定能解决掉客户的担忧。

2.批量发布。按顺序一个个的发，发现失败就回滚，把影响降到最低。

Q2：团队说：频繁发布损害团队活力

A2：团队每周都在发布，团队压力太大，无法集中做事。

客户爸爸愿意的，我都争取了。哈哈哈，团队内，建议自定义一周大上线，一周小上线。团队人员分散专注某个时间段的上线功能。

Q3：QA说：这么多项目一个QA，我不行

A3：之前有个项目，新来的QA，第二天就不敢来了，吓到了。说项目太多，做不过来。

嗨，记住，质量不是你一个人的事情。把案例写好，指派人做，全员测试。实在不行，加人。撂挑子可不是成年人的风格哟。

Q4：开发说：我今天要做什么，明天做什么？

A4：不要担心 ，我们是敏捷团队，迭代我会给你整起来。好了，我累了不想写了。