cdfoundation / sig-interoperability

CDF Interoperability SIG

CDF Interoperability SIG

Quick links

• CDF Interoperability SIG
  • Quick links
  • Overview
  • Members
  • New Members
  • Governance
    • SIG Workstreams
  • Communication
  • Meetings

Overview

The emergence of new open technologies and methodologies such as cloud native and microservices has resulted in tremendous advances in various industries and enabled the rapid development and delivery of new features and services to the end-users faster than before. Continuous Integration (CI) and Continuous Delivery (CD) are prerequisites and enablers for organizations to use these technologies and achieve true agility in response to these changes.

The organizations that embrace CI/CD employ various 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. This is perhaps one of the biggest benefits the users get by using open technologies for their CI/CD needs.

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 "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 the 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 risks of outage in their CI/CD pipelines due to the potential changes (ie non-backward changes to the APIs, changes in data models) that happens to the tools in respective projects.

SIG Interoperability will focus on addressing these challenges and further work with projects to achieve a common set of solutions.

SIG Interoperability aims to enable a dialog in the interoperability area by bringing CI/CD users together with the open source projects 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

Members

• Andy Glover (@aglover), Netflix
• Christie Wilson (@bobcatfish), Google
• Eric Sorenson (@ahpook), Puppet
• Fatih Degirmenci (@fdegir), CDFoundation
• FuQiao (@fuqiao123), China Mobile
• Kara de la Marck (@MarckK), Cloudbees
• Priyanka Sharma (@pritianka), Gitlab
• Thanh Ha (@zxiiro), Lumina Networks
• Tracy Miranda (@tracymiranda), Cloudbees
• Wavell Watson (@wavell), Vulk Coop
• Ravi Lachhman (@ravilach), Harness
• Andreas Grimmer (@agrimmer), Dynatrace
• Chun-Hung Hsiao (@chhsia0), D2iQ
• Marky Jackson (@markyjackson), OpsMX
• James Rawlings (@rawlingsj), Cloudbees
• Ramin Akhbari (@rakhbari), Salesforce
• Cameron Motevasselani (@link108), Armory
• Dave Sudia (@thedevelopnik), GoSpotCheck
• Andrea Frittoli (@afrittoli), IBM
• Oliver Nocon (@olivernocon), SAP SE
• Emil Bäckmark (@e-backmark-ericsson), Ericsson
• Vibhav Bobade (@waveywaves), Red Hat
• Jerop Kipruto (@jerop), Google
• Saif Ul Islam (@rubix982), Mapillary
• Ann Marie Fred (@amfred), Red Hat
• Melissa McKay (@mjmckay), JFrog
• Justin Abrahms (@justinabrahms), eBay
• Brett Smith (@xbcsmith), SAS Institute Inc.
• Muktesh Mishra (@mukteshkrmishra), Adobe
• Mainak Mitra (@maimitr](https://github.com/maimitr)), Ericsson

New Members

Membership to SIG Interoperability is open to public and self-declared.

New members are advised to:

• Join the SIG and CDF TOC maillists.
• Join the #sig-interoperability channel on CDF Slack and introduce yourself.
• Go through the README.md document.
• Regularly join the SIG meetings.
• Submit a PR to add yourself to the members list.
• Here are various ways to get involved:
  • Share your thoughts by joining the meetings or by posting to maillist and Slack channel.
  • Add a topic you would like to discuss to the agenda of upcoming meeting.
  • Create a new issue to start gathering feedback and collaborating.
  • Choose an issue where help is needed and comment on it expressing interest.

Governance

SIG Interoperability is a CDF Special Interest Group.

The process SIG Interoperability follows can be seen from here.

Chairs and the TOC Sponsor of the SIG are

• Melissa McKay (@mjmckay), JFrog - Chair
• Dadisi Sanyika (@dsanyika), Apple - Chair
• Dan Lorenc (@dlorenc), Google - TOC Sponsor

SIG Alumni

• Fatih Degirmenci, Ericsson Software Technology, 01/2020-03/2022
• Kara de la Marck, CloudBees/CDF, 06/2020-04/2022
• Justin Abrahms, eBay, 04-2022-06/2023

SIG Workstreams

SIG Interoperability welcomes contributors who take part in the SIG to form workstreams to work on specific areas of interest in a more focused and structured way.

Workstream governance is documented here.

Archived workstreams are:

• Events in CI/CD: now the CDF SIG Events

Communication

SIG Interoperability communication happens via a public mailing list and everyone is welcome to join our open discussions.

SIG Interoperability also uses Slack for additional collaboration opportunities.

• Maillist: https://lists.cd.foundation/g/sig-interoperability
• Slack Channel: #sig-interoperability on CDF Slack

Meetings

SIG Interoperability meets first and third Thursdays at 15:00UTC. (See your timezone here).

• Meeting agenda and minutes: here
• Meeting recordings: here
• Zoom Bridge: here
• Zoom International dial-in numbers: here
• CDF Public Calendar (UTC): here

sig-interoperability's Issues

Add SIG meeting details to the repository

Add SIG meeting details to the repository.

• Meeting frequency/day/time/ according to the result of survey
• A document to keep minutes of past meetings and create agenda for upcoming meetings (docs/meetings.md)
• Link to the working copy of the meeting minutes and agenda on Google Docs
• Link to the public CDF Google Calendar

Slack invitation broken

Just watched the talk on the CD Foundation at FOSDEM. (Really great!)

I wanted to jump into the Slack but it looks like the link isn't working. Here is what I get when I go to the link that's currently in the README:

Could somebody please look into this? Thanks!

Rename repository name to sig-interoperability

Repository was created as sig-Interoperability. (note the capital I)

In order to be in line with how the repos for other CDF SIGs are named, repository needs to be renamed before we start working in it.

Create Initial Roadmap

We as SIG need to work on our roadmap in order to define what areas we can tackle, divide and map them up, and perhaps start workstreams for specific items with people interested to collaborate and contribute to them.

CDF SIG MLOps approach is something we can take a look while working on initial roadmap.

https://github.com/cdfoundation/sig-mlops/blob/master/roadmap/2020/MLOpsRoadmap2020.md

Add LICENSE

Add LICENSE file to the repository.

Add placeholder for SIG Governance Document

SIG governance needs to be documented and made available for the community.

This issue is just adding a placeholder for such a document rather than creating it. The reason for this is that we need to clarify if CDF TOC should have SIG governance documented which all the SIGs are bound or not. If TOC decides to have one, we can refer to it rather than creating our own.

To clarify this, an issue has been created in CDF TOC repository. [0] Depending on the outcome of that discussion, we can then decide what to do.

[0] cdfoundation/toc#70

Document vocabulary used for build stages

Create a mapping of common names for Stages, where a Stage is the unit of work one degree smaller than a Pipeline. While CI/CD Tools and Technologies generally give developers broad leeway in naming and implementing their Stages, agreeing upon some common terms will help develop more pluggable Pipelines.

Update members section to include Github handles

It would be useful to list SIG Members' Github handles so contributors can add them to PRs/issues as reviewer.

This could perhaps be addressed via OWNERS file but we first need to discuss roles.

Add CODEOWNERS to the repository

CODEOWNERS file makes who can review and submit PRs visible to everyone who looks at the repository and contributes.

The information in CODEOWNERS could be seen as duplicate to the members list but this is a small cost comparing to the benefits it has in addition to making reviewers visible. The most important benefit is that everyone in this file is automatically requested for review for the PRs opened for the repository, removing the need to figure it out and manually add them.

See below for more details.

https://help.github.com/en/articles/about-code-owners

Document vocabulary used by CI/CD tools and technologies

Users employ various CI/CD tools and technologies and it would be good to have a document to list various terms used by these tools. Apart from merely documenting the terms, having this together with mapping would help us to communicate with each other as humans to understand what we all mean when we use certain term.

Is "secret detection" just an example of a "scan" pipeline step, or is it its own type of step?

See the conversation here: #81 (comment)

Update SIG communication details

Add slack channel together with CDF slack invite.

How do code linters that also automatically update the code fit into the pipeline steps?

See this comment: #81

Document vocabulary used for build steps

Create a mapping of common names for the various types of build steps (the unit of work two degrees smaller than a build pipeline). While CI/CD Tools and Technologies generally give developers broad leeway in naming and implementing their build steps, agreeing upon some common terms will help develop more pluggable build pipelines.

Is "Maintain" a type of pipeline stage or a type of pipeline?

I originally had this as a pipeline stage:

Maintain Stage

• Semantics: Automatically update or upgrade previously built software. May invoke some or all of the previous stages.
• Aliases: Update, Upgrade
• Inputs: See Above
• Outputs: See Above
• Other Results and Side Effects: Updated documentation and software built, tested, released and deployed. This stage can also update source code repositories, for example, with new Declared Dependencies or Baseline/Composition Information.

But then m-linner-ericsson correctly pointed out that this is not like the others: #76 (comment)

Does this really belong in a different doc where we have examples of different types of pipelines?

Add guidance for new members

While we are waiting for SIG governance topic to be clarified, it would be useful to add a short document to describe how new members can join to SIG and how they can start contributing.

• Membership to the SIG is open to the public and self-declared.
• Open a PR and add yourself to members list if you'd like to be listed as member.
• Join to SIG and TOC maillists and slack channels.
• Join to SIG Meetings.
• Add topics to the meeting agenda or start discussions around things on maillist.