Category

Blog

Jan 21
Love0

CD Foundation Technical Oversight Committee Approves Interoperability SIG!

By Blog

Continuous Delivery Foundation (CDF) Governing Board (GB) agreed to and ratified 9 strategic goals in early October 2019. One of the strategic goals identified by CDF GB is fostering tool interoperability.

Recognition of the importance of interoperability and identifying it as one of the strategic goals is a very important step for CDF to take for users. Users and organizations employ various CI/CD tools and technologies depending on their needs and where they are in their CI/CD transformation. Organizations often employ more than one tool in various stages of their CI/CD pipelines due to different capabilities provided by the tools and this is perhaps one of the biggest benefits users get by using open technologies for their CI/CD needs. For example, CDF member Salesforce has over 20 different CI/CD tools internally thanks to acquisitions and different requirements in teams. 

However, one of the challenges users face is the lack of interoperability across the CI/CD tools and technologies, resulting in various issues while constructing and running pipelines such as passing metadata and artifacts between the tools or achieving traceability from commit to deployment. Often users end up building their “own glue code” to address what is a common problem, further complicating moving from one tool to another and adopting new technologies and methodologies.

These “glue code solutions” are generally specific to users’ needs and tools rather than being loosely coupled and agnostic to tooling and technology. Additionally these solutions are not visible to other users and the communities, making them vulnerable to the risk of outage in their CI/CD pipelines due to potential changes (i.e. non-backward changes to the APIs, changes in data models) that happen to the tools in respective projects.

Therefore, focusing on tool interoperability is critical. 

There has been significant collaboration going on in this area. Linux Foundation Networking (LFN), OpenStack Foundation (OSF), and Cloud Native Computing Foundation (CNCF) projects have done a lot  to raise awareness of CI/CD interoperability challenges. In addition to these communities, Spinnaker, Jenkins, Tekton, and Jenkins X, CDF founding projects, have been collaborating and sharing ideas. However, there are many more users, projects and communities, either looking for answers to similar interoperability challenges, on their way to developing solutions, or simply trying to find like minded people to work with together.

We believe the work should happen in a neutral forum where users come together with maintainers of open source CI/CD projects and have a dialog about the challenges we need to address. 

Which is why the CDF Interoperability SIG was launched, led by Fatih Degirmenci of Ericsson and with support from representatives from Netflix, Google, China Mobile, CloudBees and others. 

We, the CDF Interoperability SIG, aim to provide such a forum and enable a dialog around interoperability in order to:

  • clarify what interoperability means for the CI/CD ecosystem
  • promote the need to collaborate on interoperability challenges in a neutral forum
  • highlight and promote the needs of the users who face challenges constructing complex end-to-end CI/CD flows and pipelines by employing different tools and technologies
  • explore synergies between, and enable collaboration across, the CI/CD projects with regards to interoperability
  • pursue solutions which are loosely coupled, scalable, flexible, and tool and technology agnostic
  • reduce the need for users to implement in-house solutions by promoting native interoperability between tools
  • attract and assist projects that work on interoperability

Membership to the Interoperability SIG is open to the public. We invite users and contributors to open source CI/CD projects to join us to share ideas, use cases, challenges, and solutions with each other. 

Here are some of the ways you can take part in the Interoperability SIG and start collaborating:

CDF SIG Meets every even week on Thursdays at 15:00UTC on Zoom and the meeting agenda and minutes are available here. Our first meeting will be on January 23, 2020.

Finally, we would like to thank everyone who has listened to our ideas, shared their thoughts, taken part in crafting the proposal, and most importantly, encouraged us with their +1s!

Jan 16
Love0

Happy Second Birthday Jenkins X!

By Blog

Originally posted in the Jenkins X blog by Rob Davies

Second year of Jenkins X

The Jenkins X project started the beginning of 2019 by celebrating its first birthday on the 14th January, a big event for any open source project, and we have just celebrated our 2nd – hooray!

image by Ashley McNamara, creative commons license

Two Years of Jenkins X!

Jenkins X has evolved from a vision of how CI/CD could be reimagined in a cloud native world, to a fast-moving, innovative, rapidly maturing open source project.

Jenkins X was created to help developers ship code fast on Kubernetes. From the start, Jenkins X has focused on improving the developer experience. Using one command line tool, developers can create a Kubernetes cluster, deploy a pipeline, create an app, create a GitHub repository, push the app to the GitHub repository, open a Pull Request, build a container, run that container in Kubernetes, merge to production. To do this, Jenkins X automates the installation and configuration of a whole bunch of best in breed open source tools, and automates the generation of all the pipelines. Jenkins X also automates the promotion of an application through testing, staging, and production environments, enabling lots of feedback on proposed changes. For example, Jenkins X preview environments allow for fast and early feedback as developers can review actual functionality in an automatically provisioned environment. We’ve found that preview environments, created automatically inside the pipelines created by Jenkins X, are very popular with developers, as they can view changes before they are merged to master.

