当下，容器已成为一个非常热门的趋势，而只要谈到容器大家也通常都会说到Docker。甚至，容器已经有了自己的动词形式containerizing，用以描述使用Docker将应用程序打包。
在热烈争论之后，Docker领域的重点迁移到如何在现实生产环境中使用容器，人们纷纷将“containerization”的哲学运用到存储、网络，亦或是管理。
毫无疑问，在这个强劲的势头下，Docker可以在生产环境稳定使用肯定不会太遥远。而这里将分享一些基于Docker的用例，它们已经得到了工程师的验证。
首先，在另一篇博客中我已经简单的提到了这些，而本文则是基于和同事交流的扩展。当然，这些并不是对Docker只是一个市场趋势说法的辩驳。
将功能测试提升一个等级
在这里，我不想继续去重复解释功能测试以及不同类型的软件测试。当下已经有很多文章解释为什么单元测试前必须基于真正的服务和运行环境。
当下，基于单元测试的测试驱动开发已经被证明是一个很好的应用程序开发途径，整个开发过程将与单元测试密不可分。通常，你会同时开始写单元测试和代码，并以迭代的方式不停的填补代码和单元测试。
当代码运行正常后，在评审和合并之前，它通常会被提交到CI环境以运行单元测试，也许在review和merge之前，还会做一些功能测试。
针对某个功能的功能测试并不会在同时提交，因为功能测试进行起来并不容易，同时也会花费很多时间。你必须正确配置所有东西，比如数据库的初始建立，比如测试所需的上下文中如何进行通信。
同时，即使你以这种方式搭建了测试环境，运行的也还算良好，大部分人仍然只是简单地将它放在几个同事共享的一个虚拟机中进行，而不是设置一个一整套的环境，实现类似DB、APP和Web Server那样的交互。你肯定也不会去测试应用程序的扩展性，因为它的开销更加昂贵。
在多服务间进行功能测试，而不是一个简单的VM
而这些，你使用Docker和Fig搭配就可以轻松实现。你可以指定不同的环境，并快速的进行部署。你可以直接在CI中运行不同的目标和内容；更重要的是，你可以非常便捷的将之与同事共享。这一切都是因为Docker，它可以为镜像构建一些非常智能的缓存，并且在数秒内运行这些镜像。
告诉用户应用该以什么样的方式部署
在构建Dockerfile时，你会指定应用程序的构建途径，以及配置的具体内容。同样，你可以向用户表达它是如何工作的。鉴于你并不具备专业复杂软件部署从业者的经验和技术，结果可能不会尽善尽美，但是最低限度的，你可以告诉用户工作是如何进行的，而不是让他们自己绞尽脑汁。
甚至，你可以让单元测试更加鲁棒！
在另一篇博客中，我为大家介绍了Dox。如果你玩过OpenStack，你会发现OpenStack经常需要运行众多非常复杂的测试，因此我们需要一个系统简化这个过程中的复杂度。然而，并不是只有OpenStack才有这些非常复杂的测试，比如你需要运行Sqlalchemy，同时你需要在后端的sqlite，以运行你的单元测试。但是最终你可能因为一些非常奇怪的状态终止，比如foreign keys不能正常工作，以及一些其他SQL功能不能实现。但是通过容器，你可以轻松的将配置好的DB打包，从而轻松的完成这些测试。以此类推，在你需要依赖某个系统，或者某些配置/文件时，Docker可以轻松地将它们打包。
希望在了解这些点后，你能更加坚定容器是开发流程中必不可少的一环。同时，我也希望有更多的内容会添加到这些工作流程中，而未来也会出现更多强大的工具让开发更加便捷。
原文链接：Use cases for Docker driven development.（编译/童阳 审校/周小璐）