痛点 随着应用逐渐复杂化，构建的流程与依赖都变得越来越复杂； 参与的人员越来越多，大家使用的开发环境难免不一致； 很多时候编译环境带来的问题是潜在的（例如路径处理等等），无法在打包过程就发现；
当然，在正式发布时，大多数团队通常都会采用 CI 系统构建出安全的包，以此规避。
然鹅，在平时开发中我们难免遇到临时验证问题的场景出现，在很多团队里，开发人员会在本地机器里直接构建之后将产物丢给测试验证，这个过程就容易因为环境因素而遗漏问题。
根本痛点： 开发环境没有标准化
想法
docker 在运维领域已经被广泛应用，很适合用于统一环境。而在本地开发里它出现得却很少。通常我们更倾向于用它负责构建与部署。本地使用 docker 最主要的障碍有两个： 起步麻烦：你至少需要知道 docker 是什么，怎么运作，及一些基本的概念，这有一些学习成本； 使用体验：即便现在有 gui 的存在，创建容器与镜像时还是需要记住一些配置，手敲命令，这有一些记忆成本；
如上面提到的，我们要解决的是环境标准化的问题，了解使用 docker 是一个解决过程，而不是方法。对于大多数人来说，他们的诉求只是一个容易用的标准环境，而不是多花时间去学一个新东西。
做了什么
设计这个东西，目标有三个： 环境标准化 使用门槛超低 易于团队协同
解决方法： docker 命令行启动，少打字 配置化，配置文件跟仓库走
可能有人会问，docker 已经有了 Dockerfile 与 compose，为什么还要一个配置文件。他们的关系是这样的： compose：描述我们需要一批什么样的容器 Dockerfile：描述我们需要什么镜像 新配置：描述我们需要一个什么样的容器，如何与我们的工作区关联起来，并 check in
设计思路很简单粗暴，但效果看起来是不错的：

而你只需要配一个简单的 json 在你的仓库里： { "env": { "name": "hello", "image": "maven:slim" } }
这么做之后，你的团队只需要预先构建好一个 image，配进仓库，所有人就可以统一环境啦！
项目
https://github.com/williamfzc/devcube
最后
欢迎各位一起讨论 ：） 欢迎进来写 features