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：不要担心 ，我们是敏捷团队，迭代我会给你整起来。好了，我累了不想写了。
网友评论