CI/CD Tools History and Timeline - Trademarks, Acquisitions, Foundations, and Where the Build Runs

First Published: 2026-09-07
Last Updated: 2026-09-07

When inheriting a pipeline built by someone else, the first question that comes to mind is, "Why this configuration?" Why is it still using Jenkins? Why are only the builds moved to the repository? Why did the migration plan stall midway through several years ago? Feature comparisons of tools will not answer this question. The answer lies in who owned the tools.

This article explores the history and timeline of the category of CI/CD tools. Many of the earlier timelines in this series follow a single service or a single company's products. This article, however, addresses a category that spans multiple organizations.

The history of this category has a distinct characteristic. When you examine the points where the lineage breaks, it becomes clear that the driving force behind these shifts is not technology. It is not that tools were replaced because they became faster or gained new features. Instead, the changes are driven by who holds the name, which company acquired which, which organization manages the assets, and when the terms of availability are altered. At those moments it is almost always one of these four.

Where the Build Runs - From Your Own Server to the Repository

Another pattern emerges only when viewed through the lens of a timeline: the location where the builds run. Initially, these were servers built and maintained by the teams themselves. Then the code hosts began to own that machine. This shift did not happen in a single announcement. It is the result of several code hosts moving in the same direction over several years.

This article does not rank the tools. It does not say which is better or which one to migrate to. It also avoids judging the decisions made by companies or communities. Instead, it focuses on documenting what primary sources stated and when. Recording the order of events is different from making judgments about their quality. Furthermore, where an official source gives no reason, this article does not supply one.

All information presented in this article was verified as of 2026-09-06.

Related articles on hidekazu-konishi.com:

Background and Method of Creating the CI/CD Tools Timeline

What Counts as a Turning Point Here

This timeline is not exhaustive. There are dozens of CI/CD products, and listing every version and feature would not explain the shape of an inherited pipeline. Only four kinds of rows are included:

Category Shifts: Entries where the fundamental nature of the tool itself changed. Announcements regarding changes in the execution environment fall under this category.
Lineage Changes: Entries where a single product split into two, had its name changed, or moved under a different organization.
Changes in Availability: Entries where new customer sign-ups stopped or resumed, where a product moved to maintenance only, or where a final version shipped.
Changes in What Is Required of CI: Entries where the requirements placed on a tool changed rather than the tool itself. Entries where the practice was given a definition in writing, and entries where requirements for the supply chain were set out externally, fall under this category.

Rows that record only a feature addition are excluded as a rule. The feature histories for each product can be found in their respective official release notes and changelogs. The exception is a feature addition that moved where the execution environment sits. An example of this is August 8, 2019, when GitHub Actions gained support for CI/CD.

The Primary Sources This Article Used

Every row carries the URL of its primary source. The following categories were utilized:

Official Websites and Blogs of the Projects — jenkins.io, cd.foundation, slsa.dev, eclipse.org
Vendor Official Blogs and Changelogs — github.blog's changelog, Microsoft's official blog and Microsoft Learn, Travis CI's blog, and press releases from ideracorp.com.
Source Repositories Themselves — tags and repositories on gitlab.com, and API documentation from javadoc.jenkins.io. In cases where announcement pages were unavailable, existing deliverables were used instead.
Foundation Announcements — press releases from the Linux Foundation and the Cloud Native Computing Foundation.
AWS Documentation and Official Blogs — document history for each service, AWS News Blog, AWS DevOps Blog, and What's New.

⛔ Secondary media and summary articles were not considered primary sources. This category has a large volume of secondary articles, and many of them round off the lifecycle state. For lifecycle state in particular, this article takes the wording the official source uses, as set out below.

Why the Date Precision Differs from Row to Row

The level of date precision varies from row to row. Some rows only specify the month, others only the year, and some contain discrepancies between different primary sources. This article does not use estimations to improve accuracy.

Rows specifying only the year: These include the initial release of CruiseControl and the founding of Travis CI. Both are based on primary sources that only state the year.
Rows with conflicting years: The launch of Hudson, for example, is documented with two different years (2004 and 2005) by the project's own records. This article does not choose one over the other, but instead notes the discrepancy in the row.
Rows with discrepancies between primary sources: This applies to the re-opening of AWS CodeCommit. The official blog post and the document history list dates that differ by one day. The row indicates which date was chosen.

⚠ What could not be verified is left out rather than hedged. Neither the date on which Hudson became an Eclipse Foundation project nor the date on which that project was archived could be confirmed from Eclipse's own pages. Therefore, this article lists the earliest verifiable release date and the final verifiable release date in two separate rows.

⛔ There is one row where the dates within a single primary source conflict. The article on Continuous Integration dates the original version to 2000 in its revision history, while its main text says 2001. This article uses the date from the revision history and notes the discrepancy in the row.

When a Vendor's Own Announcement Stops Resolving

⚠ During the creation of this article, instances were found where the primary source itself was missing. The announcement for GitLab 8.0 now redirects from the originally published URL to a release list page, making it impossible to trace back to the original article. This article is therefore constructed from existing primary sources: tags in the source repository and a retired, standalone repository.

⚠ Additionally, one primary source is inaccessible for automated retrieval. The Sun Microsystems Form 8-K can be viewed in a browser, but does not respond to attempts to retrieve it programmatically. Nothing that could be verified has been dropped merely because it is hard to fetch.

