Codenvy 背后的技术 -- 一次与 CEO TylerJewell 的深入访谈

与 Eclipse Orion ， Cloud9 及其它新一代 IDE 一样， Codenvy 也是其中一员。它们都试图转变开发人员创建软件的方式，为他们提供可以在任何主流浏览器上执行的前端界面，以及可以在服务器或云中执行的后端，该部分将处理所有的力气活：编译、代码分析、构建、预备、发布等等。

Codenvy 可以支持多种语言的在线开发，其中有 Java、JavaScript、HTML5、CSS、PHP、Python、Ruby 及 XML。同时更多的工作也在进行中，以便支持更多语言，同时为社区提供所需工具用来添加想要的语言。对于框架也是一样的，Codenvy 目前支持 Spring、Node.js、JSP、Rails、GWT 和 Django 等框架。对于 Android 开发的支持也在 Google I/O 2013 对外发布了。

应用程序在 IDE 里就可以往不同 PaaS 上发布：Amazon（Elastic Beanstack）、CloudBees、Cloud Foundry、GAE、Heroku、OpenShift、AppFog 和 Tier3。

对于代码仓库，Codenvy 一开始就支持 GitHub 和 BitBucket ，随后支持 Git 和 Mercurial 代码库，但是最近添加了对 Assembla、BeanStalk、Codebase、Deveo、GitEnterprise、Gitorious、PikaCode、ProjectLocker 和 Unfuddle 的支持。Codenvy 使用 Jenkins、Hudson 或 CloudBees 来持续集成。

Codenvy 支持结对编程，它含有实时多光标协作功能。其代码编辑器包含有语法高亮，代码补全和重构功能。

我们采访了 Tyler Jewell，Codenvy 的 CEO，以便挖掘出那些为该 IDE 提供动力的技术背后所存在的更多细节。

InfoQ：Codenvy 是由什么构造的？其背后技术、服务器和客户端都是什么？

TJ：Codenvy 作为一个云系统，包含有多个节点来处理路由，负载平衡，身份管理，IDE，生成器，运行器和分析器。核心 IDE 本身是用 Java 编写的，并由 GWT 生产优化后的客户端 JavaScript。对于大部分浏览器和服务器之间的沟通，我们则采用 WebSockets。其它在系统中广泛使用的技术包括：Apache Web Services，CloudFoundry，Gluster，CodeMirror，Collide（协同编辑器），Hadoop 和 Apache Pig。其实 Codenvy 的核心是作为构建云 IDE 的平台。在内部，我们利用一个运行时框架来管理发现，加载，协调和激活分层扩展。扩展是以插件形式打包好提供语言、框架、编辑器、文件管理、生成器指令和运行器指令。然后我们创建一个 IDE 框架链接各个插件并部署到云框架，用来提供租赁、灵活性、日志记录、身份管理和隔离控制。我们建立了自己的多租户 IP，这样在单个 JVM 上就能运行最多 250 个 IDE，同时也防止 IDE 在执行生成和运行流程时产生拥堵现象。我们针对 OAuth 创建了自己的拓展，用来允许入站身份验证请求，以及向外拓展身份到云下游以简化用户工作流。我们使用 puppet 和大量的 Bash 脚本来处理与 Devops 相关的问题。而我们的网站，作为独立于我们云生命周期的产品，是通过 JavaScript、Yeoman、Grunt 和 Jekyll 撰写的。而对于工具，我们则大量使用 GitHub、Jira、Confluence 和 Selenium。Codenvy 的原始代码是通过使用 Eclipse 和 IntelliJ 来撰写的，但是现在大部分 Codenvy 是通过 Codenvy 本身来撰写的。

我们使用超过 100 多个开源库来创建运行现有 Codenvy 的各种元素。

InfoQ: Codenvy**** 是在哪里运行的，在您自己的服务器上，还是在云里？到底是哪个？

TJ：我们有开发（验收测试），临时（完整的测试环境），准产品（允许市场营销、技术支持和文档参与进来的最终确定版本），以及产品等不同环境。我们在 AWS 上运行产品。准产品则在我们自己位于欧洲的数据中心内，执行于 Eucalyptus 之上。我们将临时环境运行于 AWS，这样就能进行 Devops 配置，测试多种不允许内部访问的云 API，以及执行大规模的测试。我们的开发服务器环境都是包装有 Codenvy 的单服务器，它们能根据配置执行于 1 到 2 个虚拟机上。针对每个功能特征，我们使用开发环境（能同时运行 6 个）驱动从 PM 和用户那所获取的验收标准。在 Sprint 中，验收服务器会在我们自己的数据中心中运行每个功能。当 Sprint 结束后，临时环境和预产品环境将通过 Puppet 程序自动更新。

