来到帝都，最爽的是几乎每周都有技术沙龙。终于发现居然有人把书上的理论通过一个个生动的例子讲出来。
比起以前，再也不是看完书无处问，无处讲的状态了。这也是我重新开始另一段工作的主要原因之一。
很小的时候就养成了脸皮厚，对于这种沙龙，基本上有时间就去。偶尔再拿点纪念品，感谢各个的赞助单位了：）
既然这样，博客也应该多写点什么。本着不在博客公布某重要敏感信息的原则，以后的博客只谈技术，不谈具体公司，人名，以及数字。
该开始了：
n个月前知道了devops的这个概念，很偶然，这次有机会可以体验到一个devops的具体工作。先那现在实例说说：
某开发团队，每周正常发布两次。紧急发布不计其数。
周一周三提交上线申请。
devops收集上线申请后，提交相关提案，交由测试以及相关部门测试。
如果测试通过，并且代码经过review后，开发开始向trunk提交代码后，由devops开始打包。
devops开始预上线（这个是不是在所谓的灰度环境中还真不太清楚）
测试对预上线的结果进行测试，如果通过则开始第二天的全量上线。
周二周四，预上线通过后，开始做全量上线。
周五喝喝茶，聊聊天：）
呃，这就是某团队的回环，按照持续交付的维度目前还处于
一级：阻碍级（Regressive）
1. 软件的构建过程是手工的。
2. 构建过程冗长，而且其中的主要步骤常常出错。
期望能达到
二级：可重复级(Repeatable)
1. 在开发人员的代码上进行定期的自动化构建和单元测试。
2. 利用自动化过程，能够从源控制中重新生成任意一个构建版本。
3. 开发人员的提交频率是不定的。
具体工作：目前来看改变流程这事推进起来比较困难，因此从务实角度将，先把手工手机上线需求变为自动。
先用python现学现卖的写了个脚本，估计这周就可以试运行一下了。
第二步， 把每个提交的状态记录到文件中，抵达checkpoint的时候自动判断状态并且通知相关人员。
这样可以把目前俺手里的工作完全变成自动化，目前也只能做到这么多了。困。。得睡觉了。。先不写了。