These two issues are unavoidable aspects of working with this category. A page that states a specification and a page that records an event have different lifetimes. The latter is subject to being reorganized and removed without notice, at the vendor's discretion.

The Trigger Column

Each row in the timeline carries a Trigger column that names what moved that row. This column is the heart of the article. Six values are used, and only the first four of them stand at a break in the lineage. Launch and Practice mark rows that are here for a different reason: they record where the execution environment sits, and what came to be required of CI.

Trademark — Rows related to changes in or decisions regarding trademark rights.
Acquisition — Rows indicating a change in company ownership.
Foundation — Rows documenting the transfer of assets or governance under a foundation.
Lifecycle — Rows detailing changes in the product's status, including the cessation and resumption of new customer sign-ups, transition to maintenance, and the final version.
Launch — Rows marking the introduction of a product or feature. Only those that bear on where the execution environment sits are included.
Practice — Rows indicating a change in requirements or expectations for a tool, rather than a change to the tool itself.

What This Article Leaves to Other Articles

This article focuses solely on historical context and timelines. The following topics are covered in other articles, and this article will only include timeline entries and delegations of responsibility.

GitHub Actions Configuration and Hardening — Information on permissions, trigger security boundaries, and action pinning can be found in Hardening GitHub Actions for AWS Deployments. This article does not cover how to write GitHub Actions workflows.
Details of AWS Service Retirement — A list of new service acceptance end dates and resumption dates, service status classifications, and the AWS retirement process itself are detailed in AWS Retired Services History and Timeline. This article only briefly mentions AWS Code services as a line within a broader historical overview.
Implementation of Signatures and Provenance — The design of SBOMs, attestations, and admission control is covered in Software Supply Chain Security on AWS. This article only includes a timeline entry describing "what became required in CI," without detailing any implementation.
Details of Supply Chain Incidents — Information on individual vulnerabilities and the dates of specific incidents can be found in Major Security Vulnerabilities History and Timeline.
Running Agents in CI in an Automated Fashion — Claude Code in CI/CD and Headless Automation provides details on this topic.
The Lineage of Infrastructure as Code Tools — The branching of Terraform and OpenTofu, and the analysis of the license changes themselves, are covered in Terraform and OpenTofu History and Timeline.
The Lineage of Observability Tools — Information on the foundation's integration efforts and a general overview of what the foundation is, can be found in Observability and OpenTelemetry History and Timeline. This article describes only what a foundation did for specific CI/CD projects.

⛔ This article does not include pricing or free tier details. While the article will include events related to changes in service terms in the timeline, it will not include specific pricing information. Instead, it will only document the structural changes to those terms.

CI/CD Tools Historical Timeline (Updates from September 10, 2000)

The following is a timeline of tools categorized as CI/CD, presented in ascending order. Each row carries a URL to its primary source.

Use the following index to navigate to specific years:

2000 - The practice is given a name in writing.
2001 - CruiseControl is released.
2004 - Hudson begins development within Sun.
2006 - The definition of the practice is rewritten.
2010 - Sun's acquisition is completed, and the original author leaves the company.
2011 - A trademark breaks the lineage, and a vote changes the name.
2013 - One line ships a version through the Eclipse Foundation.
2014 - Cloud providers begin offering their own CI/CD solutions.
2015 - Code hosts begin bundling the execution environment.
2016 - "Pipeline as code" becomes standard, and one line ships its final version.
2018 - A code host changes owner, and the execution environment becomes standard equipment.
2019 - A foundation is established, an acquisition takes place, and Actions becomes part of the CI/CD landscape.
2021 - The trademark is transferred to the foundation, and the original domain is discontinued.
2022 - The two GitOps projects graduate.
2023 - Build provenance gets a version number.
2024 - Provenance becomes a standard feature, and one product closes to new customers.
2025 - The terminology related to the provision status is refined, and one suspension is lifted.
2026 - Current status.

2000-2010 - The Build Server Was Yours to Run

During this period (2000-2010), the team was responsible for the build server. Someone would set it up, and someone else would maintain it. The vocabulary of the category settled, the first tools appeared, and then ownership changed hands.