InfoQ：你们是否有打算支持其它语言呢？如果是，那将是哪些？

TJ：目前就我看来，我们不可能支持太多的语言。在这里，我们有两个方向可以考虑：一是全新的语言，需要专门的构建和运行环境来执行；另外就是可以运行于 VM 的语言，类似那些执行于 JVM 的。如果单靠我们自己团队，有太多的环境需要支持，因此我们把社区引入进来。我们一直在努力完成内部所使用的 SDK，然后将其发布出去，这样大家就能创建自己的扩展和插件。它的架构和 Eclipse 插件相符，只会更广泛一点。Codenvy 内部是个完整的构建子系统和执行 Cloud Foundry 的运行环境。因此，如果开发人员想往系统中添加新语言，比如：C，就需要添加常用的 IDE 部件（文档、语法、调试、重构和宏）。同时也需要给 Codenvy 相应指令去操作构建系统（make）和运行环境。

我们的首要任务就是将该 SDK 发布出去，而这将是在今年；随后，我们的第二个重点是将围绕不同框架和语言的社区组织起来。我们也有来自外部的人有兴趣参与到 C、C++，Objective C、Go、Scala、Plan 等语言中。

InfoQ：那对框架 /PaaS/CI 的支持呢？

TJ：在每个 Sprint 中我们都尝试添加新的东西。我们执行为期两周的 Sprint，因此这方面的列表总是在变化。之所以 Codenvy 这么快能走红，是因为我们有个广泛的集成，而且也没有放缓的倾向。我们最新列表也是广泛分布的。我们为 GitHub、Bitbucket、AWS、Google App Engine、Heroku、Cloud Foundry、OpenShift、CloudBees、Tier3 和 AppFog 所提供的高度支持，感到非常自豪。我们也刚刚完成大概 10 个 git 供应商的认证，因此我们将更新所有规范和 how-to，以更好地与各供应商协作。

对于 CI 的支持，我们启用了 post-comment hooks，以及让 Web Service 直接调用 CI 供应者。

InfoQ：该 SDK 提供了什么？我理解是开发人员能够自己添加语言或平台。还有该 SDK 将在什么时候发布？

TJ：该 SDK 提供了一个 API 用于编写分层拓展；一个 API 用于分离 UI、数据（文档）和事件模型，以便单独考虑；API 文档；一组插件实例，比如我们给 Java 所设计的那样；一个专门的 SDK 云允许开发人员上传插件测试。插件本身将通过 Java 和 GWT 来编写。除非是在开发模式下运行，否则 GWT 需要 11 分钟编译。我们打算让 GWT 为 Codenvy 设置一个开发模式，但是从简化创建流程的最初目的上看，我们需要开发人员上传插件到 Codenvy 的伙伴云中，在那里我们可以编译、打包以及集成到运行时中。

该 SDK 云的最初版本会发布于 2013 年夏天。我们已经签订了好几个 ISV 合作伙伴，他们对此非常期待，因此这是我们内部的最高优先级。

在首次发布后，我们将创建 Codenvy WAR 文件包。这样开发人员就可以在 Tomcat 中运行 Codenvy 的单服务器版本，同时本地构建和发布插件。该版本将会有点棘手，因为它没有包含对运行器的支持。由于我们使用的是 Clound Foundry 执行运行器，目前为止还没有找到一个简单的方法将运行器包装到单服务器模式。我们将允许开发人员映射他们的“云运行器”到 Tomcat 中运行来处理 localhost 系统。因此如果在 localhost 的浏览器中执行“Run”，也将触发你在同一机器中所定义的进程命令。

InfoQ**：Codenvy能离线工作吗？如果不能，你们的计划是什么？**

TJ：我们不支持离线工作。在某种程度该话题本身就能成为一个初步招股说明书（a red herring）。从 UserVoice 获知，该特性是排名第 4 或第 5 个大家所需要的。但是当我们询问开发人员他们为什么需要这个特性时，答案却每个都不一样。有些人担心飞机旅行，需要完全离线；而有些则考虑如果只有部分网络访问能力的话，情况会怎么样；但大部分人并不认为如果没有该功能会是个大问题，而提出该需求本身也是件非常自然的事。

