2019-10-28老师，在J型曲线里为什么会有”自动化导致人工处理的测试增加"，自动化的进程中不是也增加了自动化测试么？测试的压力从手工转到编写自动化测试脚本，人工处理的测试增加时怎么回事呢？作者回复: 是这样子，由于开发辅助工具以及需求拆分导致开发完成的需求加速，流转到测试团队就对测试团队带来的更大的压力，如果测试团队的自动化能力没有跟上，那么就会产生瓶颈，比如给你举个例子，对于一个移动App来说，开发一个功能可能一天就完成了，但是全量回归测试就要两天，那么开发再怎么快，测试也快不了，这就要求测试能力的提升了，你可能会说，开发只改了一个功能，那么只测一个地方不就行了吗？事实上，并非这么简单，一来害怕出错，二来依赖关系变更影响分析没有做到位，你怎么敢就事论事呢？
1 4
2019-10-25我们去年7月成立devops小组，先通过jenkins实现了. net应用测试环境构建，paas实现了java应用的平台化构建，目前已通过二开paas平台实现了开发，测试，预发布环境的java应用部署，正在将正式java应用的部署从早期jenkins迁往paas。
途中有两个问题想请教下老师
1.虽然将应用迁移至部署平台，但感觉称不上cicd，请问老师cicd成功实践的判断标准是什么？
2.就是实践devops时，小组成员手上有很多遗留下来的本职工作，以及随着公司发展穿插进来的新工作，导致先前计划的devops相关工作无法按计划进行，这种矛盾该如何处理？展开作者回复: 你好，关于第一个问题，我给你提供一个最简单的指标，那就是如果只修改一行代码，从研发提交到上线发布给用户需要多长时间？你可以尝试基于现有的CICD流程来看看，我可以告诉你的是，从业界调查报告来看，这个时间不超过一天，精英公司不超过一个小时。
关于第二个问题，我是觉得从来没有准备就绪的时候，并行工作难以避免，如果想保障DevOps的工作推进，就要在流程上约定，比如每个迭代周期，有百分之多少的工作预留给DevOps，如果没有这个底线，那只能说明DevOps的工作优先级不够高。 3 3
2019-10-25老师提出的“羽化原则”比较适合我们当前的现状，从底层开始做起，需要一个可以统领的“大脑”，前端时间申请新服务器，整个流程走了一个多月，本来是准备11.11之前切换的，结果服务器下来之后由于网络配置，走流程开通权限啥的浪费了不少时间（主要就在审批），然后管理啊系统封版，只能等到11.11后，反正目前问题还是比较多作者回复: 你好，像你说的这种申请资源慢，在很多公司我看都是通病，而且靠一个部门也很难解决，人家不听你的啊，所以这种时候就需要DevOps这类专项来改进，甚至需要借助外部力量，明确指出这个地方有问题，其实很多时候聘用外部专家，核心就是透过他的嘴来说出内部不方面说出的问题哈😄
2
2019-10-30向上沟通真是很重要的能力，上级是我们能利用到的最好的资源作者回复: 没错，但是很多人都不会利用这个资源，我想这跟组织的文化关系很大，我在最早上班的时候是一家日企，第一天就给我们培训的菠菜文化，也就是报告，联络和相谈这三个词的缩写，有进展及时报告，有问题风险及时联络，有创意和想法及时相谈，这三点对我受益匪浅，推荐给你。
1
2019-10-28当devops转型工作与本职工作并行时，可否采用kanban方法对工作进行优先级和阈值设定，并通过沟通协商来制定针对触发阈值的决策作者回复: 你好，其实DevOps转型工作和本质工作，都是需求，只不过我们人为的区分了业务需求，技术需求，持续改进需求等多种类型而已，实际上对于优秀的DevOps来说，持续改进类需求和技术需求会占据固定的比例，而不是业务需求的牺牲品。比如像谷歌的工程师，每周有20%的时间是自由的，就是公司鼓励创新的一种途径。
关于看板的使用方法，欢迎继续往后听，我会通过两讲来进行详细的介绍。 1
2019-11-13我是负责移动端的devops建设，目前devops团队就我一人，现在的自动化就部署了jenkins去自动化编译，打包，测试 ，发布到应用市场这样一套流程。 后续的工作就不知道怎么去开展和推进了，有点迷茫。作者回复: 你好，我现在也是在负责移动端的项目，我觉得根据项目规模不一样，痛点也不一样，比如我们之前的发版动作比较复杂，还必须专人负责，这就可以优化为一键发版，任何人都能操作，减少人与人之间的依赖。再比如，安全扫描的环节手动执行，这就可以把这个环节串联在流水线中也让他自动化，减少部门与部门之间的依赖。还有，测试安装调试包很复杂，需要自行下载连接手机安装，那么就可以通过二维码，发送链接，手机访问网页等方式一键推送和下载，减少人和机器之间的依赖。所以你看，在主流程跑通之后，其实有大量的可操作空间，这就要站在全局视角观察整个流程的瓶颈点，看看有哪些是自己能做的，也就是持续改进的过程。
2019-11-081.move fast and break things
2.我感觉我在看的不是devops，而是实施敏捷开发，精益开发，增长理念落地，和分工协作，群策群力。总之，好泛。作者回复: 呵呵，好经典的一句话，只不过我总觉得break既可以翻译成打破常规，也可以翻译成把系统搞挂，要选哪个就看DevOps的了😄
2019-11-08要说问题，可能在于整个组织把这个工作当成负责devOps工具平台搭建实施的那些人事情了，而这些人自己甚至也认为devOps的相关工作比业务相关的优先级要低，往后排，长此以往，也就没有以后了的感觉
要说解决，估计还得各种吹风儿，尤其给领导的吹边风儿，争取更多的授权，然后再借一些业务开发问题引入一些具体实践措施，也算瞒天过海，用心良苦了吧作者回复: 精辟！我就在做给最大的领导吹风的事情，但是要把这个事情提升到战略高度，让老板理解的前提下认为这件事情跟业务同等重要，我只想说，不容易，这就要用到一些整理信息的技巧了，比如“推拉镜头”，从小点着手，不断变焦到全局，最终达到目标，我下周试验一把，回头给你反馈😝
1
2019-11-06军工企业一年两个版本 就不需要、无法应用 devops么？表示存疑作者回复: 你好，我忘记有没有说了，今年再碰到这个朋友，他们对DevOps的模型框架非常感兴趣，只能说不是不适合，只是时候未到吧，不知道你有什么观点呢？
2019-10-28每学一篇，老师文中描述的问题我们项目都有。作者回复: 不仅仅是你们团队，我见过的绝大多数公司问题都有类似，还是组织问题没有解决，期待你的更多思考和解决方案，一起来做实践者，加油
2019-10-24地区和文化限制 IT的前沿技术在我们这里至少延后3年 学着以免日后被淘汰作者回复: 技术不分国界，地区，我见过有些公司的程序员就是在家里办公，网络已经大大加速了信息流动效率，参与关注一些开源项目，是很好的选择哈，一样，你能找到一个领域，并成为专家，加油。
2019-10-24打卡学习，积累知识和经验待以后自己使用😀作者回复: 加油哈