Date	Project	Trigger	Summary
2000-09-10	`-`	`Practice`	Martin Fowler published an article on Continuous Integration. The currently published version records `10 September 2000: Original version published.` in the `Significant Revisions` section. However, the main text of the same page says `I originally wrote this article in 2001, with an update in 2006.`, so the year of the original version disagrees with the revision history. This row records the discrepancy, using the date from the revision history. The current page, published on 2024-01-18, is a revised version and not the original from 2000. References: Continuous Integration
2001	`CruiseControl`	`Launch`	CruiseControl was released. The project page states `The original CruiseControl source code was contributed by ThoughtWorks`, and now indicates that it is `developed and maintained by a group of dedicated volunteers`. The license is `a BSD-style license`. Due to a lack of primary sources specifying the month of the initial release, this row only includes the year. The tool was originally designed to run on servers set up by the users themselves. References: CruiseControl Home / Open-Sourcing Thoughtworks Go
2004/2005	`Hudson`	`Launch`	Hudson was started by Kohsuke Kawaguchi while he was at Sun Microsystems. The exact year of the launch is unclear, according to the project's own records. An article from 2010 on jenkins.io states, `started Hudson in 2004/2005`, citing Kawaguchi's own statement. This row will reflect this ambiguity, rather than selecting a single year. That the product was built inside Sun became the basis for breaking its lineage seven years later. References: Live Blog: Kohsuke's Presentation at JavaOne
2006-05-01	`-`	`Practice`	The Continuous Integration article was completely rewritten. The revision history records, `01 May 2006: Complete rewrite of article to bring it up to date and to clarify the description of the approach.` The current definition is: `Continuous Integration is a software development practice where each member of a team merges their changes into a codebase together with their colleagues changes at least daily` This definition comes from the 2024 revision. It is not the 2006 wording. References: Continuous Integration
2010-01-26	`Hudson`	`Acquisition`	Oracle completed its acquisition of Sun Microsystems. Sun's Form 8-K filing with the U.S. Securities and Exchange Commission records that `On January 26, 2010, pursuant to the terms of an Agreement and Plan of Merger`, `Oracle completed its acquisition of Sun`. The agreement itself was publicly announced on 2009-04-20. As a result, the rights to the products created within Sun were transferred to Oracle. At this point, this row does not directly relate to CI tools. It would become relevant one year later. The 8-K filing used as a source does not allow for automatic retrieval; a browser is required to view it. References: Sun Microsystems, Inc. Form 8-K / Oracle Buys Sun
2010-04-16	`Hudson`	`Acquisition`	Hudson 1.354 was released. The project's blog describes this release as `the first release of Hudson ever made by a not-employed-by-Sun Kohsuke`. This is the first release after the author left the company that had been acquired. This row marks a change of employer only. The right to the name had not moved yet. The article also notes that practical adjustments related to this transition affected the release schedule. References: Hudson 1.354 Released

2011-2014 - A Trademark Splits the Line

The most-cited event in this category happened in three weeks of January 2011. The point at issue was not features and not design. It was the name. Where each of the two split lines went next also falls in this stretch.

Date	Project	Trigger	Summary
2011-01-11	`Hudson`	`Trademark`	A proposal to rename the project was put forward publicly. The article records Oracle's position as `Oracle has told us that they have trademark applications filed in both the EU and US for Hudson, based on Hudson's creation by Kohsuke while working at Sun`. The proposal itself reads `First, we rename the project - the choice for a new name is Jenkins, which we think evokes the same sort of English butler feel as Hudson`. ⛔ The point at issue is the trademark, not a difference of technical opinion. The article also poses the question of whether this is a fork or a rename, and answers it itself with `I firmly believe we are proposing the latter - for me, the project's key component is Kohsuke himself`. ⚠ The article does not state Oracle's motivations, and this article does not provide that information either. References: Hudson's future
2011-01-29	`Jenkins`	`Trademark`	A vote decided the rename. The article records the result as 214 to 14, indicating a clear majority in favor of the change. Furthermore, the same article notes that more than half of the total votes were cast by participants who did not have voting rights. Following this, the article lists the various assets being renamed, including mailing lists, social media accounts, and repository organization names. At this point, the intended trademark holder was different from the actual holder that later emerged. The proposal from 2011-01-11 had suggested registering the project under the author's name and then transferring it to Software Freedom Conservancy. References: Jenkins!
2011	`Travis CI`	`Launch`	Travis CI was launched. The current official website states, `Empowering Developers Worldwide Since 2011`. A press release from the time of acquisition describes the product as `Founded in 2011 and headquartered in Berlin` The primary source only mentions the year, so this article will retain that level of precision. The product gained popularity as a hosted CI service, eliminating the need for users to set up their own servers. This marked a shift in the location of the execution environment, moving from the user's side to the provider's side. References: Empowering Developers Worldwide Since 2011 / Idera, Inc. Acquires Travis CI GmbH
2013-09-13	`Hudson`	`Foundation`	Eclipse Hudson 3.1.0 was released. This is the first version recorded on the Eclipse Foundation's project page. Of the two lines that split in 2011, the one that kept the name Hudson carried on as an Eclipse Foundation project. It was not possible to determine from the public page when the project officially became part of the Eclipse Foundation, so this article uses the first available release date as the record. The Eclipse Foundation's handbook does not allow a project to arrive holding its own trademark, so the name is assigned to the Foundation. References: Eclipse Hudson / Eclipse Project Handbook
2014-11-12	`AWS Code`	`Launch`	AWS announced the launch of three developer-focused services simultaneously. These are AWS CodeDeploy, AWS CodeCommit, and AWS CodePipeline. ⚠ The three did not become usable on the same day. The announcement stated, `We are launching AWS CodeDeploy today and you can start using it right away`, while indicating that further announcements would be made regarding the other two services. This was the first move by a cloud provider to line up the code host, the build, and the deployment inside its own platform. References: New AWS Tools for Code Management and Deployment

2015-2018 - The Runner Arrives With the Repository

Over these four years, the location of the execution environment moved. Code hosts began to bundle the machine that runs the build, the runner. Multiple vendors were performing similar actions independently.

