I have, I've just been informed that I have a two hour talk.
So we're going to use that, we're going to use that time wisely.
Hopefully we also have like a minute.
So I can't start talking with the talk until for another minute.
So with that, who's, this is your first time at FOSDEM.
I'm also raising my hands for this first time, tried for years and finally got here.
So cool, glad you're all here.
So now it's like 25 seconds, we have to kind of just whatever.
Yeah, everybody awake?
Who, what was the latest you were out?
Like who was, who was out, who went to bed at like 10?
Okay, good, nobody.
And that doesn't mean 10 this morning, when after this and just been up.
Who was, who went to bed after midnight?
One, two, three, three, 15.
That was three, 15.
Four, are you, you're still awake.
You're still good.
Okay.
All right, so we are, we're going to start now.
Hi, I'm Jeremy.
We're going to talk about streamlining developer experience, power of CICD standardization
and interoperability.
Really going to kind of touch on when we think about developer experience, how,
what's kind of the role of CICD in that and how it fits within all of the different kind
of tools and systems that we use.
So I'm going to talk about that.
A quick note, I did use on a fair amount of these slides.
Because I had evidently time on my hands.
I used chat, GBT and Dahli for the images.
So that is a very interesting, don't, don't go into it thinking you're going to get exactly
what you want.
As you'll see on some of the slides, it's a little weird, but why not?
So we're going to jump into that, figured I'd try something new.
Okay, so you said, my name is Jeremy Meese.
I'm the co-founder of a kind of a stealth DevEx startup right now.
Hopefully we'll have some news in the next couple months.
But yes, so Jeremy Meese, I've done, I've been in tech for a couple decades.
Previously, most recently, I was at CircleCI for about three and a half years, running
the DevRel and community team, doing a lot of talking around CICD and stuff.
So that's me.
Now I did have some early feedback on the title of this talk.
So Gray had a lot to say around, this is probably heretical, what I'm going to talk about.
I don't know about that.
Heresy, but I felt that was kind of harsh.
He hadn't even heard the talk and already he's given some feedback.
But we're going to kind of talk about this evolving landscape of software development,
especially in the modern world.
If you've ever seen the CNCF landscape, could not even fit on one slide.
I mean, it's fit on one slide, but there's no way you're going to read it.
That's how big that's evolved.
I really should have had a slide that showed some progression over time.
But when you think about, this was a couple of days ago.
I'm sure it's grown in that time.
But continuous integration has a good, when you kind of zoom in, it has a good section
of that.
And it stands really as kind of this, CICD does, stands as this kind of transformative
pillar that kind of has reshaped how we look at software and how we look at deployments
and how we look at delivering quality software to, hopefully quality software, to the users,
to the companies and such.
And kind of driving that very experience.
I also put out, kind of feel, when we think about developer experience, what is the kind
of shortened version of that?
And we're going to use DevX.
The internet has spoken, so we're going to use DevX, not DX.
So you all say DevX for short, instead of saying all of developer experience over the
next three hours, I think we have.
Okay.
So developer experience, kind of defining it, it really kind of encompasses the journey
of the developers as they're learning and deploying technology, whether that's software,
whether that's even hardware kind of fits into that.
And when you have a successful developer experience, it really is focusing on eliminating the obstacles
that hinder developer or a practitioner from being successful in their endeavors, whatever
they're trying to do.
Now CICD's transformative influence that we've seen on the developer experience is really
pretty profound.
Because we've had kind of this dynamic shift in how developers over the years have collaborated,
how they create, you know, how they deliver software.
And by automating, you know, the pipelines and like the integration and testing, deployment
processes, all those things, it really is to empower developers to really gather the
feedback necessary with those feedback loops, having faster ones, so that they can improve
the code quality and the ability to continue to iterate swiftly.
That is not a Taylor Swift drop, it's just iterate swiftly.
But by streamlining workflows, that helps to reduce a lot of the friction that we see,
provides a lot of intuitive tools.
And so you have like this good DevX empowers developers to focus on creating that high
quality code we talked about, fostering the innovation and really eliminating and contributing
to, you know, faster, more, ultimately contributing to faster, more reliable software delivery.
So we're going to kind of hone in on the two of the critical pieces of what that looks
like in CICD with standardization and interoperability.
So from the CICD standardization side, that really brings the consistency necessary to
your pipeline.
So that you can reduce the friction, you can enhance the collaboration between your different
coworkers or different teams.
So we're going to also look in this at a few open source tools.
We're going to look at Argo and Flux.
I'm not going to bring up any demos or anything, but we're going to talk about some of the
features that they have that really work well with this kind of standardization idea of
standardizing processes and how you deliver good software that way.
Then we're also going to talk about the interoperability side, which is kind of ensures a seamless
integration across multiple different tool sets, everything from observability to, you
know, different, potentially different frameworks.
You have all the different tools that kind of integrate with that.
So with that, we'll look at, you know, some of the features that Spinnaker has and also
tools like Backstage, how they kind of work with the developer experience on the interoperability
side, bridging kind of tool chain gaps and such.
At the end kind of whole thing, we're going to kind of really dive in, not really dive,
but just kind of summarize how that both of those things play a pivotal role in optimizing
developer experience and improving, you know, overall productivity, which is really kind
of the idea.
All right, so the standardization side, that really means we're trying to minimize the
variability, reducing all the errors, fostering environment where developers can, you know,
again, collaborate.
That's efficient collaboration.
So when you're standardizing that, you're kind of defining clear, repeatable, no, not
yet, clear, repeatable code integration, testing, deployment processes, all of those
kind of things when you standardize that ensures that you're having like your pipelines are
streamlined, the developer process becomes a lot more, a lot smoother for everyone that's
interacting with what you're trying to do, whether you're building something internally
or for external users or both.
So when we think about that kind of the steps for what kind of better practices look like
for that, we start with kind of assessment and analysis with that.
So here you're really kind of looking at your current CI CD pipelines.
You want to understand kind of existing workflows, the tools, all the processes that you're using
to identify the pain points, the bottlenecks, and then, you know, areas where standardization
really is needed.
And then the next kind of thing with that is you're going to kind of look at all the specific
requirements that are in place and the constraints of your projects and the development of that
first step there.
Then when you're defining this, you're really going to kind of define the goals and objectives
that you're trying to achieve with your pipeline standardization.
And those goals are really going to try and align with the overall dev strategy that you
have and some of the organization business objectives.
You don't want to stray away from that.
And that also kind of helps you start to kind of identify those KPIs that are going to really
measure what success looks like for you in your development process.
Usually that looks like you're probably going to try and reduce deployment times or decrease,
you know, error rates.
We always want to try and obviously decrease error rates.
Then you want to look at what the tools and practices are going to be for your CI CD standardization.
So, you know, things are going to align with your organization's needs and goals.
So that's things like Jenkins, GitLab, CI CD.
There's other cloud native solutions.
AWS code pipeline.
There's I think Team City, I think is on the cloud side.
There's a bunch of different options there.
But you want to make sure you have those tools and practices that help you achieve those
goals.
There's some standardized templates for pipelines defining those essential stages of build,
test, deploy, what's that going to look like for you.
And then kind of what a standard configuration would be for all of your pipelines.
And then you're also going to enforce a lot of those coding standards for CI CD, those
configurations ensuring that there is consistency and readability for everything that you're
doing.
So somebody can come in and understand exactly what you're trying to do and you don't have
to spend a lot of time kind of.
I mean, there's going to be onboarding, but you want to make it as standardized and relatively
simple as possible.
And then on the documentation training, which is kind of touched on quickly, you want to
make sure that documentation is comprehensive, that you're outlining all of the standardized
processes that you have in place.
Make sure everybody is aware of how you work, including how you work with your workflows.
How do you, you know, what's your standard configuration?
What are some of those better practices that you're using inside your organization?
Make sure that's documented.
And then you're also providing a lot of those training sessions for your dev teams and your
support teams that work with the dev teams, ensuring that they're understanding and can
be really effective in as they use your CI CD tooling and all those templates that get
created.
Then you kind of move into the version control side.
You want to make sure you're storing those pipeline configs in some kind of VCS, you
know, Git, GitLab, GitHub, whatever.
That practice there is really going to ensure that your configurations are versioned so
you know you can go back to something, you know what the changes were, you can trace
where potential errors are, and you can, like I said, revert, you can easily get back to
something if you need to.
And then implement your branching and pull request strategies.
It should mirror what you're already doing in your standard that you've already hopefully
documented that we just talked about, but making sure that all of the, you think about
the standard templates and such is that they're all kind of following in that same path of
branching, pull request and such.
And then automated testing.
Since this is testing room, we want to make sure we talk about testing.
You want to make sure you're integrating your automated testing and validation into the
pipeline and all those templates to ensure that, you know, those standardized configs
produce your expected results.
Don't just create a standardized template and not test out to make sure that works.
Otherwise you're going to create problems downstream.
Another great opportunity to put code reviews in place.
Build out your standardized templates and then start code reviews.
Make sure that you're not missing something.
Bring more eyes to it.
Validate that, catch those errors before they become an issue downstream.
Okay.
And then continuous monitoring, continuous integration side of this or continuous improvement.
Make sure you're monitoring and having alerting in your CIECD pipeline so you're detecting
the issues bottlenecks in real time before they become an issue.
Establish kind of this culture of kind of continuous improvement.
So that means you're regularly reviewing, updating those, you know, those pipelines based
on the feedback and evolving kind of framework that your projects and pipelines go through.
Make sure you're not, those templates aren't being left behind.
Also governance and compliance is very much an important part of the CIECD standardization.
So make sure your policies are enforcing pipelines, the standardized pipelines and compliance
with industry regs, regulations or, you know, some internal or external standards that are
in place.
Make sure that you're accounting for those.
Really audit and assess how you are adhering to those to make sure that you continue to
improve there as well.
Scaling and adaptation, ensuring that, you know, those standardized pipeline templates
are something that can scale and adapt to the different project types that you have.
Every team or, you know, an organization probably has different types of projects that you're
all working on.
So make sure those templates are easily applied to different, you know, different things that
you're doing, different sizes, different technologies that might be in place inside your organization
or that you're developing for external.
Maintaining the flexibility kind of helps there to accommodate the unique requirements
that each project is going to have, but also making sure you're still adhering to your
standardized core practices.
And then there's that feedback loop.
Very much a part of DevOps is feedback loop.
Even more, that's part of why continuous integration and continuous deployment is there, is it
helps you give you that feedback loop.
So have an environment where, you know, developers can really collaborate and provide that feedback
and contribute to continuing to improve those standard practices and then continuously kind
of communicate the benefits of those to outside your organization.
Make sure everybody knows what you're working on and knows that the achievements that you've
had really helps kind of drive more collaboration, drives more obviously awareness of what your
organization is doing, but also brings a lot of praise to the teams internally.
So by kind of putting these steps, these kind of best practices on the standardization side,
organizations really can kind of implement more efficient, consistent workflows so that
the developer experience on the continuous integration, I'm sorry, on the standardization
side is really you start to see those, the results of that.
So we're going to right now kind of look at kind of Argo and Flux, just some of the features
that they have that help implement some of these better CI CD practices for standardization.
So Argo is reusable workflows so orgs, they can really define reusable workflow templates
that set up the standard sequences for CI CD like build, test, deploy so that devs can
reuse those things across projects, not just within your, the project you're working now,
but you can use reuse those templates elsewhere.
Argo also follows GitOps principles.
So your configs, workflows, they're managed as code in Git repos, ensuring everything's
versioned, like I said, traceable, easy processes to kind of collab amongst dev teams is really
kind of a core piece of that GitOps.
And then the way that they manage artifacts, Argo supports managing and storing those artifacts
like Docker images as part of the CI CD process so that you can make sure that the right artifacts
are used in the right situation and deployed across the environments and they can be used
as inputs in subsequent steps as part of your template.
So those are some things that Argo has in place specifically.
And then from Flux, we have the declarative config model that they can operate on where
systems are, you know, their desired state of how they're going to exist as a system
is defined in code.
This is what orgs can kind of define and enforce already those standardized practices in a VCS
system, ensuring that you can kind of track things consistently.
On the continuous synchronization side, they allow you to kind of continuously synchronize
the desired state in your Git repos with the actual state of, for instance, like your Kubernetes
clusters.
So that is that changes, everything can continuously be replicated so that you have a standard config
and deployments and that are consistent across your environments.
And then there's the policy side.
So that's kind of where we have, does it say that flagger?
Yeah.
So that's kind of the feature flag.
So Flux has feature flag capabilities through Flagger, which is a part of that, so that
you can deploy and allow orgs to define the different rules for how things get deployed,
either different sets of things or to different users.
So you can really do a lot of that A-B testing if you think about progressive delivery.
It's that kind of thing.
Yeah.
So who here uses Flux?
Okay.
What about Argo?
Okay.
So about, I think there was some overlap.
Good.
So when we want to achieve these kind of standardized workflows, kind of the summary here is like
achieving that.
You want to make sure your templates with Argo and Flux, they allow for the standardized
templates and definitions so that everything is, all your orgs have an established baseline
to work with for consistency.
There's also integrations with VCS, CI-CD tooling so that you have your configs are maintained
and accessible to all, which is really important, bringing visibility to what you're doing.
And then on the documentation and training side, it's really essential to make sure that
you've got the docs and training standardized and that you have documents, that you have
the docs and trainings for the things that you've standardized.
So make sure you've done both so that orgs can really be responsible for making sure
that dev teams and even support teams understand how these standard processes are.
Continuous improvement really kind of fosters the culture that's really necessary to achieve
a good developer experience so that you have, everything's regularly reviewed, the workflows
are updated, you're getting feedback, improvements are continuously happening.
Making sure that, again, developer experience is high on that list.
Alright, interoperability in CI-CD is, you know, system, it refers to the ability of
different tools, technologies, components within kind of the CI-CD ecosystem are able
to work effectively together.
So that means, you know, the various parts like, you know, the pipeline, source code,
repositories, build systems, testing frameworks, deployment platforms, monitoring tools, all
those things are able to interact with each other in a way that ensures that you're able
to see what's happening.
So if the data is effectively kind of exchanged and that there's, you know, not really any
compatibility issues or disruptions to kind of your workflows.
So kind of the way that that looks like, we think about, so there's a collaboration
side that gives flexibility and choice that you, when you are looking, trying to implement
interoperability in your environment really enables dev teams to use the best tool for
the job so that you don't have to work with the vendor lock-ins, give them that flexibility
to use what works best.
And then there is the various tool preferences that are there that Oregon company has.
And so you want to make sure with the enhanced collaboration that all those different various
tools are not a blocker to success.
Excuse me, that also ensures, you know, smooth interaction.
You know, also the collaboration comes is.
And then, it's a really important, yeah, really important side of that to make sure
that you're, you know, able to integrate the interoperability kind of really enforces that
better use utilization of your resources.
So your orgs can make efficient use of your existing infra, infrastructure and tools.
So you should not always have to build something new.
If you have systems that are interacting together, the system, the tools, you're not waste, you're
not being wasteful.
Yeah, reason the components and scripts, saving cost.
The next side of that, scalability and growth.
So as organizations are scaling, they're adopting new tech, which happens consistently.
Interoperability really ensures that your CI CD systems can adapt and expand as necessary
to kind of support incorporating the new tools and processes and ideas and workflows, all
of that into your, the way you all work as a team.
And then, yeah, cross platform deployments.
So interoperability advantage there is that, you know, when you, in this existing kind
of multi cloud hybrid kind of environments that are out there now, it really promotes
kind of this unified approach that you don't, that doesn't have to be a blocker to having
all these different systems.
You have it all together, ensuring that the data gets transferred well.
Also kind of promotes a unified deployment and infrastructure management.
And then troubleshooting debugging.
I knew there was another one there.
So when issues kind of are arising, this interop enables, you know, this seamless data sharing
between all the different tools and process.
I've seen a growth, like, it's amazing, but it's been a very astronomical growth of the
average number of like SaaS tools that are in place in a organization into the hundreds
on average by companies.
And so like being able to look at all the tools and be able to troubleshoot those and
have everything working together is a huge kind of game changer for kind of looking at
better issue ID, troubleshooting, resolution and such.
All right, so in essence, you know, this, when CICD systems are interacting together,
this interoperability acts as really that bridge.
It's one of those chat-chitty created images that kind of works.
But you know, connecting all the different parts of your dev and delivery processes together,
fostering, you know, we talked about collaboration, ensuring teams can work cohesively, efficiently.
All that stuff is tied into the importance of, you know, interop.
So looking at like how Spinnaker and Backstage do this, the, on Spinnaker's side, the, there
we go, integration with cloud providers.
So Spinnaker allows you to pretty much integrate with anything you want so that you have this
consistent interface itself for deploying, managing across platforms, ensuring seamless
targeting of the different environments that are in place by devs, allowing them to like
choose what works best.
Don't tie them into one specific tool that is that whole, that little analogy of, you
know, hammering a square peg into a round hole.
And then integration with VCS systems.
Spinnaker, you know, works across, you know, really can work with whatever so that you
can kind of trigger your deployment pipelines directly from your repositories and automate
that release process, reducing manual intervention.
And then extensible integrations.
So you know, having an extensible architecture supports a lot of different integrations, which
allows teams to connect with, you know, again, various set of tools like the monitoring,
incident management scripts, those things, and really ensures that Spinnaker really
seamlessly fits into the org.
And yeah, tool sets fit into your org's existing tool sets, requirements, workflows and such.
And then artifact management.
We talked about, you know, Argo has that.
Spinnaker also kind of lets you kind of interact with those, integrate with different repos,
artifact repos.
So you got Docker Hub, there's Artifactory, I'm trying to think those are the two that
come to mind.
Assist really in managing those artifacts, ensuring that, you know, the right things
are consistently used in your deployments.
And then there is the pipeline abstraction.
The, helps you kind of abstract the deployments, making the process more flexible and adaptable
to what you're trying to do.
Developers really can start to reuse those templates that you've created, making an
adaptation easier as the projects evolve themselves, and those requirements.
And so that bridge between, you know, the abstraction and flexibility ensures Spinnaker
can kind of cater to different various deployment scenarios.
So that's the Spinnaker side.
We think about backstage.
Backstage has, you know, it integrates with a lot of CI CD tools and other things.
We're talking about CI CD here.
And so it integrates with a lot of them, like Jenkins, sort of CI, GitHub actions, Flux,
Argo.
All of those things brings that visibility.
And so having that interoperability with pretty much anything allows developers to visualize
and manage what's going on in their pipelines directly from backstage and not having to
go to multiple systems.
You can do it all in one.
So there's kind of that unified single pane of glass view of the entire kind of dev workflow.
Service Categlog integration with backstage kind of acts as that service catalog, helping
teams manage, discover the services and apps and such that they can use.
And so that interoperability with all the different systems ensures that the information
in your CI CD is integrated into that service catalog itself so that they know that easier
for teams to understand service status, history.
The history is really important to be able to go back and see what's happened over time
and see some trends.
Yeah, it has a really good plug-in ecosystem.
So, you know, that extensible architecture across all the different custom plugins that
you can create that maybe your community has done.
All that stuff can help bring better visibility to things you do.
And then customization theming that comes in place, allowing repos to kind of customize
the UI and theme that's in place.
That may seem like a small thing, but when you're trying to get your organization to
buy off to use something like backstage or things like it, having that ability to customize
the look and feel satisfies a lot of those branding requirements that companies have,
marketing departments kind of do.
So it's important to have that kind of flexibility ensures that your org is going to be able
to be flexible and use what's there.
All right, so Spinnaker and backstage, they both kind of prioritize flexibility, adaptability,
allowing organizations really to integrate with the kind of the diverse tool sets that
are out there and accommodate the various needs that developers have.
Bridging those gaps between the different tech and systems, it acts as kind of that central
hub that connects those parts, enhances the flexibility of your CI CD pipelines and developer
workflows and is ultimately going to kind of promote more efficiencies and collaborative
development environment.
All right, so the organizations often use kind of this mix of tool sets.
And there's some of these challenges that come in with when you're trying to implement
this.
Is that that mix?
And each of them have their own ecosystem, APIs, such data format schema differences,
tools are using a lot of different data form.
They're not all unified themselves.
That's kind of their niche is having something different than everybody else.
So that presents a challenge.
Authentication and authorization, like those themselves also present a lot of challenges
of how do you not only manage the access to all these different tools, but how do they,
you know, you have APIs, different APIs going back and forth.
How do you kind of work with that?
Versioning and compatibility, that also is something that like tools change.
New versions come out.
They can break the, you know, breaking changes that either could have been avoided or not.
It doesn't matter.
You're trying to use them and now you have something that doesn't work.
So having, you know, that is a real challenge.
And then lack of documentation.
We've all seen it.
API that's on version two and their docs are on version 1.1 and they haven't updated
or they haven't changed one thing and it breaks that.
That often is a challenge to try and work with all these different systems and in some
cases building your own integrations between those systems can really kind of get hit with
lack of documentation.
But there are ways to overcome those with us.
So using unified config formats and how you define your deployment pipelines that are
documented and forced for all the tools, libraries that are associated can then automatically
kind of convert between the formats, ensuring there's data consistency, compatibility.
There's API gateways that really translate the data between the systems for consistency,
simplifying, you know, off and authorization access across all the different tool sets.
Helps you maintain version compatibility and it's important to kind of use a version
compatibility matrix, matrices, so that you can see, you know, track it all down and see
what works with each other to help you make better decisions.
Make sure you've documented.
Oh, time out.
Okay.
So that's good there on that piece.
The last little bit just we think about developer experience really important to remove all
the barriers.
So that, thank you.