Jenkins X is opinionated, yet easily extensible. Built to enable DevOps best practices, Jenkins X is designed to the deployment of large numbers of distributed microservices in a repeatable and manageable fashion, across multiple teams. Jenkins X facilitates proven best practices like trunk based development and GitOps. To get you up and running quickly, Jenkins X comes with lots of example quickstarts.

Highlights of 2019

February 2019: The rise of Tekton!

In the second half of 2018, Jenkins X embarked on a journey to provide a Serverless Jenkins and run a pipeline engine only when required. That pipeline engine was based on the knative build-pipeline project which evolved into Tekton with much help and love from both the Jenkins and Jenkins X communities. The Jenkins X project completed its initial integration with Tekton in February 2019. Tekton is a powerful and flexible kubernetes-native open source framework for creating CI/CD pipelines, managing artifacts and progressive deployments.

March 2019: Jenkins X joined The Continuous Delivery Foundation!

Jenkins X joined the Continuous Delivery Foundation (CDF) as a founding project alongside Jenkins, Spinnaker, and Tekton. Joining a vendor-neutral foundation, focused on Continuous Delivery, made a lot of sense to the Jenkins X community. There had already been a high level of collaboration with the Jenkins and Tekton communities, and there have been some very interesting and fruitful (in terms of ideas) discussions about how to work better with the Spinnaker communities also.

June 2019: Project Lighthouse

When Jenkins X embarked on its serverless jenkins journey, it chose to use Prow, an event handler for GitHub events and ChatOps. Prow is used by the Kubernetes project for building all of its repos and includes a powerful webhook event handler. Prow is well proven, but heavily tied to GitHub, and not easily extendable to other SCM providers. At the end of June 2019, work commenced on a lightweight, extensible alternative to Prow, called Lighthouse. Lighthouse supports the same plugins as Prow (so you can still ask via ChatOps for cats and dogs) and the same config – making migration between Prow and Lighthouse extremely easy.

June 2019: Jenkins X Boot!

We were very busy in June – a frantic burst of activity before summer vacations! One common problem Jenkins X users were facing was the installation of Jenkins X on different Kubernetes clusters. Installing services, ensuring DNS and secrets are correct, and done in the right order is completely different from vendor to vendor, and sometimes cluster to cluster. We realised that to simplify the install, we really needed a pipeline, and whilst this may sound a little like the plot to a film, running a Jenkins X pipeline to install jx really is the best option. The jx boot command interprets the boot pipeline using your local jx binary. The jx boot command can also be used for updating your cluster.

As part of the move to the CDF the Jenkins X project took the opportunity to redesign its logo. An automaton represents the ability of Jenkins X to provide automated CI/CD on Kubernetes and more!

Second half 2019: Big focus on Stability and Reliability

The Jenkins X project has been fast paced with lots of different components and moving parts. This fast pace unfortunately led to some instability and a growth of serious issues that risked undermining all the great work there had been on Jenkins X. There has been a concerted effort by the community to increase stability and reduce outstanding issues – the graph below shows the trend over the last year, with a notable downward trend in the number of issues being created in the last 6 months.

CloudBees also aided this effort by introducing the CloudBees Jenkins X Distribution with increased testing around stabilized configurations and deployments and regular releases every month.

October 2019: Jenkins X Steering Committee inaugural meeting

The Jenkins X Bootstrap Steering Committee is tasked with organising the transition to an elected steering committee, as well as determining what responsibilities the steering committee will have in guiding the Jenkins X project.

December 2019: First Jenkins X Outreachy mentee!

Neha Gupta is adding support for Kustomize in Jenkins X, to enable Kubernetes native configuration management, while participating in Outreachy from December 2019 to March 2020. We welcome Neha’s work on Jenkins X and look forward to building on our culture of continuous mentoring!

Jenkins X usage in Products

The easiest way to try out Jenkins X is undoubtedly through CloudBees CI/CD powered by Jenkins X which provides Jenkins X through the convenience and ease of use of SaaS. No cluster setup, no Jenkins X install, that is all done for you! Currently, CloudBees CI/CD powered by Jenkins X is available for preview. Sign up here to try out the new Jenkins X Saas!

What’s next?