Date	Project	Trigger	Summary
2015-07-09	`AWS Code`	`Launch`	AWS CodeCommit became generally available. Approximately 8 months after its announcement at the previous year's re:Invent. It was presented as a managed service for hosting Git repositories. ⚠ The status of this service changes twice, nine and ten years later. References: Now Available - AWS CodeCommit
2015-07-09	`AWS Code`	`Launch`	AWS CodePipeline became generally available. It was released on the same day as CodeCommit. The announcement stated that Amazon had previously implemented a similar feature internally. Releasing both products on the same day created an option for users to manage their code from storage to release within a single provider. References: Now Available - AWS CodePipeline
2015-09-22	`GitLab`	`Launch`	GitLab 8.0 was released. The source repository's `v8.0.0` tag records this date. With this release, GitLab CI, previously a separate application, was integrated into the core product. The repository for the previously independent CI server was created on 2013-10-10 and is now marked as `DEPRECATED - Continuous integration server for gitlabhq`. ⛔ This is a turning point for the category. Users no longer needed to use a separate application to view the status of tests and deployments. This is the first clear example of a code host bundling the execution environment. The announcement itself for this release is no longer traceable. The 2015 article on `about.gitlab.com` now redirects to the release index, so this row cites the tag and the deprecated repository instead. References: GitLab FOSS tag v8.0.0 / GitLab CI (deprecated repository)
2016-04-26	`Jenkins`	`Launch`	Jenkins 2.0 was released. The core feature was "Pipeline as code," allowing users to define automated workflows as text. The announcement highlighted this benefit, stating, `This allows you to version control it, put it alongside your source tree, etc.` Similarly, those using self-hosted servers began moving toward placing pipeline definitions alongside their code. The initial setup experience and security defaults were also updated, maintaining backward compatibility with existing installations. References: Jenkins 2.0 is here!
2016-09-02	`Hudson`	`Lifecycle`	Eclipse Hudson 3.4.0 was released. This was the last release recorded on the Eclipse Foundation's project page. ⚠ The current status of the project is `Archived`, but the page does not specify the date the project was archived. Therefore, this row designates the last verifiable release date as the relevant point. Of the two lines that split in 2011, this is where one of them stopped shipping versions. References: Eclipse Hudson
2016-12-01	`AWS Code`	`Launch`	AWS CodeBuild was announced. The announcement specifically identified the burden of maintaining shared build servers as a problem. ⛔ This line gains additional meaning when viewed through the lens of "execution environment location." The point of the announcement was not speed or features. It was that users no longer had to provision a build machine. References: AWS CodeBuild - Fully Managed Build Service
2018-06-04	`GitHub`	`Acquisition`	Microsoft announced its agreement to acquire GitHub. Completion was expected later that same year. At this point, GitHub did not have a CI/CD product. The completion of the acquisition and the inclusion of an execution environment occurred in a series of events over the following 5 months. References: Microsoft to acquire GitHub
2018-09-10	`Azure DevOps`	`Launch`	Visual Studio Team Services was renamed to Azure DevOps and divided into five services, one of which was Azure Pipelines. This was a renaming, not a deprecation. Furthermore, the ability to define build pipelines using YAML files placed within repositories became widely available. This is a different vendor moving independently in the same direction as GitLab. References: Introducing Azure DevOps
2018-10-16	`GitHub`	`Launch`	GitHub Actions was announced as a limited public beta. ⛔ At this stage, Actions was not a CI/CD product. The announcement began, `GitHub Actions allows you to connect and share containers to run your software development workflow`, and explained that users could build and deploy projects `on GitHub or any external system-without having to run code yourself`. The announcement did not mention continuous integration or continuous delivery. Notably, the announcement emphasized that users would not need to provision their own execution environment, which was the selling point at this time. Support for CI/CD was a feature of a later announcement. References: GitHub Actions (limited public beta)
2018-10-26	`GitHub`	`Acquisition`	Microsoft's acquisition of GitHub was completed. The announcement stated that GitHub would continue to operate independently as both a community and a business. ⚠ This row does not claim a causal relationship between this acquisition and the launch of Actions, which began 10 days earlier. Publicly available documentation does not explicitly connect the two. References: Microsoft completes GitHub acquisition

2019-2022 - Foundations Take Custody of the Names

What stands out across these four years is that assets and names moved from individuals and single companies to foundations. During the same period, there were also significant changes in ownership resulting from acquisitions, and the culmination of efforts to integrate execution environments within repositories.

