淘宝ASSETS前端开发流程

流程，通俗来讲，就是许多人，在做一系列的事情时，怎样相互协调，安排好这一系列事情的先后顺序，有什么事先的约定，需要达到怎样的预期目标。

在UED里，前端同学需要处理的需求比较多，早些时候，前端这里的开发流程还是比较模糊的，UED以外的同学也不清楚这边的工作具体是怎样进行的，所以难免会有需求插队的情况发生，打乱了大家的计划，因此今年Q3的时候，在与SCM团队同学的共同努力下，形成了一个前端的ASSETS发布流程。

这个流程主要针对ASSETS发布的需求做了一些约定，制定了相关的几个时间点，包括审核需求、提交代码、daily测试、预发测试、正式发布到线上确认的时间。
ASSETS流程简述

需求审核

在提需求之前，需求方一般都会先找PM或者相应产品线的前端咨询一下，如果可行的话就会在周四之前将需求提到平台上，到了周四的时候，前端会结合自身的工作情况，将平台上的需求接收并纳入自己的日程中，预估完成时间、发布时间以及相关的发布简述。

编码开发

周四需求评估完以后，就会按计划开始处理需求，将涉及ASSETS发布的需求优先处理，不涉及ASSETS的放在靠后的时间处理，一般这段时间是从周四到下一周的周二。SCM会在每周四开一个新的ASSETS分枝供前端在下一周开发使用。

提交代码，合并到daily测试以及预发测试

如果有涉及到与后台开发相关的需求，前端的同学会在周一就把代码提交，这一天会有一次合并代码，方便后台开发来测试。其他的同学一般最晚会在周二下班之前把代码提交，在周二，会有多次合并代码到daily的操作，每次操作完后，SCM的同学会在前端的群里通知到大家，方便大家测试。

周三早上，SCM的同学会将代码发布到预发环境，此时就可以在HOST中绑定IP，换用线上的地址来测试。

正式发布

周四上午，SCM的同学确认后，将没有问题的代码发布上线。
流程的作用

在团队不断成长的过程中，处理的需求数量也在增长，需要考虑到开发的效率、产品的质量以及团队协作间的配合等因素，这个流程能为我们解决很多相关的问题：

督促需求方做好相关的规划

有些时候，一些需求的细节还没完全确定，但需求方总希望能将他想到的各种细节都实现出来，然后再挑选其中一种做为他的方案，所以需求的变更会有些频繁，然而这样的成本有些高，一切应该在计划后再去实现，而非反其道而行。现在需求方会在提需求之前，会花时间地去考虑他们的需求，将尽可能多的情况都想清楚，做好必要的沟通工作，权衡各种利弊之后，再给出一个比较成形的方案。

保证需求安排的有序性

在一个大的团队中，不同部门的同学在一起合作，因为沟通及一些特殊情况，效率或多或少会受到一些影响，良好的规划能有助于提高开发的效率。

通过每周的需求审核，安排好下一周的日程，由于需求的优先级和先后顺序都已排定，工作的条理性会更加清晰，需求插队的现象也有明显减少。当然我们也有紧急流程，但是它仅限于处理线上bug以及一些经过多方确认的紧急需求，有其自己的适用范围。

统一测试，归避风险

之前的日常处理中，可能会遇到这样的情况：甲、乙两个同学分别需要处理两个日常需求，他们的需要改动到的代码会有重合的部分，如果他们并不知道这个情况，那么在他们本地的单独测试中，一切都是OK的，然而当发布到线上去时，发现出了bug或者一方的改动没有同步到线上，查原因后发现是提交的代码相互覆盖了。

现在要处理的需求数量越来越多，为了避免上述情况，新流程实行以后，大家会统一来做多次测试，这样就更容易发现bug，可以大大降低协作开发而产生的风险。

流程本身就是一把双刃剑，有利有弊。一方面，它使我们的需求变得有序，使前端能够在处理一个需求时，不会频繁被其他插队的需求打断。并且因为发布有时间点的设定，所以测试工作会更加严谨，这有助于提升代码的质量。因此对于我们来讲，流程带来的好处是显而易见的；但另一方面，它额外地增加了做事的成本，涉及ASSETS发布的需求，就像赶某班火车一样，错过了就只能等下一班，所以也给需求方带来了许多不便，有待改进，不过这可以通过长期的合作而慢慢被弱化，双方达成了一种默契以后，情况会好很多，现在这样的情况已经比较少了。

尽管在流程使用之初，会带来诸多不便，但是从长远来看，流程有助于使一个团队形成统一的工作方式和态度，将繁杂的事情化整为零，有条理地去处理它们。因为流程，每一个人的责任感都会增强，对风险考虑得会更多一些，这一切都会使产品有质的提升。而我们所有与这个流程有关的人，都会不断地去推动流程改进的工作，这其中还有很多需要思考的：

    如何将我们的流程推广到整个公司，让大家都能了解我们的流程，这样在未来需要合作时，需求方需要注意些什么，相关的时间点以及开周时间的预估等，他们就会心中有数。
    ASSETS的发布还不够灵活，如果把和应用相关的ASSETS独立划分出去与应用一起发布，这样剩下的需要发布的东西就会少很多。或者是按产品线来设计发布流程，根据实际情况来发布。
    如何来简化流程上的一些细节，在保持效率的同时，降低实际操作中的成本。
    每周二是一个特别的时间点，为了赶在这最后时间提交代码，之前的开发会有些紧张，这种情况也有待改善，比如未来可以一周有两次发布。

流程不是生来就完美，但从现在它带给我们的好处来看，遵循并使用它，对我们的开发会起到很大的帮助作用。我们对待它的态度，决定了它对我们会有怎样的反馈，如果觉得它不合适了，就发出自己的声音，想办法去改进它，不要只是被动地等待。

———————————-

部分名词解释：

daily环境：UED的一个日常测试环境
预发环境：外网IP，需绑定访问，供内部使用测试
ASSETS：脚本和样式存放的目录
SCM：软件管理配置
PM：项目经理