The Jenkins X project is going to be encouraging the community to get involved with more innovation. There are a lot of great ideas to extend the continuous story with integrated progressive delivery (A/B testing, Canary and Blue/Green deployments) and Continuous Verification, alongside more platforms support. We are expecting lots of awesome new features in the CloudBees UI for Jenkins X too.

Expect lots more exciting new announcements from Jenkins X in 2020!

Jan 15
Love0

Getting Serious About Open Source Security

By Blog

A not so serious look at a very serious problem

Originally published on Medium by Dan Lorenc, (dlorenc@google.com,
twitter.com/lorenc_dan)

Photo by Matthew Henry on Unsplash

A Blast From the Past

2019 was a crazy time to be writing software. It’s hard to believe how careless we were as an industry. Everyone was just having fun slinging code. Companies were using whatever code they found laying around on NPM, Pip, or Maven Central. No one even looked at the code these package managers were downloading for them. We had no idea where these binaries came from or even who wrote most of this stuff.

And don’t even get me started on containers! There was no way to know what was inside most of them or what they did. Yet there we were, pulling them from Dockerhub, slapping some YAML on them, and running them as root in our Kubernetes clusters. Whoops, I just dated myself. Kubernetes was a primitive system written mostly in YAML and Bash that people used to interact with before Serverless came and saved us all.

Looking back, it’s shocking that the industry is still around! How we didn’t have to cough up every Bitcoin in the world to stop our databases from getting leaked or our servers from being blown up is beyond me. Thankfully, we realized how silly this all was, and we stopped using whatever code had the most Github stars and started using protection.

We’re Under Attack

No, really. Every time you pip install, go get, or mvn fetch something, you’re doing the equivalent of plugging a thumb drive you found on the sidewalk into your production server.

You’re taking code from someone you’ve never met and then running it with access to your most sensitive data. Hopefully, you at least know their email address or Github account from the commit, but there’s no way to know if this is accurate unless you’re checking PGP signatures. And let’s be honest, you’re probably not doing that.

This might sound like I’m just fear-mongering, but I promise I’m not. This is a real problem that everyone needs to be aware of. Attacks like this are called supply-chain attacks, and they are nothing new. Just last month, an active RCE vulnerability was found in an open source package on PyPi that was being used to steal SSH and GPG credentials.

There are lots of variations on this same play that make use of different social-engineering techniques in interesting ways. One attacker used a targeted version of this to steal cryptocurrency from a few specific websites. Another group performed a “long-con” where they actually produced and maintained a whole set of useful open source images on Dockerhub for years before slowly adding, you guessed it, crypto-mining.

The possibilities are endless, terrifying, and morbidly fascinating. And they’re happening more and more often. If reading about attacks like these is your kind of thing, the CNCF has started cataloging known instances of them. Snyk also just published a post detailing how easy it is to inject code like this in most major languages — Github even hides these diffs in code review by default! Russ Cox has also been writing about this problem for a while.

Vision

OK, there’s a bit of hyperbole up there (Kubernetes doesn’t have that much bash in it), but open source is under attack, and it’s not OK. Some progress is being made in this area — GitHub and others are scanning repositories, binaries, and containers, but these tools all only work on known vulnerabilities. They have no mechanism to handle intentional, malicious ones before they are discovered, which are at least as dangerous.

The brutal fact is that there is no way to be confident about the code you find on most artifact repositories today. The service might be compromised and serve you a different package from the one the author uploaded. The maintainer’s credentials might have been compromised, allowing an attacker to upload something malicious. The compiler itself might have been hacked, or even the compiler that compiler used (PDF warning)! Or, the maintainer could have just snuck something in on purpose.

For any given open source package, we need to be able to confidently assert what code it’s comprised of, what toolchains and steps were used to produce the package, and who was responsible for each piece. This information needs to be made available publicly. A reliable, secure view of the supply-chain of every open source package will help make these attacks easier to prevent and easier to detect when they do happen. And the ability to tie each line of code and action back to a real individual will allow us to hold attackers accountable.

How Do We Get There?

We need to work as an industry to start securing open source software, piece by piece.

Artifact repositories need to support basic authentication best practices like 2FA, artifact signing, and strong password requirements. DockerHub, PyPi, and NPM support 2FA, but there’s no way to see if a maintainer of a package is using it. Most container registries don’t support signatures yet, though work is ongoing.

Software build systems need to make reproducible, hermetic builds possible and easy. Debian has started doing some great work here, but they’re basically alone. Every docker build gives you a new container digest. Tar and gzip throw timestamps everywhere. It’s possible to get reproducible builds in Go, Java, and most other major languages, but it’s not necessarily easy. See the recently published whitepaper on how Google handles much of this internally for more information.

