Getting software released to users is often a painful, risky, and time-consuming process.
Continuous Delivery can help large organizations become as lean, agile and innovative as startups. Through reliable, low-risk releases, Continuous Delivery makes it possible to continuously adapt software in line with user feedback, shifts in the market and changes to business strategy. Test, support, development and operations work together as one delivery team to automate and streamline the build, test and release process.
Continuous Integration is best described in a landmark article by our Chief Scientist, Martin Fowler. Originally one of the fundamental practices outlined in the Extreme Programming (XP) methodology, Continuous Integration (CI) has become an essential ingredient for teams doing iterative and incremental software delivery.
Continuous Delivery is the natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button. Continuous Delivery aims to make releases boring, so we can deliver frequently and get fast feedback on what users care about.
"Continuous Integration is a software development practice where members of a team integrate their work
frequently, usually each person integrates at least daily - leading to multiple integrations per day.
Each integration is verified by an automated build (including test) to detect integration errors as quickly as
possible. Many teams find that this approach leads to significantly reduced integration problems and allows a
team to develop cohesive software more rapidly."
Continuous Delivery (CD) is a concept that was first described in the eponymous 2010 book co-authored by ThoughtWorker Jez Humble and ThoughtWorks alumnus David Farley. CD provides a pattern language for the collection of software build, test and deployment activities that happen on the path to production. Further, CD references CI as a starting point, and extends it using lean philosophy and planning techniques that make it relevant to the greater business community. The goal of CD is to put customers in control of an ongoing cycle of software releases.
CI made its way to many delivery teams by way of open source software called CruiseControl, that was developed by ThoughtWorks in the year 2000. Since then it has spawned a wide market of development tools in the mainstream market. After many years of working with customers to construct deployment pipelines, ThoughtWorks developed Go as the first tool designed specifically for the practice of continuous delivery.
“Business knows all too well that slower and larger releases are buggy and unreliable. With Go we have frequent releases of smaller amounts of functionality. This avoids all the pressure, escalations, and rollbacks, while enabling reliable, predictable releases. They really see a value in this.”
Continuous Integration (CI) made its way to many delivery teams by way of open source software called CruiseControl, which was developed by ThoughtWorks in the year 2000. Since then CI has spawned a wide market of development tools in the mainstream market.
After many years of working with customers to construct deployment pipelines, ThoughtWorks developed Go as the first tool designed specifically for the practice of continuous delivery. It automates and streamlines the build-test-release cycle for worry-free, continuous delivery of your product. Go is now open source and free.
Snap lets teams get started with their continuous delivery journey in minutes. Powerful deployment pipelines wrap familiar continuous integration stages to provide fast feedback and control over the deployment process.