Date	Project	Trigger	Summary
2019-01-23	`Travis CI`	`Acquisition`	Idera acquired Travis CI. The press release stated that Travis CI would be added to the company's Testing Tools division. Travis CI itself published an article stating that it would continue to be offered as an independent product, maintain free hosting for open-source projects, and continue to publish its code under the MIT license. ⚠ This row does not draw a causal relationship between the initial statement and subsequent events; both should be considered as separate entries with their respective dates. References: Idera, Inc. Acquires Travis CI GmbH / Joining the Idera Family
2019-03-12	`CDF`	`Foundation`	The Linux Foundation announced the establishment of the Continuous Delivery Foundation. The announcement states `The first projects to be hosted by the CDF will include Jenkins, an open source CI/CD system, Jenkins X, an open source CI/CD solution on Kubernetes, Spinnaker, an open source multi-cloud CD solution, and Tekton, an open source project and specification for CI/CD components`. ⛔ This is the first entry in this category where a neutral home was set up to hold CI/CD projects. The announcement positions the CDF as `a new foundation for the diverse continuous integration and delivery (CI/CD) space`. The explanation of what a foundation is as a mechanism belongs to Observability and OpenTelemetry History and Timeline, so this article defers to it. References: The Linux Foundation Announces New Foundation to Support Continuous Delivery Collaboration
2019-08-08	`GitHub`	`Launch`	GitHub Actions added support for CI/CD. The announcement states that nearly every request received since the previous announcement had asked for CI/CD. Support was added for hosted execution environments for Linux, macOS, and Windows, as well as the ability to display execution logs. ⛔ This is where the movement of the execution environment into the code host arrives. The largest code host followed the direction GitLab had taken in 2015 and Azure DevOps in 2018. References: GitHub Actions now supports CI/CD
2019-11-13	`GitHub`	`Launch`	GitHub Actions became generally available. The date corresponds to a previous announcement that stated, `We hope you'll try out the beta before GitHub Actions is generally available on November 13`. This follows approximately 13 months since the initial beta announcement and approximately 3 months since the announcement of CI/CD compatibility. References: GitHub Actions now supports CI/CD
2021-02-24	`Jenkins`	`Trademark`	The Jenkins trademark was transferred from Software in the Public Interest, Inc. to LF Charities, Inc., a subsidiary of the Linux Foundation. The project's trademark page states `The name "Jenkins" is a registered trademark in the USA to protect the project and users from confusing use of the term: #4664929, held by LF CHARITIES, Inc.`, and its change history records this date as the transfer date. ⛔ The 2011 proposal named Software Freedom Conservancy as the recipient, but the organization that actually held it for years was Software in the Public Interest. Secondary articles sometimes get this wrong. ⇒ The very trademark that broke the lineage came to rest with a foundation ten years later. References: Jenkins Trademark and Attribution / Jenkins Governance Document
2021-05-07	`Travis CI`	`Lifecycle`	An announcement was made regarding the shutdown of travis-ci.org. The article explained that this was the final stage of a process that began in 2018, aimed at integrating all domains into a single domain, with a target date of May 31, 2021. ⚠ Build logs and configuration were to stay accessible in read-only form after the shutdown, so this was not the end of the service. ⛔ This row focuses solely on the change in terms for open-source users resulting from this integration, without detailing the specific numerical terms. References: Read About .Org Shutdown
2022-11-30	`Flux`	`Foundation`	Flux graduated from the Cloud Native Computing Foundation (CNCF) Incubator. According to the announcement, Flux was accepted into the CNCF on 2019-07-15, moved to Incubating on 2021-03-12, and reached the Graduated stage on this date. The graduation criteria included the public nature of governance, broad adoption, and third-party security reviews. References: Flux Graduates from the Cloud Native Computing Foundation Incubator
2022-12-01	`AWS Code`	`Launch`	Amazon CodeCatalyst was announced in preview. It was presented as an integrated development service that combines planning, coding, building, testing, and deployment. ⚠ The preview was offered in one Region only. References: Announcing Amazon CodeCatalyst (Preview)
2022-12-06	`Argo`	`Foundation`	Argo graduated from the Cloud Native Computing Foundation (CNCF) Incubator. This occurred just six days after Flux's graduation. According to the announcement, Argo was created and released by Applatix in 2017 and entered the Incubator in April 2020. Two projects with similar purposes reached the same stage within a single week. ⚠ Both projects are associated with the CNCF, rather than the Continuous Delivery Foundation. One category thus holds projects sitting with different foundations. References: The Cloud Native Computing Foundation Announces Argo has Graduated

2023-2026 - Terms Move, and One Closure Is Undone

In these four years the rows are mostly about the terms of availability and the level of requirement, not about the tools themselves. And there is a row where new customer sign-ups, once stopped, are opened again.