SCM providers need strong identity mechanisms so we can associate code back to authors confidently. Git commit logs can be easily forged, and signed commits are not in common use. Even with them, you still have no idea who is on the other end of a PR, only that the signature matches. This isn’t just an issue for security. It can also be a licensing nightmare if you don’t know the real author or license of code you’re accepting.

There is value in allowing developers to work anonymously, but there is also a cost. We need to balance this with systems that apply a higher level of scrutiny to anonymous code. We also need to allow other individuals to “vouch for” patches that they’ve examined, maybe similar to how Wikipedia handles anonymous edits.

And finally, all of this needs to be tied together in secure CI/CD systems and platforms that implement binary transparency for public packages. Putting the packaging steps in the hands and laptops of developers leaves way too large an attack surface. The ability to push a package that will run in prod is the same as having root in prod. By moving the build and upload steps into secure CI/CD systems, we can reduce the need to trust individuals.

OK, but What Can I Do Now?

First, start by securing your code as much as possible. Make sure you have copies of every dependency you’re using stored somewhere. Make sure you review all code you’re using, including OSS. Set up and mandate the use of 2FA across your organization. Publish, and actually check the signatures and digests of the software you’re using.

Log enough information in your build system so you can trace back every artifact to the sources. And every deployment to the artifacts. Once you’ve done all of this, you’ll be pretty far ahead of everyone else. You’re not completely safe, though.

That’s where we need to work together. If you’re interested in helping out, there are many ways to get involved, and I’m sure there are a lot of efforts going on. We’re just getting started on several initiatives inside the Continuous Delivery Foundation, like our new Security SIG. We’re also hoping to make it easier to build and use secure delivery pipelines inside the TektonCD open source project.

We would love your help, no matter your expertise! For example, I’m far from a security expert, but I’ve spent a lot of time working on developer tools and CI/CD systems. Feel free to reach out to me directly if you have any questions or want to get involved. I’m on Twitter and Github.

Jan 14
Love0

From Jenkins: Happy New Year! 2019/2020 edition

By Blog

Originally published in the Jenkins blog by Oleg Nenashev

Jenkins project congratulates all users and contributors with the New Year! Let’s take a look at some changes this year.

NewYear

Highlights

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 🙂

Jenkins 2019 in numbers

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 5 security 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.

Where did we get those stats? GitHub stats came from the CDF DevStats service. These stats include all repositories in the jenkinsci organization and most popular repositories in jenkins-infra, Jenkins X and other organizations/repositories within the project are not included. Other stats came from project reports, component changelogs, Jenkins usage statistics service, plugin releases history.

What’s next?

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!

About the Author – Oleg Nenashev

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

Jan 10
Love0

We can do it! Get involved in 2020

By Blog

By Jacqueline Salinas, Director of Ecosystem & Community

Happy New Year everyone! We are so excited to kick off 2020. We are quickly approaching our first birthday this March, which is a huge milestone for the foundation. 

The CD Foundation appreciates all of the hard work and contribution from the community in 2019, without the collaboration and contributions from you it would have been very challenging to get to the end of Year 1. 

As we mature and grow we want to ensure that collaborating with us is easy. We realized that we needed to have a more streamlined process for collecting & publishing content. Here’s information on how to submit your blogs, case studies, PR/News, Announcements, and Meetups to the marketing folks at the CD Foundation. Let’s make some magic happen this 2020!

Blogs

We get it… you don’t always have the time to run a meetup or travel to a conference or summit. We encourage the community to participate in other ways such as submitting written content. We would love to hear from you. Here’s how to submit your blog in 3 easy steps:

1.     Select your topic and write your blog! Pro tip: Good topics are ones that the community has asked for like project milestones, project roadmap announcements, recaps of community events & conference attendance, etc.

2.     Submit your blog through our form: https://forms.gle/CK12n4BWwuB2eZpD6. Pro tip: Make sure you give us permission to see your shared doc!

3.     Once we receive your submission we will send over a confirmation email and provide you a publishing date, edits & feedback, and we will also collaborate on creating some social media posts to promote your blog through the CD Foundation’s social channels.

Case Studies

Working on something cool? Do you have content that was already published and can get recycled through the CDF as a case study? Get in touch with us and let’s collaborate on a case study. Kick off a conversation with me and schedule some time to chat:  

1.     Drop us a line and set up a 30 min call through my calendly link here: https://calendly.com/jsalinas-cdf and email me at jsalinas@cd.foundation.

PR/News/Announcements

If you are speaking at an event on behalf of the CD Foundation, speaking about CI/CD technologies, recently interviewed, or know of an article that will be published soon? Let us know and we will publish this on our website and social channels. Please get Jesse Casman involved as he is our PR guru.

