Master
ThoughtWorks
菜单
关闭
  • 产品及服务
    • 概况
    • "客户体验、产品及设计业务线 "
    • 数据战略、工程及分析业务线
    • 数字化转型及运营业务线
    • 现代化企业、平台及云业务线
  • 合作伙伴
    • 概况
    • 汽车企业
    • 医疗企业
    • 公共服务机构
    • 清洁技术,能源与公用事业
    • 媒体和出版业
    • 零售业和电商
    • 金融和保险企业
    • 非盈利性组织
    • 旅游业和运输业
  • 洞见
    • 概况
    • 特色

      • 技术

        深入探索企业技术与卓越工程管理

      • 商业

        及时了解数字领导者的最新业务和行业见解

      • 文化

        分享职业发展心得,以及我们对社会公正和包容性的见解

    • 数字出版物和工具

      • 技术雷达

        对前沿技术提供意见和指引

      • 视野

        服务数字读者的出版物

      • 数字化流畅度模型

        可以将应对不确定性所需的数字能力进行优先级划分的模型

      • 解码器

        业务主管的A-Z技术指南

    • 所有洞见

      • 文章

        助力商业的专业洞见

      • 博客

        ThoughtWorks 全球员工的洞见及观点

      • 书籍

        浏览更多我们的书籍

      • 播客

        分析商业和技术最新趋势的精彩对话

  • 加入我们
    • 概况
    • 申请流程

      面试准备

    • 毕业生和变换职业者

      正确开启技术生涯

    • 搜索工作

      在您所在的区域寻找正在招聘的岗位

    • 保持联系

      订阅我们的月度新闻简报

  • 关于我们
    • 概况
    • 我们的宗旨
    • 奖项与荣誉
    • 多元与包容
    • 领导层
    • 合作伙伴
    • 辅助功能
    • 新闻
  • 联系我们
China | 中文
  • United States United States
    English
  • China China
    中文 | English
  • India India
    English
  • Canada Canada
    English
  • Singapore Singapore
    English
  • United Kingdom United Kingdom
    English
  • Australia Australia
    English
  • Germany Germany
    English | Deutsch
  • Brazil Brazil
    English | Português
  • Spain Spain
    English | Español
  • Global Global
    English
博客
选择主题
查看所有话题关闭
技术 
敏捷项目管理 云 持续交付 数据科学与工程 捍卫网络自由 演进式架构 体验设计 物联网 语言、工具与框架 遗留资产现代化 Machine Learning & Artificial Intelligence 微服务 平台 安全 软件测试 技术策略 
商业 
金融服务 全球医疗 创新 零售行业 转型 
招聘 
职业心得 多元与融合 社会改变 
博客

话题

选择主题
  • 技术
    技术
  • 技术 概观
  • 敏捷项目管理
  • 云
  • 持续交付
  • 数据科学与工程
  • 捍卫网络自由
  • 演进式架构
  • 体验设计
  • 物联网
  • 语言、工具与框架
  • 遗留资产现代化
  • Machine Learning & Artificial Intelligence
  • 微服务
  • 平台
  • 安全
  • 软件测试
  • 技术策略
  • 商业
    商业
  • 商业 概观
  • 金融服务
  • 全球医疗
  • 创新
  • 零售行业
  • 转型
  • 招聘
    招聘
  • 招聘 概观
  • 职业心得
  • 多元与融合
  • 社会改变
持续交付技术

Go Goes Open Source

Jez Humble Jez Humble

Published: Mar 4, 2014

ThoughtWorks has long been associated with continuous integration. In 2000 we began using it on a large project and Matt Foemmel wrote what we think was the first CI server to help make it easier. Other people wanted the tool and through a complicated process of idea-sharing and dragging code across the US we ended up creating CruiseControl, the first publicly available CI server.

Since we weren't into products at the time, we released it as free software where it spread rapidly, breeding sister tools for .NET and Ruby. CruiseControl did a lot to popularize the idea of continuous integration, a remarkably powerful practice that improves software quality and helps teams get rid of non-value-add activities such as stabilization, integration and testing phases.