提供离线支持的一部分在于决定哪些可以离线。我们可以很容易地提供一个文本编辑器，但不会有对 Git 指令、构建、调试、运行或部署的支持。因此，从最基本层面看，初始阶段允许开发人员离线时有个只读模式是有一定道理的。而这在将来也非常容易做到。除此之外，不同层次的离线功能将取决于你是否可以或愿意允许在客户端安装它们。如果系统完全基于浏览器，那么我们可以同步 Git 代码库，并提供编辑功能。如果允许我们在桌面上安装软件，那么我们也可以在本地创建一个完全同步的构建和运行器。

在这方面，我们还在评估哪方面是我们想做的，并希望与社区进行更多的讨论。

InfoQ：你能就 Codenvy 对 JRebel、Rally Dev 和 Tasktop 的集成上提供更多的细节吗？

TJ：为协调 Java 工程我们提供了 JRebel。首先建立一个单一且永久的运行器，然后在生成器和运行器集群间激活 JRebel。

我们会在今年年底讨论我们将为 Rally 和 TaskTop 做哪些工作。

InfoQ：目前只有社区版是可用的。你们打算什么时候推出其它已经宣布定价的版本呢？

TJ：其实，我们已经有一些付费服务可供出售。现在，我们为那些个人使用者提供了“早期采用者项目”，并提供 66% 的折扣。随着时间的展开, 我们对于在每一个版本中增加的高级特性更有自信, 价格将会逐年增加.

InfoQ：企业版将包含什么？

TJ: Codenvy 企业版将会是一个安装在防火墙后能管理大量开发者的云系统. 迄今为止使用的客户都是那些有监管，合规，安全，外包管理需求的. 企业版除了包含公共云的特性之外还加入了一些特殊功能: a) LDAP(轻量级目录访问协议)& 认证集成,b) 集群, 负载均衡, 和高可用性策略控制, 和 c) 分析和汇报以衡量采购，参与度，以及开发团队、工作空间和项目的活力。现在，客户们自己提供硬件，然后在 Tier3、AWS、Eucalyptus 或 OpenStack 上运行 Codenvy Enterprise。

有趣的是，很多 Codenvy Enterprise 的早期使用者并没有把它当作 Eclipse 的替代品。相反，它被作为一个辅助的系统。很多情况下，我们会替换离岸开发人员运行缓慢的 VDI 或 TS 环境。在其他情况下，当花时间在有限窗口下编程比学会如何配置开发环境更重要的时候，我们正在变成新员工、实习生或合作伙伴的培训基地。就算作为辅助使用，开发人员还是可以推广自己的云，只是他们需要自己负责管理桌面，并让 IT 负责管理 Codenvy。

InfoQ：对于将来，你们有什么计划？

TJ：我们非常有幸拥有 30 个工程师在我们的开发团队。他们都是非常出色的系统工程师，在构建大而复杂的系统上有很丰富经验。我想这也正是他们的动力之源，促使他们开发设计出了大量能帮助开发人员自动化复杂工作流的项目。我们的精力将分散到以下这几个分类中：

1) 支持开发人员。更多的语言，更多的框架，更多的云集成和其他云服务将被引进。我希望在年底能集成 250 个技术到 Codenvy 中。此外，由于与 Trigger.IO 和 Google 的合作，我们已公开承诺将添加 Android 和 iOS 开发。

2) 支持独立软件开发商（ISV）。在第三季度，我们将交付各种 ISV 软件包，这样用户就能自定义模板，推广示例应用程序，以及内部构建 / 测量 / 跟踪开发活动。最终，我们希望所有 ISV 都能在线配置自定义的、按需的 IDE。这一点，在很多方面，需要结合他们在 SDK 方面的情况。

3) 支持企业。我们寻求更多的 POC，及在大企业中的安装。我们已经在一些大公司上完成安装，但是我们想再完成大概 25 个后，再宣称 Codenvy Enterprise GA。任何想自己运行开发云的公司，都可以联系我们，我们将非常荣幸。

关于被访者

Tyler Jewell是 Codenvy 的 CEO。同时也是 Toba Capital 的投资合伙人，他主要关注中间件和应用开发投资。他是 WSO2、Exo Platform 和 Codenvy 的董事会成员，同时也投资了 Cloudant、ZeroTurnaround、InfoQ 和 AppHarbor。

参考英文原文： The Technology behind Codenvy. An Interview with Tyler Jewell, CEO

感谢陈菲对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。