1.     Send your PR/News/Announcement content here: pr@cd.foundation

Meetups

Are you interested in becoming a Meetup organizer or CDF CI/CD Community Ambassador? No CI/CD Meetup in your city? 

Here is how to request to join the CD Foundation Meetup Network. We sponsor the quarterly fees, and we will support you wherever possible. Please complete this form and you will be on your way to joining our network CI/CD Meetups.

1.     Complete this form to request to create a group in your region: https://forms.gle/ztLU8g126cFzYQhA6

There are other ways to get involved in your local Meetup community! You can also join as a Meetup co-organizer and become part of the CD Foundation’s CI/CD Community Ambassador program. Learn more about the program requirements, benefits, and how to get involved.

1.     Read more about joining the CD Foundation’s CI/CD Community Ambassador program

2.     Apply here!

Newsletters

We are excited to share the latest news with the community about the progress of each project, training & resources, new blog posts, and important updates. We encourage the community to submit content they wish to share with the CI/CD community.

The CD Foundation team will compile all submitted content from the members and community to publish the bulletin on the last week of each month. If you are interested in submitting content here’s how:

1.     Submit your content with this form: https://forms.gle/4BR3QjZWUVrEUPub7

2.     Stay connected with the CD Foundation: https://cd.foundation/stay-connected/

Dec 12
Love0

What’s New in Tekton 0.9

By Blog
By Dan Lorenc
dlorenc@google.com
twitter.com/lorenc_dan


Another 6 weeks, another Tekton release. It’s mostly common knowledge that Tekton’s logo is a robot cat, but it’s lesser known that the releases are named after robots and cats! Each Tekton Pipelines release is given a codename of a type of cat followed by a famous robot.

On Monday, December 2nd, Andrea Frittoli of IBM cut the v0.9.0 release, dubbed “Bengal Bender”. This release contained commits from 21 different individuals. I wanted to take the time to highlight some of the new features and API changes, as well as to point out what much of the “under the covers” work is laying the groundwork for.

So let’s jump in!

New Features and Bug Fixes

“Bengal Bender” includes a solid set of features, bug fixes and performance improvements. Apologies if I missed anything here, this list is simply what I find most exciting.

Script mode!

https://github.com/tektoncd/pipeline/pull/1432

If you were at Kubecon San Diego you might have come away with the impression that Go is the language of the cloud. And while that is true to some extent, good old bash and yaml also play a huge part, especially when it comes to “glue” systems like delivery pipelines.

If you’ve spent much time working with containers, you’ve probably seen a yaml file with something like this in it: 

- name: hello
  image: ubuntu
  command: ['bash']
  args:
  - -c
  - |
      set -ex
      echo "hello"

This is a lot of complicated boilerplate just to run a simple bash script inside a container. And if you’re not deeply familiar with how bash, shells, entrypoints and shebangs all work at the system level, this is a bit opaque. It’s also prone to subtle and confusing bugs. Even if you are familiar with these things, you’ve probably wasted time debugging issues when the shell in your container is set to something you’re not used to, or the entrypoint is overridden, or “bash -c” doesn’t do what you expect.

This makes delivery pipelines harder to write, understand and maintain.

Enter script mode! Inspired by some ideas from Ahmet Alp Balkan, Jason Hall put together a proposal to make it much easier to define tasks that just need to run a simple bash script. Here’s what it looks like:

- name: hello
  image: ubuntu
  script: |
    #!/bin/bash
    echo "hello"

You’ll notice that there are far fewer lines of boilerplate. No more need to specify args, an entrypoint or remember the tricky “-c” part. Just specify the interpreter you want to use and the commands to run. This has already let us simplify dozens of test cases and examples!

Performance

https://github.com/tektoncd/pipeline/pull/1545

Tekton has long suffered from poor performance around starting PipelineRuns. Christie Wilson and I did a debugging/coding session last spring to try to improve this, and identified PVC mounting as a major contributor. Unfortunately, our attempted fix didn’t work and needed to be rolled back.

A more general longer term fix is being handled by Scott Seaward and the re-resources effort, but I decided to take another stab at a short term fix. Fingers crossed that it works, but initial testing shows improvements of anywhere between 5 and 20 seconds per PipelineRun!

API Changes

There have been a few changes to the API as we start to firm things up for a beta release. We’re hoping to get the majority of these breaking changes in over the next few releases so users can start to build production systems on top of stable versions.

The breaking changes in v0.9.0 include:

Standardization of output paths for image digests