In 2007, while working at ThoughtWorks India, I was riding my motorbike home from our Bangalore office when I got a call from Roy Singham, our founder. He wanted to know if I was interested in moving to China and starting up a new product for ThoughtWorks Studios aimed at helping enterprises adopt continuous integration. We convened a team in Xi’an, China to share our experiences doing continuous integration at scale and coming up with a vision for the tool.

We decided to build an easy-to-manage product that could run complicated multi-step build, test and deployment processes seamlessly across large server farms, providing visibility into the production-readiness of software projects for large and distributed teams. Ultimately we wanted to create a product that could scale to serve a large IT group.

The Go Team at ThoughtWorks Beijing
The Go Team at ThoughtWorks Beijing

After spending a few months working off the CruiseControl codebase in our Beijing office, we realized in December 2007 that its architecture would not support the way we wanted to implement grids and the build, test and deployment workflow. We were also not getting enough revenue to support our original business model of using paid consulting work to support the development of an open-source tool. Thus, we pivoted. We decided to create a new tool and build a commercial product business around selling licenses.

We set ourselves a target to have our new product self-hosting so it could build and re-deploy itself by Chinese New Year: February 7, 2008. Using the existing CruiseControl codebase as the platform for the build agents, we created an entirely new server component from scratch, using Spring, Velocity, iBatis and Hypersonic. At this point we needed to find a customer. Fortunately we had -- just one desk over in our Beijing office -- a busy offshore project with around 30 developers who were happy to use our fledgling product as their CI server.

Supporting a project in full flight with its own deadlines had something of a nightmarish quality. Nearly every day we'd get some urgent request for a feature or reports of problems with something we were in the middle of developing. But the benefit was we had constant feedback from exactly the kind of team we wanted the product to support. This kind of close working relationship with your customer is a principle we regularly push for in our project delivery work, and we find it makes a big difference.

Cruise 1.0, as our product was then known, was released for the first time on July 27 2008. It was the first CI and release management product designed around the concept of deployment pipelines, a pattern that forms the central plank of continuous delivery (although the model we use in the product is by no means the only way of modeling a deployment pipeline).

Subsequent releases saw the product grow in terms of both features and is ability to support large build farms and multiple, large teams. Our 2.0 product, renamed Go, included the ability to run a large suite of acceptance tests across the grid and report back which tests are currently breaking and which check-in broke them, a unique capability in a commercial CI tool at the time. We also modeled the concept of multi-server environments to allow you to see and control what was in every test and production environment under Go’s control.

Over time the Go team changed, moving from Beijing to San Francisco to Bangalore. We also re-architected the software, using branch-by-abstraction to change both the UI stack and the persistence layer while continuing to release the product.

The Go Team at ThoughtWorks Bangalore

Around this time the Continuous Delivery book came out and took off, and I bowed out from active involvement in the product, although I was delighted to see later releases add unique features such as the ability to visualize your value stream from check-in through to release, as well as making it easier to manage large grids and multiple large projects.

Despite all of this innovation, we feel that Go has not done enough to support our wider goal: to revolutionize software development by making continuous delivery standard practice throughout the industry. Thus I’m thrilled to hear that, as of today, Go will be free open source software (as in freedom).

ThoughtWorks will continue to provide commercial support for the product. We’ll also be developing commercial plug-ins for it. Most important, the Go team will continue to be active in supporting its development and the community around it.

I’d like to thank all of our users and customers for their support over the last five years. I’d also like to salute all the people I was privileged to work with on the Go team: Many of the ideas that went into the Continuous Delivery book came out of our discussions.

Download the tool and try it out, and please do give us your feedback.

\

Master
政策声明 | 现代奴役声明 | 辅助功能
Connect with us
×

WeChat

QR code to ThoughtWorks China WeChat subscription account
© 2021 ThoughtWorks, Inc.