产品的技术小课
其实最早的时候，devops中，"dev"指的是开发人员，"ops"指的是运维人员。它是为了提升运维效率的一种协作方法和工具。（这是比较狭义的解释）
上古时期，当成立一个新项目，前端想发布到线上时，操作流程非常繁杂：
1、登录到服务器，配置好域名和项目首页的映射关系。
2、配置好静态资源缓存机制。
3、上传前端代码到服务器的指定位置
4、在服务器执行构建命令，生成前端构建后的代码。
等等。。
其实以上很多步骤都是“运维”的工作，如果后面项目越来越多，每个项目都这样配置一遍，效率是非常低的。
所以很多“持续集成/持续交付”平台就应运而生了。
持续交付平台会代替很多运维工作，让开发人员更关注于自己的业务代码。
比如腾讯的coding平台，当你新成立一个前端项目时，只需要在平台上面建立一条发布“流水线”，就可以把代码发布到线上了。
但这只是通过自动化工具解决了“运维”方面的效率问题，产品和开发之间的协作效率问题依然没有解决。
比如说，当开发写好代码，想发布到测试环境让产品验收时，该如何通知到产品？每次都要私聊他吗？
再比如当开发完成需求并发布到线上后，过几个月后，如何能追溯到哪个需求对应哪块代码？
还有开发评工时记录在哪里？
后来，devops强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付软件。这是比较广义的解释。
这就需要一个一体化的项目管理工具了，能把整个软件生命周期串起来。
各大云厂商其实都有提供devops一体化平台，个人觉得阿里做的比较好😆
从产品提一个需求，到需求上线，是一个闭环。
需求能跟人关联，也能跟代码关联，也能跟上线的构建产物关联，还有自动反馈消息到IM工具、邮箱等等。
--- end ----
