非即时可用资源学习在我们软件打包实践中的应用

一、我们面临的问题

1、软件打包（构建）工作频率问题：在ST、UAT测试环节，我们需要不定期的打包，用于更新软件和修复bug，多少时间打一次软件包（含部署到服务器上去）是我们面临一个问题，每次commit后打一次包，打包所花费代码太大；过较长时间打包，bug得不到即时回归，间接对软件质量造成问题。同时commit的重要性也分等级的，有些必须马上打包。我们10个人在团队，在测试阶段，一般都要花费1-2人·天的打包精力。

2、软件打包工作的无趣性：软件打包，并部署到服务器上去这项工作在我们软件研发团队是没有专门的人去负责的，一般是由研发同事兼任，或者研发同事轮流开展。如果团队中指定人固定去完成这项工作，估计这个指定的人会因为看不到前途，八成会离职。

二、我在《看板方法》这本书上学习的理论知识

1、软件打包这项工作专业术语叫做“非即时可用资源”，它看起来像瓶颈，有点像我们开车时，在红绿灯前停下来。在软件中，非即时可用资源一般是共享资源或者需要多任务工作的问题。

2、在日常生活中我们遇到相同的问题：乘坐地铁，我们需要等待；无桥过河需要轮渡，在旅游景点等待摆渡车。

三、书中提到的几个解决方案

       1、挖掘/保护措施

       在非即时可用资源前设置缓冲区，并且纳入价值流，可以叫做待打包（待构建），这样提高该列的WIP，提高效率。

2、服从举措

指定专人或者招聘专人进行打包工作，让打包工作不再成为瓶颈。

3、突破措施

建一个真正的自动化打包（构建）工具，无需研发人员花费较多的时间参与的。

四、我个人思考

       1、有些方法不可取

       指定专人或者招聘新人做这个工作，我觉得不可取。原因是这种不产生利润的工作，公司一般很少在各个团队都指定专门负责人，有也是很多人公共资源，还是非及时可用资源。另外指定专人，没有额外待遇情况下，很多技术人员都会离职，交接工作更麻烦。

       2、新建真正自动化系统

       很多有想法的公司，都有自动化构建系统，但是真正做到无需研发人员投入的真的很少，也很难做到。至于为什么，这里就不讨论了。

五、我个人认为的最佳实践

       1、打包人员选择

       我们的做法是在指定小范围人员轮流进行打包工作。

原因是首先有些人员不适合进行打包工作，例如团队技术大神、做事特殊粗心的人员。打包工作也是有自己特殊性的，需要经验的，如果指定1个人，那么这个人离职会造成较大损失，另外这个人也不会乐意的。

2、打包频率

在测试阶段，我们会告知团队我们会在每天工作日下午2点打包，打包频率为1天，请大家自己协调好自己commit时间。如果有重要紧急的commit，需要马上打包，需要写邮件申请给项目经理，项目经理同意后再打包。另外在每天2点打包前，我们会看有无commit，如果没有commit，我们就不会再次打包了。