Tekton currently provides a mechanism to store the digests of container images built by Tasks. This mechanism predated the PipelineResource subsystem, and required Task authors to write these digests to a specific location at /builder/image-outputs. This change moves that to the standard path for output resources, at /workspace/output/<resource-name>.

Simplification of the cluster resource

Cluster PipelineResources make deploying and working with Kubernetes clusters from within Tasks simple. They provide mechanisms for users to declare where a cluster endpoint is and how to authenticate with it. Then, during Task execution, they automatically configure a .kubeconfig file so Kubernetes tooling can find that cluster. This release contained a few changes to make these cluster resources easier to work with.

Previously, users had to specify a name parameter twice: once in the resource name and once as a parameter to the resource. The second parameter has been removed.

Ground Work

Following the age-old programming advice above, most of the work contained in each Tekton release is in service of features that won’t be exposed until a later release. Digging into the commit log shows a detailed picture of what the community is working toward.

Here’s my editorialized version of what’s coming soon 🙂

Revamped PipelineResources

A lot of work went into cleaning up the existing PipelineResource subsystem, including the interface exposed to PipelineResource types and the types themselves. Getting these both solid will form the basis for the larger Re-resources effort, which is currently underway. This project will make the resource types extensible, allowing anyone to add and use their own types. It will also hopefully leave us with some embeddable components, so that other systems can make use of Tekton PipelineResources and the coming catalog.

API Versioning

One of the most important steps in shipping a stable API is figuring out how to make changes in a backwards compatible way. No API is perfect, so the ability to upgrade one is paramount. Vincent Demeester and his colleagues at Red Hat have been hard at work designing and implementing an API versioning system that will allow users to upgrade Tekton API versions without breaking existing workloads. This will be key to the coming beta release.

Wrapping Up

The Tekton project has been amazing to watch grow. This post only details the changes in the Tekton Pipelines release, but there has also been some awesome work done in the Triggers, CLI and Dashboard projects. Triggers now support out-of-the-box Github and Gitlab validation. The CLI has improved support for creating PipelineResources and starting Tasks interactively. Visualization is coming soon to the Dashboard! I’d like to thank everyone that has made Tekton what it is today.

The Tekton community has been hard at work shipping the right APIs and components to build cloud-native software delivery systems. If you’re using Tekton, or interested in learning more about Tekton, we’d love to hear from you. Please consider joining the community, becoming a Tekton Friend or contributing directly. 

Dec 04
Love0

Fujitsu Joins Continuous Delivery Foundation As Premier Member

By Announcement, Blog

Japanese Global 500 IT services provider committed to providing leadership, helping to further accelerate development of open source CI/CD tools and methodologies

San Francisco, December 4, 2019 – The Continuous Delivery Foundation (CDF), the vendor-neutral home for many of the fastest-growing projects for continuous delivery, today announced that Fujitsu has joined the CDF as a premier member.

Fujitsu joins CDF premier members such as Cloudbees, IBM, Google, CapitalOne, CircleCI, jFrog, Huawei, Netflix, and Salesforce in working together to make continuous delivery tools and processes as accessible and reliable as possible and to grow the overall ecosystem.

“We are pleased to join the CD Foundation. We have been involved in the development and deployment of CI/CD technologies for many years, and believe strengthening an overall structure for CI/CD governance and management directly benefits the overall industry, software developers, and Fujitsu customers worldwide,” said Katsuhisa Ohta, Director of SOFTWARE BUSINESS UNIT, Fujitsu. “The CD Foundation is the right type of organization to help steer the course of development in the continuous delivery space. We look forward to participating actively.”

Open source technologies such as Jenkins, JenkinsX, Spinnaker and Tekton, which are hosted by the CDF, help development teams from companies of all sizes and industries improve their speed and productivity when creating cloud-native, legacy infrastructure, mobile, IoT, and bare metal applications.

 “We’re thrilled to be working with Fujitsu as we aim to help enterprises worldwide accelerate the adoption of continuous delivery technologies and best practices as quickly and easily as possible,” said Dan Lopez, CDF program manager. “With containers, microservices and Kubernetes on the rise, Fujitsu and other CDF members have a key role to play in growing and sustaining the CI/CD ecosystem.”

Fujitsu is the leading Japanese information and communication technology (ICT) company, offering a full range of technology products, solutions, and services. Fujitsu is also an established leader in implementing continuous delivery practices and tools to empower development teams to achieve faster, more frequent release cycles. Fujitsu will help build industry specifications and guidance around pipelines, workflows and other CI/CD areas, as well as provide foundational support for CI/CD tools.