Date	Project	Trigger	Summary
2023-04-19	`SLSA`	`Practice`	SLSA reached version 1.0. This is the first stable release of a framework that describes requirements for the supply chain in a phased manner, following approximately two years of work. This article does not describe the contents of this framework. The design of signing and provenance belongs to Software Supply Chain Security on AWS. This row marks a turning point where requirements for CI began to be provided externally. References: SLSA Version 1.0 is Final
2023-04-20	`AWS Code`	`Launch`	Amazon CodeCatalyst became generally available, approximately four and a half months after its preview announcement. ⚠ The availability of this product changes again two and a half years later. References: Announcing the general availability of Amazon CodeCatalyst
2024-05-02	`GitHub`	`Practice`	GitHub Artifact Attestations entered public beta. This mechanism attaches provenance to artifacts within workflows, without users managing keys or public key infrastructures. ⚠ This row is here not as a feature addition, but as the point where a requirement placed on CI descended into the standard feature set of the product. References: Artifact Attestations public beta
2024-06-25	`GitHub`	`Practice`	Artifact Attestations became generally available, approximately two months after the public beta. ⛔ The design of where verification is enforced is outside the scope of this article. That belongs to Software Supply Chain Security on AWS. References: Artifact Attestations is generally available
2024-07-25	`AWS Code`	`Lifecycle`	AWS CodeCommit was closed to new customers. The service's document history states `AWS CodeCommit is no longer available to new customers. Existing customers of AWS CodeCommit can continue to use the service as normal.` ⛔ Service to existing customers continued. This is not a shutdown. ⚠ The decision recorded in this row is reversed sixteen months later. The list of retired AWS services and the classification of their states belongs to AWS Retired Services History and Timeline. References: AWS CodeCommit User Guide document history
2025-04-17	`GitLab`	`Launch`	GitLab Duo with Amazon Q became generally available. The date originates from an AWS migration guide, which states: `Customers can consider migrating to GitLab Duo with Amazon Q which announced General Availability April 17, 2025`. Read this row together with the row dated 2025-11-07. This represents a shift from a model where the cloud provider handles everything to one where it integrates with products from other companies. References: How to migrate from CodeCatalyst
2025-10-13	`AWS Code`	`Lifecycle`	AWS announced a batch of availability changes and set out three stages: Maintenance, Sunset, and End of Support. Regarding Maintenance, it states: `Services moving to maintenance will no longer be accessible to new customers starting Nov 7, 2025. Current customers can continue using the service or feature while exploring alternative solutions.` ⛔ These three are different states and must not be rounded into one. This announcement includes Amazon CodeCatalyst. References: AWS Service Availability Updates
2025-11-07	`AWS Code`	`Lifecycle`	Amazon CodeCatalyst was closed to new customers. The document history states `Amazon CodeCatalyst is no longer open to new customers. Existing customers can continue to use the service as normal.` The migration guide states that while existing users can continue using it, new spaces cannot be created, and while investments in security and availability will continue, no new features will be added. AWS uses `open` for this product and `available` for CodeCommit. The wording differs. This article preserves the wording used by AWS in each entry. This represents two years and eleven months from the preview and two years and six months from the general availability. References: Document history for Amazon CodeCatalyst / How to migrate from CodeCatalyst
2025-11-24	`AWS Code`	`Lifecycle`	AWS CodeCommit became generally available again. An AWS blog post states: `CodeCommit is returning to full General Availability, effective immediately`, and `New customer sign-ups are open as of today`. The document history records `AWS CodeCommit is now available to new customers.` as of 2025-11-25. There are two dates. This article takes the date from the blog and states the date from the document history alongside it. This row may appear contradictory to the row dated 2024-07-25, but both are correct. The same product has changed its status at different times for different reasons. The reading of this reversal belongs to AWS Retired Services History and Timeline. References: The Future of AWS CodeCommit / AWS CodeCommit User Guide document history
2026-01-20	`GitHub`	`Practice`	GitHub announced a mechanism that cryptographically binds an artifact to the repository and workflow it came from. The announcement states that this helps achieve SLSA Build Level 3. This row represents a shift from requirements defined as a framework in 2023 to a standard feature of the code host. References: Strengthen your supply chain with code-to-cloud traceability and SLSA Build Level 3 security
2026-09-02	`Jenkins`	`Lifecycle`	Jenkins LTS version 2.568.3 was released. This is the latest stable version as of the time of this article. The line that renamed itself in 2011 is still shipping versions fifteen years later. Please refer to the official changelog for the most up-to-date information on version numbers and dates. References: Jenkins LTS Changelog

Current Overview of How CI/CD Tools Are Governed Today

The Four Triggers That Have Actually Bent the Line

Of the six values in the Trigger column, four stand at a break in the lineage. None of the four is a technological shift.

The Four Triggers and the Years They Landed

Trigger	What Changes	Examples on the Timeline	What Can Be Gleaned from Primary Sources
`Trademark`	The right to use a name	Proposal for a name change on 2011-01-11, trademark transfer on 2021-02-24	The publicly visible name changes. On 2011-01-29, the article lists domains, mailing lists, social accounts, and the names of organizations within repositories as being subject to the name change.
`Acquisition`	Ownership of a company	GitHub on 2018-10-26, Travis CI on 2019-01-23	At the time of the announcement, continued service is stated. In both cases the announcement said the product would continue to run independently. ⚠ To understand what happened afterward, you need to refer to entries on the timeline with dates separate from the announcement.
`Foundation`	A recipient of assets and governance	CDF establishment on 2019-03-12, Flux and Argo graduation in 2022	Governance shifts from individual organizations to external entities. CNCF lists public governance and third-party security reviews as conditions for graduation.
`Lifecycle`	Service conditions	CodeCommit on 2024-07-25 and 2025-11-24, CodeCatalyst on 2025-11-07	New customer sign-ups and existing usage move independently. ⚠ As set out below, rounding off the official wording leads to migrations that were never needed.

⚠ These four triggers are independent of each other. A company can be acquired without a name change, and a name can change without the company changing. For Hudson in 2011, only the right to the name moved. The code, the author, and the place the work happened were continuous.

⇒ This is reflected in the current Jenkins code. Even after 15 years, the API documentation still lists classes under the hudson.model namespace. The name on the outside changed in 2011. The name inside the code did not. This one detail is what makes the claim concrete: it was a rename, not a fork. References: Project (Jenkins core API)

What a Trademark Does That a License Does Not

The 2011 case is still cited today because it showed that there are things a license cannot prevent.

Hudson's code was open source. Anyone could copy, modify, and redistribute it. Nevertheless, a proposal to change the name arose because the scope of a license and the scope of a name are different. A license permits the copying, modification, and redistribution of the code, but it does not decide what that code may be called.

What the proposal states is that Oracle had filed trademark applications, and that no permanent guarantee of keeping the name was available. ⚠ The article does not state what Oracle intended, and this article will not elaborate on that either.

