Hello friends! I am Marky Jackson and I am so thrilled to be one of the newest CDF ambassadors.
I have been involved in open source for many years but my start in the world was rather rocky. I had a difficult childhood. I was shuffled from one boys’ home to another and had little control over my life. But I was tough and smart, and I emancipated at an early age, which allowed me to start living the way I wanted while I was still in my teens.
I studied computer science at UCLA and MIT and then spent 14 months as an intern at Jasmine Multimedia Publishing before joining companies such as Yahoo, AT&T, HP, Symantec and more.
I am extremely excited to be a part of this program because I get to make people smile by mentoring and being positive. I love public speaking, doing a meetup in person or virtual and helping people online. I get joy when a person gets involved in the open-source community.
The open source community is all about inclusion. We welcome people to contribute, and we try to express our gratitude for their hard work. The sense of unity and belonging is second to none with developers, coders, and engineers from around the world collaborating to advance our industry.
It takes a lot of time and effort to keep the open-source community going. Most of us are working after-hours to get things done, and we need help—lots of help. People think that you have to be an expert coder to join us, but that’s not true. There are plenty of ways to take part in. You can contribute error reports, write technical documentation, or even sponsor an application. There are plenty of ways to offer support. Just ask what you can do.
I look forward to meeting everyone and collaborating! You can find me at @markyjackson5 on Twitter.
From Dailymotion, a French video-sharing technology platform with over 300 million unique monthly users
At Dailymotion, we are hosting and delivering premium video content to users all around the world. We are building a large variety of software to power this service, from our player or website to our GraphQL API or ad-tech platform. Continuous Delivery is a central practice in our organization, allowing us to push new features quickly and in an iterative way.
We are early adopters of Kubernetes: we built our own hybrid platform, hosted both on-premise and on the cloud. And we heavily rely on Jenkins to power our “release platform”, which is responsible for building, testing, packaging and deploying all our software. Because we have hundreds of repositories, we are using Jenkins Shared Libraries to keep our pipeline files as small as possible. It is an important feature for us, ensuring both a low maintenance cost and a homogeneous experience for all developers – even though they are working on projects using different technology stacks. We even built Gazr, a convention for writing Makefiles with standard targets, which is the foundation for our Jenkins Pipelines.
In 2018, we migrated our ad-tech product to Kubernetes and took the opportunity to set up a Jenkins instance in our new cluster – or better yet move to a “cloud-native” alternative. Jenkins X was released just a few months before, and it seemed like a perfect match for us:
It is built on top and for Kubernetes.
At that time – in 2018 – it was using Jenkins to run the pipelines, which was good news given our experience with Jenkins.
It comes with features such as preview environments which are a real benefit for us.
And it uses the Gitops practice, which we found very interesting because we love version control, peer review, and automation.
While adopting Jenkins X we discovered that it is first a set of good practices derived from the best performing teams, and then a set of tools to implement these practices. If you try to adopt the tools without understanding the practices, you risk fighting against the tool because it won’t fit your practices. So you should start with the practices. Jenkins X is built on top of the practices described in the Accelerate book, such as micro-services and loosely-coupled architecture, trunk-based development, feature flags, backward compatibility, continuous integration, frequent and automated releases, continuous delivery, Gitops, … Understanding these practices and their benefits is the first step. After that, you will see the limitations of your current workflow and tools. This is when you can introduce Jenkins X, its workflow and set of tools.
We’ve been using Jenkins X since the beginning of 2019 to handle all the build and delivery of our ad-tech platform, with great benefits. The main one being the improved velocity: we used to release and deploy every two weeks, at the end of each sprint. Following the adoption of Jenkins X and its set of practices, we’re now releasing between 10 and 15 times per day and deploying to production between 5 and 10 times per day. According to the State of DevOps Report for 2019, our ad-tech team jumped from the medium performers’ group to somewhere between the high and elite performers’ groups.
But these benefits did not come for free. Adopting Jenkins X early meant that we had to customize it to bypass its initial limitations, such as the ability to deploy to multiple clusters. We’ve detailed our work in a recent blog post, and we received the “Most Innovative Jenkins X Implementation” Jenkins Community Award in 2019 for it. It’s important to note that most of the issues we found have been fixed or are being fixed. The Jenkins X team has been listening to the community feedback and is really focused on improving their product. The new Jenkins X Labs is a good example.
As our usage of Jenkins X grows, we’re hitting more and more the limits of the single Jenkins instance deployed as part of Jenkins X. In a platform where every component has been developed with a cloud-native mindset, Jenkins is the only one that has been forced into an environment for which it was not built. It is still a single point of failure, with a much higher maintenance cost than the other components – mainly due to the various plugins.
In 2019, the Jenkins X team started to replace Jenkins with a combination of Prow and Tekton. Prow (or Lighthouse) is the component which handles the incoming webhook events from GitHub, and what Jenkins X calls the “ChatOps”: all the interactions between GitHub and the CI/CD platform. Tekton is a pipeline execution engine. It is a cloud-native project built on top of Kubernetes, fully leveraging the API and capabilities of this platform. No single point of failure, no plugins compatibility nightmare – yet.
Since the beginning of 2020, we’ve started an internal project to upgrade our Jenkins X setup – by introducing Prow and Tekton. We saw immediate benefits:
Faster scheduling of pipelines “runners” pods – because all components are now Kubernetes-native components.
Simpler pipelines – thanks to both the Jenkins X Pipelines YAML syntax and the ability to easily decouple a complex pipeline in multiple small ones that are run concurrently.
Lower maintenance cost.
While replacing the pipeline engine of Jenkins X might seem like an implementation detail, in fact, it has a big impact on the developers. Everybody is used to see the Jenkins UI as the CI/CD UI – the main entry point, the way to manually restart pipelines executions, to access logs and test results. Sure, there is a new UI and a real API with an awesome CLI, but the new UI is not finished yet, and some people still prefer to use web browsers and terminals. Leaving the Jenkins Plugins ecosystem is also a difficult decision because some projects heavily rely on a few plugins. And finally, with the introduction of Prow (Lighthouse) the Github workflow is a bit different, with Pull Requests merges being done automatically, instead of people manually merging when all the reviews and automated checks are green.
So if 2019 was the year of Jenkins X at Dailymotion, 2020 will definitely be the year of Tekton: our main release platform – used by almost all our projects except the ad-tech ones – is still powered by Jenkins, and we feel more and more its limitations in a Kubernetes world. This is why we plan to replace all our Jenkins instances with Tekton, which was truly built for Kubernetes and will enable us to scale our Continuous Delivery practices.
If you are interested to know more about Jenkins features introduced in 2019, stay tuned for a separate blog post about it (coming soon!).
Project updates
Highlights above do not cover all advancements we had in the project. Below you can find slides from the Jenkins contributor summit in Lisbon. There we had project updates by officers, SIG and sub-project leaders. See the slide deck to know about: Jenkins Core, Pipeline, Configuration-as-Code, Security, UX Overhaul, Jenkins Infrastructure, platform support and documentation.
Some stats and numbers
If this section seems to be too long for you, here is some infographic prepared by Tracy Miranda. As you may see, Jenkins is pretty big 🙂
Community. Over the past year we had 5433 contributors in GitHub repositories (committers, reviewers, issue submitters, etc.). We had 1892 unique committers who created 7122 pull requests and 45484 commits, bots excluded. Contributors represent 273 companies and 111 countries, 8% of contributors are recognized as independent. The most active repositories were Jenkins Core and jenkins.io. The most active month was October 2019 when we reached the record high number of contributions: 915 unique contributors, 124 of them were first-timers, thanks to Hacktoberfest!.
Jenkins core. In 2019 Jenkins core had 54 weekly and 13 LTS releases with several hundreds of notable fixes/enhancements. There was a login screen extensibility rework, many update manager and administrative monitors improvements. We also introduced support for user timezones, not speaking of emojis support 🥳. There was also a lot of housekeeping work: better APIs, codebase refresh, cleaning up static analysis warnings and removing deprecated features like Remoting CLI. The core’s components also got major updates. Only Jenkins Remoting got 11 releases with stability improvements and new features like support of inbound connections to headless Jenkins masters. There are also major incoming features like JEP-222: WebSocket Services support, UI look&feel updates, JENKINS-12548: Readonly system configuration support, Docker images for new platforms like Arm. To facilitate further changes we created a new Core pull request reviewers team and added 9 contributors there.
Plugins. There were 2654 plugin releases, and 157 NEW plugins have been hosted in the Update Center. Jenkins ecosystem got a lot of new integrations with Development and DevOps tools. Also, warm welcome back to the Scriptler Plugin which was depublished in 2017 due to security issues. If you are afraid about such plugin numbers and dependency management, there is a new Plugin Installation Manager CLI Tool which should help Jenkins users to manage plugins more efficiently.
Security. It was a hot year for the Jenkins Security Team. There were 5security advisories for the core and 20 – for plugins. In total we disclosed 288 vulnerabilities across the project, including some backlog cleaning for unmaintained plugins. Script Security Plugin was the hottest plugin with 10 critical fixes addressing various sandbox bypass vulnerabilities. Plain text storage and unprotected credentials were the most popular vulnerability type 120 disclosures in 2019. It was made possible by hundreds of reports submitted by contributors after code surveys, special thanks to Viktor Gazdag who reported the most of the issues and became the Jenkins 2019 Security MVP (check out his story here).
Infrastructure. Got Jenkins? If so, you rely on Jenkins update centers, website and issue tracker. All these and many other services are maintained by the Jenkins Infrastructure Team. This year the team handled more than 400 requests in the bugtracker, and many other informal requests. In total, more than 30 people contributed to Jenkins infrastructure this year (website content is excluded). We also deployed 4 new services, migrated 7 services from Azure Container Service to Azure Kubernetes Service and updated many other services. More changes will happen in the next months, and we are looking for new INFRA team members!
Documentation. Only last quarter we had 178 contributors to Jenkins documentation. It includes jenkins.io and other documentation hosted on GitHub, Wiki is not included. There is also ongoing migration plugin documentation from Jenkins Wiki to GitHub (announcement). Since the beginning of the project in Sep 2019, more than 150 plugin were migrated, and they got significant documentation revamp during the migration. You can see the current status https://jenkins-wiki-exporter.jenkins.io/progress. We also work on introducing changelog automation in the project. 123 plugins have already adopted the new changelog tools, powered by Release Drafter. Also, we had more than 60 technical blog posts published on jenkins.io.
Configuration as Code was one of the most popular areas this year. Jenkins Configuration as Code Plugin had more than 30 releases with new features and bug fixes. More than 50 plugins have been also updated in order to offer better configuration-as-code support. As a result, the JCasC Plugin got massive adoption this year (from 2000 to almost 8000 installations), and now it becomes a de-facto standard for managing Jenkins as code. This year we also ran our very first CommunityBridge project devoted to JCasC Schema validation and developer tools.
Events and outreach programs. In 2019 we participated in multiple conferences, including FOSDEM, DevOps World | Jenkins World, SCALE. More than 40 Jenkins Area Meetups were organized across the world, and there were many other meetups devoted to Jenkins. We also kept expanding our outreach programs. In total we had 12 students who participated in Google Summer of Code, Outreachy and newly introduced Community Bridge. We also had the biggest ever Hacktoberfest with 664 pull requests and 102 participants. These outreach programs help us to deliver new features in Jenkins. For example, this year we added Multi-branch Pipeline support for Gitlab and a new Plugin Installation Manager Tool during GSoC, and Outreachy resulted in a new Audit Log Plugin.
Year 2020 will be pretty busy for the Jenkins project. There are many long-overdue changes in the project, which need to happen if we want the project to succeed. As it was written Board elections blogpost, there are many areas to consider: UX revamp, cloud native Jenkins, pluggable storage, etc. In the coming months there will be a lot of discussions in mailing lists and special interest groups, and we invite all teams to work on their roadmaps and to communicate them in the community.
Next month we will participate in FOSDEM, and there will be a Jenkins stand there. On January 31st we will also host a traditional contributor summit in Brussels, where we will talk about next steps for the project, in terms of technical roadmaps and the project governance. If you are interested in Jenkins, stop by at our community booths and join us at the summit! See this thread for more information.
We also plan to continue all outreach programs. At the moment we are looking for Google Summer of Code 2020 mentors and project ideas (announcement), and we will be also interested to consider non-coding projects as a part of other programs like CommunityBridge. We also work on improving contribution guidelines for newcomers and expert contributors. If you are interested, please contact the Advocacy and Outreach SIG.
And even more
This blog post does not provide a full overview of what changed in the project. The Jenkins project consists of more than 2000 plugins and components which are developed by thousands of contributors. Thanks to them, a lot of changes happen in the project every day. We are cordially grateful to everybody who participates in the project, regardless of contribution size. Everything matters: new features, bug fixes, documentation, blog posts, well reported issues, Stackoverflow responses, etc. THANKS A LOT FOR ALL YOUR CONTRIBUTIONS!
So, keep updating Jenkins and exploring new features. And stay tuned, there is much more to come next year!
Jenkins core maintainer and board member. Oleg started using Hudson for Hardware/Embedded projects in 2008 and became an active Jenkins contributor in 2012. Nowadays he leads several Jenkins SIGs, outreach programs (Google Summer of Code, Hacktoberfest) and Jenkins meetups in Switzerland and Russia. Oleg works for CloudBees and focuses on key projects in the community. GitHub Twitter Blog
Outreachy is a program for open source internships that specifically targets people in demographics that are underrepresented in tech. Since 2010 Outreachy has had over 400 participants making contributions to open source projects. Outreachy is one of the most effective programs for improving the diversity of open source communities. For those familiar with Google Summer of Code, Outreachy follows a very similar format.
The Continuous Delivery Foundation is a neutral home for the next generation of continuous delivery collaboration. We know that the greater number of diverse voices we have collaborating, the more effective we are as a community. Which is why we are thrilled to be participating in Outreachy for this upcoming round.
Three of the CD Foundation projects: Jenkins, Jenkins X and Tekton are offering Outreachy internship projects. The Jenkins project has participated in the previous 2 rounds of Outreachy, having a total of 4 Outreachy interns working with the community on the Jenkins Audit Log Plugin. Jenkins mentor Matt Sicker shares in this post “Outreachy has helped open my eyes to the struggles that developers from around the world are dealing with which can be improved upon to help expand our communities. For example, many countries do not have reliable internet or electricity, so the use of synchronous videoconferencing and other heavyweight, synchronous processes common to more corporate-style development are inadequate in this international context.”
In that way Outreachy is also beneficial to the mentors participating. The actual tech contributions are a bonus side effect. Jenkins participates in the program with no expectation that the interns remain part of the community – but takes a wider, long term view that this generally improves open source and tech communities as a whole. Tracy Miranda, Outreachy coordinator for the Jenkins project says “As of this year I know of 2 Outreachy alumni (non-Jenkins projects) who were hired by my employer and both mention the Outreachy program as an important stepping stone in their career journeys.”
Here are the details of this round’s CD Foundation projects which we are looking for interns for. Please help us spread the word.
Kara de la Marck, the Jenkins X Outreachy coordinator can personally speak to the benefits of the program: “Outreachy is a fantastic mentoring program that helps to onboard new contributors to a project and to open source more generally. Many participants go on to become long term contributors to open source. As an alumna, I have carried forward a deep appreciation of open source as an enabler of global collaboration, technological innovation, and community. I’m incredibly happy to welcome Outreachy participants to Jenkins X.”
Please help us spread the word, and we look forward to working with Outreachy interns and welcoming them into our community.
Jenkins Community Celebrates 15 years of Continuous Delivery Automation and Innovation at DevOps World | Jenkins World
DEVOPS WORLD | JENKINS WORLD, SAN FRANCISCO – AUGUST 14, 2019 – The Jenkins project, comprised of the community of practitioners using Jenkins®,
today celebrated its 15th birthday at DevOps
World | Jenkins World with a recap of milestones showcasing
the community’s growth and the project’s defining impact on the global software industry.
Jenkins is the world’s leading open source
automation server, used by companies large and small to implement continuous
integration (CI) and continuous delivery (CD). Originally developed in 2004 and
called Hudson, Jenkins’ impact has grown consistently over the years to the
point where experts regularly describe Jenkins as the de facto tool for CI/CD.
So far this year, the Jenkins project has been
a key driver in the formation of the Continuous
Delivery Foundation,
has continued to experience strong uptake in the use of Jenkins and will
recognize key contributors to the Jenkins project around the globe during
Thursday’s keynote session at DevOps World | Jenkins World.
In
establishing the Continuous
Delivery Foundation, the Jenkins community worked with The
Linux Foundation, CloudBees, Google and Netflix to create a new foundation for
the diverse CI/CD space. In addition to Jenkins, the Continuous Delivery
Foundation was established with several other CI/CD open source projects,
including Jenkins X, Spinnaker and Tekton. It serves as a vehicle to develop, nurture and promote open source
projects, best practices and industry specifications related to continuous
delivery.
The
Continuous Delivery Foundation fosters vendor-neutral collaboration between the
industry’s top developers, end users and vendors to further CI/CD best
practices and industry specifications. Its mission is to grow and sustain
projects that are part of the broad and growing continuous delivery ecosystem.
“This has been a great year for Jenkins, the
Continuous Delivery Foundation and open source collaboration as a whole,” said
Chris Aniszczyk, vice president at the Linux Foundation. “We all share a common
mission – to support community-based development of projects that advance the
state of software delivery. The Jenkins project has been squarely behind this
effort from day one and today the community is stronger than ever.”
Also
playing a key role in Jenkins’ transition to the CDF was CloudBees’ Tracy
Miranda. Miranda took on the dual roles of CloudBees director of open source
community and member of the governing board of the CDF. “CD is becoming a
differentiator for organizations in every industry, yet adoption remains
challenging. It’s an industry-wide problem that needs an industry-wide
solution. From the CloudBees perspective, we see it as critical to have a
neutral foundation where all agents of change can collaborate and contribute
openly,” said Miranda. “Looking ahead to the next 15 years, we need to solve the complexity of CD adoption. With
the CDF, we are well-equipped to do this in open source – building on top of
all that we have learned in the Jenkins community over the years.”
During
the period from July 1, 2018, through June 30, 2019, the Jenkins project
achieved these milestones:
46% growth in active Jenkins installations1
reporting usage data was in the period August 1, 2018 – July 31, 2019
The community experienced approximately 46 percent growth in active
installations, reaching 265,956 installations as of July 31, 2019, compared to
182,236 installations as of August 1, 2018. Active installations are defined as
Jenkins instances that report usage information back to the Jenkins project.
This number is not representative of the total Jenkins instances in use
worldwide; that number is significantly greater.
Approximately 15.8 million Jenkins developers A recent Datanyze analysis of the CI vendor landscape showed that about 66
percent of continuous integration is being run on Jenkins. With an estimated 24
million developers, globally, according to Evans Data in its 2019 Global
Developer Population and Demographics Study, approximately 15.8 million developers are
using Jenkins.
254% growth in Jenkins Pipeline jobs Finally, the combined number of defined Jenkins jobs increased during this same period from 19,946,119 in July 2018 to 30,281,905, or 52 percent growth. Specifically, Jenkins Pipeline jobs grew 254 percent in the same period. The dramatic growth in Jenkins Pipeline jobs demonstrates that organizations are accelerating their investment in modern software pipeline automation practices with Jenkins.
“Over the past 15 years, the Jenkins project has revolutionized the way software is built and delivered,” said Jenkins creator Kohsuke Kawaguchi, who also serves as chief scientist at CloudBees. “We have touched every industry and made a difference to every software team in the world.”
1The Jenkins community tracks statistics from active Jenkins installations that transmit usage information back to the project. The numbers do not represent a majority of Jenkins installations, only those who choose to report. Therefore, the numbers are conservative.
About the Continuous Delivery Foundation Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. The Continuous Delivery Foundation (CDF) is a Linux Foundation initiative that serves as the vendor-neutral home for many of the fastest-growing projects, including Jenkins, Jenkins X, Spinnaker, and Tekton. The CDF fosters collaboration between the industry’s top developers, end users and vendors to further continuous delivery best practices. For more information about the CDF, please visit https://cd.foundation.
Every year before the DevOps World | Jenkins World conference, Jenkins contributors gather for a contributor summit. Earlier this year, the CD Foundation became the new home for Jenkins as well as Jenkins X, Tekton and Spinnaker projects. CD Foundation serves as the new home for many of the fastest-growing projects for continuous delivery as well as a neutral home for collaboration in the CI/CD space. In that spirit of collaboration, this year’s contributor summit is being expanded to be a CDF Contributor Summit.
CDF Contributor Summit will be held on Monday August 12, 2019 in San Francisco, USA just before DevOps World | Jenkins World. It is a free event open to contributors of the open source projects. So far we will have community members from the Jenkins, Jenkins X and Tekton projects attending the summit.
The summit brings together community members to learn, meet and help shape the future of the projects. In the CDF community we value all types and sizes of contributions and love to welcome new participants who want to contribute to one or more projects.
The morning portion of the summit will consist of presentations by core committers of the projects. Presentations will highlight what each effort is about and what community members can do to help. We will cover a range of topics from technical aspects to community topics.
In the afternoon we will break into Birds of a Feather table for in-depth discussion and collaboration on different topics of interest. Bring your laptop, come prepared with questions and ideas, and be ready to meet and get coding with other contributors.
Agenda: (tentative)
9:00 am – Kickoff & Welcome with coffee/pastries
10:00 am – Project Updates
12:00 pm – Lunch
1:00 pm – BoF/Unconference
3:00 pm – Break
3:30 pm – BoF/Unconference
4:30 – Ignite Talks
5:00 pm – Wrap-up
To join the summit, please sign up with the main project you contribute to or are interested in contributing to:
Jenkins contributors have decided that our project should join this new foundation. This discussion happened over the time span of years, actually, but a relatively succinct summary of the motivations are here.
Now, as an user, what does this mean?
First, there will be no big disruption/discontinuity. The same people are still here, no URL is changing, releases will come out like they’ve always been. We make the decisions the same way we’ve been making, and pull requests land the same way. Changes will happen continuously over the period of time.
This is yet another testament to the maturity and the importance of the Jenkins project in this space. With a quarter million Jenkins running around the globe, it’s truly rocking the world of software development from IoT to games, cloud native webapps to machine learning projects. It makes Jenkins such an obvious, safe choice for anyone seeking open heterogeneous DevOps strategy.
The CDF creates a level playing field that is well-understood to organized contributors, which translate into more contributors, which results in a better Jenkins, faster. Over the past years, the Jenkins project has been steadily growing morestructures that provide this clarity, and this is the newest step on this trajectory.
Any serious dev teams are combining multiple tools and services to cover the whole software development spectrum. A lot of work gets reinvented in those teams to integrate those tools together. Jenkins will be working more closely with other projects under the umbrella of the CDF, which should result in better aligned software with less overlap.
Our users are practitioners trying to improve the software development process in their organizations. They get that CI/CD/automation unlocks the productivity that their organizations need, but that’s not always obvious to their organizations as a whole. So our users often struggle to get the necessary support. The CDF will advocate for the practice of Continuous Delivery, and because it’s not coming from a vendor or a project, it will reach the people who can lend that support.
So I hope you can see why we are so excited about this!
In fact, for us, this is an idea that we’ve been cooking for close to two years. I don’t think I’m exaggerating much to say the whole idea of the CDF started from the Jenkins project.
A lot of people have done a lot of work behind the scene to make this happen. But a few people played such instrumental roles that I have to personally thank them. Chris Aniszczyk for his patience and persistence, Tyler Croy for cooking and evolving the idea, and Tracy Miranda for making an idea into a reality.
We’re
excited to announce that Google is a founding member of the newly formed Continuous
Delivery Foundation (CDF). Continuous delivery (CD) is a critical part of modern software development and DevOps
practices, and we’re excited to collaborate in a vendor-neutral foundation with
other industry leaders.
We’re also thrilled to announce the contribution of two projects as part of our membership: Tekton, and in collaboration with Netflix, Spinnaker. These donations will enter alongside Jenkins and Jenkins X, providing an exciting portfolio of projects for the CDF to expand upon.
Continuous Delivery Foundation
Currently,
the continuous integration/continuous delivery (CI/CD) tool landscape is highly
fragmented. As companies migrate to the cloud and modernize their
infrastructure, tooling decisions become increasingly complicated and
difficult. DevOps practitioners constantly seek guidance on software delivery
best practices and how to secure their software supply chains but gathering
this information can be difficult. Enter the CDF.
The CDF is
about more than just code. Modern application development brings new challenges
around security and compliance. This foundation will work to define the
practices and guidelines that, together with tooling, will help application
developers everywhere deliver better and more secure software at speed.
At a
foundation level, the CDF will help make CI/CD tooling easier. And at a project
level, Tekton helps address complexity problems at their core. We will team up
with the open source community and industry leaders to design and build the
critical pieces common to CI/CD systems.
Tekton
Tekton is a set of
shared, open source components for building CI/CD systems. It provides a
flexible, extensible workflow that accommodates deployment to Kubernetes, VMs,
bare metal, mobile or even emerging use cases.
The project’s goal
is to provide industry specifications for
pipelines, workflows, source code access and other primitives. It modernizes the continuous delivery control plane by
leveraging all of the built-in scaling, reliability, and extensibility
advantages of Kubernetes, and moves software deployment logic there. Tekton was initially built as a part of Knative, but given its stand-alone power, and ability to deploy to a variety
of targets, we’ve decided to separate its functionality out into a new project.
Today,
Tekton includes primitives for pipeline definition, source code access,
artifact management, and test execution. The project roadmap includes adding
support for results and event triggering in the coming months. We also plan to
work with CI/CD vendors to build out an ecosystem of components that will allow
you to use Tekton with existing tools like Jenkins X, Knative and others.
Spinnaker
Spinnaker
is an open source, multi-cloud continuous delivery platform originally created
by Netflix and jointly led by Netflix and Google. It is typically used in
organizations at scale, where DevOps teams support multiple development teams,
and has been battle-tested in production by hundreds of teams and in millions
of deployments.
Spinnaker is a
multi-component system that conceptually aligns with Tekton, and that includes
many features important to making continuous delivery reliable, including
support for advanced deployment strategies, and Kayenta, an open source canary analysis
service.
Given Google’s
significant contributions to both Tekton and Spinnaker, we’re very pleased to
see them become part of the same foundation. Spinnaker’s large user community
has a great deal of experience in the continuous delivery domain, and joining
the CDF provides a great opportunity to share that expertise with the broader
community.
If you’d like to participate in the future of Tekton, Spinnaker, or the CDF,
please join us in Barcelona, Spain, on May 20th at the Continuous Delivery Summit ahead of KubeCon/CloudNativeCon EU. If you can’t make it, don’t worry,
as there will be many opportunities to get involved and become a part of the
community.
We look
forward to working with the continuous delivery community on shaping the next
wave of CI/CD innovations, alignments, and improvements, no matter where your
applications are delivered to.