CDF members have hosted multiple Continuous Delivery events this year, including events co-located with KubeCon + CloudNativeCon + Open Source Summit China and the Continuous Delivery Summit, co-located during KubeCon + CloudNativeCon North America 2019.

Additional CDF Resources

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) serves as the vendor-neutral home of many of the fastest-growing projects for continuous delivery, including Jenkins, Jenkins X, Tekton, and Spinnaker, as well as fosters collaboration between the industry’s top developers, end users and vendors to further continuous delivery best practices. The CDF is part of the Linux Foundation, a nonprofit organization. For more information about the CDF, please visit https://cd.foundation.

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Nov 25
Love0

A View from CD Summit and KubeCon: The CD Foundation Begins to Build a Community

By Blog

By Tracy Ragan, CEO DeployHub, CD Foundation Board Member, November 21st, 2019

CD Summit and KubeCon are over. As I sit here at our booth on the last day of KubeCon 2019, I reflect on the great work the CD Foundation (CDF) has done to begin building a community of Continuous Delivery experts and users. We have had an amazing week and must give a shout out of thanks to our ‘big brother’ the CNCF for providing a co-located even for our first North American CD Summit.

In case you were not able to attend this truly amazing conference, let me update you on the week of work and fun. 

We started Monday morning with the first North American CD Summit. We released a press announcement that covered our current progress around building community and adding new members. From there we began to see our conference room begin to fill-up. At one point during the morning, Tracy Miranda, conference MC, had to ask us to shift seats to make sure everyone had a place to sit down as there were so many people standing in the back of the room. As I was the front row, I had no idea what was occurring behind me. Our first North American CD Summit had sold out.

Sweeeeet!

So facing a sold out day everyone knew they had to bring their ‘A-game’ to the show. We had some truly amazing presentations by end users, member companies, CDF Board members and experts. After a full day of presentations, the room was still full with only a few empty seats. In other words, everyone stayed for the full CD Summit. 

We ended the evening with a party hosted by JFRog, WhiteSoure, DeployHub and Puppet. And what a great time we had. Open bar, table topics to stimulate conversation, cheese board and raffle prizes. CD Summit attendees like to party. 

And then we got to work. The Budget Committee, Strategy Committee and the Outreach Committee had their first face-to-face working sessions. We got to meet the new Director of Ecosystems, Jacqueline Salinas. A focus around interoperability was reinforced as a primary talking point. We have started to further clarify and implement the CD Foundation’s Governing Board 9 Strategic Goals for 2020.

Overall, it was a powerful CD Summit and a great way to end 2019, even though there is yet one more event to attend, DevOps World in Lisbon Portugal. Have a fun week in Lisbon if you lucky enough to attend that event. And we will see the rest of you at your next local CD Foundation Meetup.

Nov 15
Love0

Broader Scope for Meetups, More Opportunities for You to Get Involved!

By Blog

By Jacqueline Salinas, Director of Ecosystem

The CD Foundation (CDF) and premier member Cloudbees are announcing the transition of Jenkins Area Meetups (JAMs) to CI/CD Meetups. This is an important change. Under the CDF umbrella, the CI/CD community will be able to cover a broader range of topics and technologies that will include Spinnaker, Tekton, or general CI/CD. Our goal for this transition is to grow and foster collaboration within the CI/CD community.

How Do I Get Involved?

Want to join an existing meetup? There are over 106 groups in 39 countries with a total of over 34,000 members, find one near you: https://www.meetup.com/pro/cicd-cdf

Want to start a meetup? Drop me a line, I’d love to hear your idea: jsalinas@contractor.linuxfoundation.org

Thank you!

I just want to express my gratitude to the open source community. The Continuous Delivery Foundation (CDF) would not be here about to host our first North America CD Summit on November 18th at Kubecon 2019 San Diego without your contributions. 

Since the launch of the CD Foundation in March of 2019 our charter has been to serve as the vendor-neutral home for the most important open source projects for continuous delivery and specifications to expedite the release pipeline process. The first projects to be hosted by the CDF include Jenkins, Jenkins X, Spinnaker, and Tekton. Our goal at the CDF is to help facilitate an open governance model that encourages participation and technical contribution from the community. The CDF will provide a framework for long-term stewardship and sustainability for CI/CD tools part of the foundation. 

Our first step towards this was to ask the existing JAMs organizers to work with us to transition the Jenkins Meetup Pro account to CDF. This means each meetup organizer has more tools and options within meetup.com for organizing meetups and connecting with their local community. You can create customized mailing lists, integrate with Mailchimp, and track the growth of members and RSVPs over time. The overall Meetup Pro account has been rebranded to CDF. JAM organizers are welcomed to transition their meetup to CI/CD to include all four projects, but by no means are they under any obligation to do so. 