When examining the established pipeline, this distinction carries practical significance. Simply verifying a license does not guarantee that the name of the tool will remain the same next year. Conversely, even if the name changes, there may be continuity between the code and its users.

Where the Build Runs, and Who Owns That Machine

Looking at the timeline, another trend emerges: the location of the machines where the builds run.

Initially, these were servers built by the teams themselves. Both CruiseControl and Hudson were designed with the assumption that they would run on these servers. Then, hosted CI solutions appeared, shifting the machines to the provider's side. And between 2015 and 2019, the code hosts themselves began to bundle the execution environment.

This shift did not happen in a single announcement from one company. GitLab moved in this direction on 2015-09-22, Azure DevOps on 2018-09-10, and GitHub on 2019-08-08, all independently moving in the same direction. AWS also lined up the code host, the build, and the deployment inside its own platform between 2014 and 2016.

⚠ The shift runs one way, but it is not complete. Jenkins continues to release LTS versions as of 2026, and running your own server has not gone away. The timeline shows that the center of gravity for choices has shifted, not that one option has been eliminated.

This axis can be useful when describing the shape of inherited pipelines. By looking at the year the pipeline was created and where the center of gravity for the execution environment was at that time, you can explain half of why it took that particular shape.

Reading a Lifecycle Notice Without Rounding It Off

The words used to describe a product's status can dramatically change meaning if taken out of context. This is the area most prone to misinterpretation.

AWS, in its announcement dated 2025-10-13, presents its categorization in three distinct groups.

Services moving to maintenance will no longer be accessible to new customers starting Nov 7, 2025. Current
customers can continue using the service or feature while exploring alternative solutions.

The same announcement lists Sunset as the stage where a migration window is open, and End of Support as the stage where service has ended. These three are not the same thing.

Furthermore, different vendors sometimes use different terminology for the same product. Examining the wording in the document history reveals the following.

AWS CodeCommit is no longer available to new customers.
Amazon CodeCatalyst is no longer open to new customers.

⛔ This article does not attempt to standardize these terms. When an article simplifies official terminology to use a single term, readers who go back to the primary source run into a mismatch.

Moreover, a product's status can sometimes be reversed. AWS CodeCommit stopped accepting new customer sign-ups on 2024-07-25, but then returned to general availability on 2025-11-24. These two entries may appear contradictory when viewed in a timeline, but both represent official records.

The practical implications of evaluating an inherited pipeline boil down to one key point: Do not take the single word ended at face value. Verify the current status, the date of the record, and what impact it has on existing users, by referring to the official documentation. Migration decisions should be made after that assessment.

Both Halves of the 2011 Split Ended Up Handing the Name to a Foundation

Tracing the timeline to its conclusion reveals that the two paths that diverged in 2011 arrived at the same place.

The line that renamed itself spent years with Software in the Public Interest holding its assets and governance, and then moved the trademark to a subsidiary of the Linux Foundation on 2021-02-24. The project's trademark page states:

The name "Jenkins" is a registered trademark in the USA to protect the project and users from confusing use of
the term: #4664929, held by LF CHARITIES, Inc.

⚠ This section is prone to misinterpretation. The recipient named in the proposal of 2011-01-11 is not the recipient it ended up with. The relevant section of the proposal states:

Kohsuke will be registering the trademark for Jenkins in his name, with the intent of transferring ownership of
the trademark to the umbrella of the Software Freedom Conservancy once the Jenkins project has been admitted
to it

⇒ The recipient named in the proposal was Software Freedom Conservancy. However, Software in the Public Interest was the organization that actually managed the assets and governance for a significant period. The change history on the trademark page records 2021-02-24 as the date of the transfer from Software in the Public Interest. Therefore, it is necessary to view the initial concept and the actual outcome after ten years as separate developments. ⚠ This article does not explain why the initial concept was not realized. Available documentation does not provide that explanation.

The line that kept the name Hudson, meanwhile, became a project of the Eclipse Foundation. The Eclipse Foundation's handbook does not allow a project to arrive holding its own trademark.

If you already have a trademark on your project name, that trademark must be assigned to the Eclipse Foundation.

⇒ Ultimately, both paths concerning the name led to the same outcome: both transferred the name to a foundation. ⚠ However, the points at which they arrived were not identical. The line that renamed itself is still shipping versions in 2026. The line that kept the name Hudson stopped at version 3.4.0 on 2016-09-02, and that project is now archived.

⚠ This article does not present this convergence as a pre-planned outcome. The 2011 documentation does not mention the intended recipient ten years later. What stands here is only that both ended up in the same shape.

Frequently Asked Questions about CI/CD Tools History

Why was Hudson renamed to Jenkins?

It was a trademark question. The proposal published on January 11, 2011, states that Oracle had filed trademark applications for "Hudson" in both the EU and the US, on the ground that Kohsuke Kawaguchi created Hudson while he was employed at Sun Microsystems. Because a permanent guarantee could not be obtained to continue using the name, a name change was proposed. ⚠ This was not due to any technical disagreements. Furthermore, publicly available documents do not state Oracle's intentions, and this article does not attempt to speculate on them.

Was the Hudson to Jenkins change a fork or a rename?

