devops工作流之(1)异步构建与部署
又名：被逼出来的敏捷
服务构建和部署看板应是组织文化的一部分。
部署应该异步进行，单个部署人员和开发人员不能被一个项目缠住，我们只管点击构建或者自动构建，成功与否由机器来通知，不要把时间花在等待构建与部署上，构建和部署看板也应该像晨会记录一样成为组织文化的一部分。
为什么要这样？
为什么是Jenkins？(好，一阵Jenkins吹)
一切为了效率。
这样可以解放人力，Jenkins 的一次配置，可以处处使用，设置好的模版和构建框架将会在部署人员资源紧张的时候发挥巨大作用。
流水线式的构建可以将代码和构建部分解耦，不在需要仓库的master权限，将开发人员与部署人员的强联系解除，在部署需求高并发的时候，不至于手忙脚乱，更重要的是，部署效率的提高，直接影响客户反馈和开发人员优化的脚步。
所有的项目有了构建历史，有执行人，执行时间，执行完的通知，命名空间，Jenkins的账号机制和插件系统是所有CI CD之中最全面的，天生为构建和容器而生。
mac端可以安装钉钉
需要我们做些什么？
需要更完善的Readme，比如项目依赖，项目简单介绍，和构建的简单操作，书面沟通的增加，意味着会减少部署时的实时交流和工作打断。
改变我们的规范，没有readme.md的项目，只是为了个人而写的，其他人看的话，就像是看书看到精彩的部分，突然缺页了，而且久而久之将会积累很大的技术债务。
在构建失败时，应该及时恢复构建，理论上所有的构建失败都要在第一时间去修复，需要我们在开发环境测试好，代码无误再提交，不然构建程序会出错，别人pull到错误的代码也是不好的。
当然，以上只是devops工作流的极小的一个流程，后面会把整个devops整个流程架构图设计补充下