Docker的第一个影响是对软件研发过程的，如果除去需求相关的环节，通常我们会把软件研发分为三个部分：设计/开发、测试/质量保障、线上部署/运维，基本上所有的软件开发活动都可以归纳其中。
虚拟化和容器技术涉及的是软件的工作环境，我们来看看在这些环节中，对工作环境要求有什么侧重。
设计/开发
重点在便利性。比如：能够自己熟悉的操作系统和IDE进行工作，可以很快的让软件run起来以便于做一些需要运行时环境配合的事情，以及修改代码以后可以不用重新启动服务进程就验证代码的变更影响。
同时，设计/开发面临技术选型的问题，如果可能，研发人员自然不希望受到太多约束
测试/质量保障
重点在环境的可控和一致性。测试和质量保障环节最介意的就是其工作的有效性，如果可能，最好完全和线上环境一致，这样其测试的结论是最具有参照性的。
另外，为了简化测试的压力、降低风险，测试工作有向上游转移的需求。而测试包括从单元测试、功能测试、接口测试、集成测试、系统测试的各个粒度，每个粒度的测试都要保证结果的一致和可重复，要尽可能做“干净的测试”
线上运维/部署
重点在自动化，而自动化的一个重要基础就是标准化，这块不用多说
看一看这些要求，会发现其中有很多是表面上相互冲突的——
- 冲突一
研发希望使用最熟悉的windows，但这将导致环境和线上不一致，所以可能的缺陷就要在测试环节解决，而这又阻碍了测试工作向上游迁移的总趋势。
- 冲突二
测试环节需要进行干净的测试，但是资源有限，因此需要在有限的资源上并行进行不同的测试，这时无论是用不同的帐号还是不同的运行目录，实际上都是对线上环境一致性的破坏，例如这样的脚本：
if [ "$ENV" = "test" ]
这是潜在风险，而且即使修改正确，也是环境不同的标志。
- 冲突三
运维需要标准化，但是之前的很多标准化工作实际上是基于某种技术栈（因为每一种语言框架都有自己的日志处理、监控管理......的方案），而这会导致对研发技术选型的限制。这一冲突是如此常见，甚至在对linux distribution进行选型时也会遇到，比如知乎上的这个提问，就清晰的说明了这种矛盾。
虽然看起来问题很头疼，但它们很多都恰好可以被Docker及其生态系统化解。
首先，Docker作为一种虚拟化技术，最为擅长的就是屏蔽外界的不同，因而可以解决开发、测试、运维的环境不一致问题，当然，某些环境本来就不可能一致，比如线上的计算和存储资源无疑更多，但是除此之外的环境差异，可以被docker降低到最低限度。这样，既保证了测试工作的有效性，又为开发活动像测试领域扩展提供了基础。
其次，Docker具有快速就绪的能力，这个能力其实常常被低估——人们的行为模式很大程度上受制于时间成本，一般来说，如果一件事可以更快地做，那么人们就会更有动力去做这件事。通过Docker，开发人员可以在本机快速部署服务集群，此时，开发人员就不会仅限于用单元测试来发现问题，他们有了更多的选择。
同时，开发人员获得的这种快速就绪能力又是非侵入式的，开发人员的可以选择自己喜欢和熟悉的操作系统和技术栈，也可以在Docker生态系统找到适合的镜像，开发人员调整Dockerfile并不比学习如何配置pom.xml或者site.pp更复杂，但是可以得到多样的技术栈和快速的资源就绪水平。
最后，这些工作没有破坏运维人员关心的标准化，相反，这实际上推动了标准化——无论使用什么语言框架，最终我们进行管理的都是各种container，优秀的工程师会让自己交付的image与port、ip无关，即使是赶进度的时候，我们至少也能比较容易的follow前人的做法而不至于留下一堆“技术债”。这样，在需要进行scale的时候，运维工程师可以比较统一的进行调度和资源规划。
从软件研发流程的角度看，Docker提供了一套标准的环境管理框架，它打通了开发、测试、运维的边界，使之可以以较低的成本进行协作，跨越传统分工的鸿沟。