The proposal article states that the change was a rename. The same article poses the question of whether it was a fork or a rename, and concludes that it was the latter. The reason given is that the core of the project remained with the original author. ⚠ However, a line carrying the name Hudson continued separately. That line became an Eclipse Foundation project, and its last recorded version was 3.4.0, released on 2016-09-02. Whether you call it a fork or a rename depends on what you treat as the identity of the line.

Who owns the Jenkins trademark today?

It is LF Charities, Inc., a subsidiary of the Linux Foundation. The project's trademark page states that LF Charities, Inc. holds the U.S. registration number #4664929 and that it was transferred from Software in the Public Interest, Inc. on February 24, 2021. ⛔ The 2011 proposal named Software Freedom Conservancy as the recipient, and that is not the route it actually took. Some secondary articles may contain inaccuracies regarding this point.

Is Travis CI still running?

Yes, it is still running. As of September 6, 2026, the official website is accepting new customer sign-ups. The company is now owned by Idera, which acquired it on January 23, 2019. ⚠ However, the travis-ci.org domain was shut down in 2021. An announcement on May 7, 2021, indicated that May 31, 2021, was the target date for the shutdown, and that historical build logs would remain accessible in read-only mode even after the shutdown. Consolidating a domain and ending a service are separate matters.

Did AWS shut down CodeCommit?

No, it did not. While AWS CodeCommit was closed to new customers on July 25, 2024, it continued to be offered to existing users. On November 24, 2025 it returned to general availability, and new customer sign-ups are open again. ⛔ The two rows look contradictory on the timeline, but both are official records. For details on AWS's retired services and the context of this change, please refer to the AWS Retired Services History and Timeline.

What is the difference between maintenance, sunset, and end of support?

These are distinct states. AWS's announcement from October 13, 2025, sets out three stages: Maintenance, where new customers can no longer take up the service; Sunset, where a migration window is open and the end date is still ahead; and End of Support, where service has ended. Even when new customer sign-ups are stopped, the service may continue to be provided to existing users. ⚠ Furthermore, different vendors may use different terminology for their products. For example, AWS CodeCommit uses available while Amazon CodeCatalyst uses open. Reading the primary source as written is the reliable way to settle it.

When did GitHub Actions become a CI/CD product?

GitHub Actions became a CI/CD product on August 8, 2019. Actions was initially announced on October 16, 2018, as a limited public beta, and at that time, it was designed to connect containers and run development workflows. That announcement mentions neither continuous integration nor continuous delivery. The announcement regarding its support for CI/CD was made on August 8, 2019, and general availability followed on November 13, 2019. ⚠ The configuration and hardening of Actions belongs to Hardening GitHub Actions for AWS Deployments.

Why does this timeline not rank the tools?

This article aims to list the reasons why the options have evolved into their current forms. It is not possible to rank the tools based on which are superior, as that depends on the team's constraints and operational structure. The timeline can only reflect the form a tool took in a particular year and the events that led to that form. ⚠ Furthermore, this article does not offer any evaluations of decisions made by companies or communities. Where an official source gives a reason, this article quotes it within that scope. Where it does not, this article does not fill the gap.

Summary

This article summarizes the history of CI/CD tools as a timeline, clarifying the current landscape.

Historically, the evolution of this category has been driven not by technology, but by ownership and governance. When the timeline is reordered by the Trigger column, only four things stand at the breaks: trademarks, acquisitions, transfers to a foundation, and changes to the terms of availability. The Hudson case in 2011 remains relevant because it demonstrated that the scope of a license and the scope of a name are different. Code can be copied freely, but a separate right decides what that code may be called.

Another pattern emerges when the timeline is viewed horizontally: the location of the execution environment has shifted. It has moved from teams building their own servers, to providers offering hosted solutions, and finally to the code hosts themselves. GitLab, Azure DevOps, and GitHub independently moved in the same direction in 2015, 2018, and 2019, respectively. ⚠ However, this transition is not complete. Jenkins kept shipping versions right up to the LTS release of 2026-09-02, and running your own server has not gone away.

The terminology used to describe the state of a product is nuanced. Stopping new customer sign-ups, moving to maintenance, and ending service are distinct states, and vendors may use different terms for each. Furthermore, a product's state can revert. AWS CodeCommit stopped accepting new customer sign-ups on July 25, 2024, but later returned to general availability on November 24, 2025. The situation where two lines on the timeline appear contradictory, yet both represent official records, is a reality.

And the two lines that split in 2011 each took a different road and both ended up handing the name to a foundation. The line that renamed itself moved its trademark to a subsidiary of the Linux Foundation on 2021-02-24. The line that kept the name Hudson became a project of the Eclipse Foundation, which requires an existing trademark to be assigned to it. ⚠ However, the endpoints are not the same. The former is still shipping versions; the latter stopped on 2016-09-02. This alignment was not planned; the documents from 2011 do not specify the intended recipient of the names ten years later.

The timeline in this article includes rows with varying degrees of date precision. Rows referencing primary sources that only state the year are presented with that level of precision. Rows where the project's own records disagree are left showing that disagreement. When primary sources provide conflicting dates, the row states which one was taken. Information that could not be verified through primary sources is not included.

This category continues to evolve. This article will be updated to reflect those changes.

Additional articles cover related topics.

References:
Tech Blog with curated related content

Written by Hidekazu Konishi