We cannot wait to see our community grow and what 2020 has to offer!

Thanks!

Jacqueline Salinas, Director of Ecosystem

Nov 15
Love0

A Year of Tekton

By Blog

Author: Dan Lorenc (dlorenc@google.com, twitter.com/lorenc_dan, github.com/dlorenc)

Last year at Kubecon Seattle, Tekton was just an idea in the heads of a few people, and a bit of code inside knative/build-pipeline. Fast forward to today, and we have a thriving community, independent governance inside a great foundation, and we’re quickly approaching our beta release! This year has flown by, so I wanted to highlight some of the original goals of the Tekton project, and some of the milestones we’ve hit toward them.

The Start

When Christie, Jason and I started sketching out the original Tekton APIs on a whiteboard in San Francisco, we had a straightforward goal in mind: make the hard parts of building CI/CD systems easy. There are already dozens of CI/CD systems designed to run on kubernetes, and for the most part they all have to build the same basic infrastructure before they can start solving customer problems. Kubernetes makes scheduling, orchestration and infrastructure management easier than anyone could have imagined, but it still leaves users with a few pieces to assemble before they can use it as an application delivery platform.

These were some of the original whiteboard sketches on what later became the Tekton Pipeline CRD.

Things like basic DAG orchestration, artifact management, and even reliable log storage are outside the bounds of the core Kubernetes APIs. Our plan was to use the new Custom Resource Definition feature to try to define a few more “nouns”, on top of the existing Kubernetes primitives, that were better suited for Continuous Delivery workloads. In doing so, we would make it easier for people and trans to create delivery systems designed for their exact use cases, while making sure the underlying primitives allowed for some degree of compatibility.

Vague ideas are great, but it’s much more productive to collaborate with others when you have something concrete to share and get feedback on. So in August of 2018, we released the sketch and principles we used to design it on knative-dev and to a few other interested parties. The feedback was amazing. The core pipeline team on Jenkins at Cloudbees jumped in with some hard earned lessons from their experience working on the most widely used orchestration system in history. The Concourse team at Pivotal helped redesign our extensibility system based on what they learned from the successful Concourse resource model.

Then we got to work building it all out! Our goal must have really resonated with others, because we could really feel the power of open source from day one. Even when there were only a few of us working together at Google, we were part of a much larger effort. We really wouldn’t be here today without the help of our contributors, maintainers and governing committee members.

A New Home

Around the time we prepared for our first release, it started to become obvious that Tekton (then called knative/build-pipeline) needed its own home. The knative brand and community helped immensely, but Tekton was meant to provide CI/CD for everyone – not just serverless or even kubernetes users. So in February of 2019, we decided to split out the project, name it “Tekton” and donate it to the newly-forming Continuous Delivery Foundation just in time for the 0.1.0 release. 

Kim Lewandowski announcing Tekton at the Open Source Leadership Summit

Open source, governance, and communities are hard. The move out of knative and into a new foundation was a big change for the project, but has proven worth the effort! Tekton still works great with other knative components, but has had the chance to grow its own community and evolve to a spot that its users need. Thanks to the community, Tekton has expanded into multiple projects like the Dashboard and CLI, and in Tekton Pipelines we have been so lucky to gain the expertise of folks like Vincent Demeester and Andrea Frittoli.

The rest of this year has felt like a blur, but I wanted to call out some major milestones we hit:

  • March – The first Tekton Pipelines release (v0.2.0) using Tekton itself!
  • June – First release of the Tekton CLI!
  • July – The first Tekton Pipelines release (v0.5.0) by a community member not at Google!
  • July – Tekton Friends repo created! 
  • August – First release of the Tekton Dashboard!
  • September – First Triggers release!
  • October – Tekton passed 100 contributors in October!

What’s Coming Next?

We’re rapidly approaching the first Tekton beta release! As part of this effort, we evaluated our API surface and identified quite a few areas that need hardening. This includes finishing up the table-stakes requirements for a CI/CD platform – things like triggers, metadata storage and building up our catalog. The Triggers v0.1.0 release has made Tekton usable in so many new ways, and we’re just getting started there still! 

Scott Seaward has has just started work on refactoring PipelineResources into an extensible system that will form the basis for the Tekton catalog, and Jason Hall is working on a metadata storage system that will help power some new ideas around software supply chain management.

If you’d like to get involved in the Tekton project, you can find us on Github, Slack or our email list . We’ll also be at Kubecon next week! Come attend one of the many sessions or the CD Summit. Here’s to Tekton in 2020!