Add a meeting Rate this page

A

uh Hello.

A

Yeah we'll see if more people join today.

B

Yeah they'll be good. uh I noticed that somebody has been updating the meeting notes for today.

A

I haven't seen that.

A

Hello, hello, hello,.

C

Hello shortly, thanks for joining today,.

C

Everywhere it's another minute say someone else is joining.

C

Okay,.

C

So I guess we can get started.

C

um Can folks is still hear me?

C

Yes,.

C

Absolutely.

B

um

C

Great um just um I took the liberty of putting a bunch of things on the rcmd document, the agenda for today um yeah but feel free to point out. If there is something that you'd like to discuss for the story, I missed at the previous meeting. So I know there was a discussion about generating.

C

The code so included one point of that as well.

C

Maybe I should charity.

C

Okay, I'll just go ahead to stop me if not making sense. um Okay. The first thing I wanted to mention- I guess everyone here already knows- is that we picked the name for the protocols. It's cd events and the dns name, though, is still not defined, so we have cd events or event cd and yeah, so we need to check which one is available and which not, and we asked the cdf for help that.

B

Is this uh cd is the dns? Is that one you're, the one you type in the browser.

C

Yeah um yeah, basically yeah.

B

um Because the events in themselves usually have reverse cds right, see, dns right.

C

Yes, on the cloud event binding, uh the event should be a reverse dns. um So in that sense I think events.cd would be my my favorite. I steve.

D

And from what I remember andre, I think that was the one that was events.cd was the one that was available um from what we could tell that. Had the best luck for us to grab.

B

I eventually so stupid question there would be. Would people think this is like events um happenings uh in this in the city domain, or do they want to use that for kind of like those type of events, summits and so on?.

A

There is a non-zero chance for that, but I guess that would be more like cd.events, because events is the tld for for dealing with those kind of things. I guess.

D

Yeah, there's always there's always a chance that you're going to get some overlap. The the domain names that are out there are we're running out of them. Basically, the the creativity that you, you have to get very creative these days.

A

We could, of course, as a parallel track, just develop a standard for how to hold like conferences and and things like that in the cd area, and then we can be both. But let's focus on the messaging for now.

D

Yeah, that's how we'll make our money by hosting events.

C

Maybe.

C

um Cool but yeah, so we brought it up with the cdftoc.

C

And I think stevie mentioned that we don't want to do double work and buy a domain and someone names and then transfer it to the cdf. So hopefully we can get help from from there too, to get this registered by the cdf directly or the linux foundation, or this um yeah, and once we have the domain, we should probably update our documentation and sdk and everything. But maybe we can wait until we have a finalized, dns name.

D

And one thing on: um once: we get the domain name and we want to stand up uh a basic website along underneath that I would recommend using uh hugo and doxy as the markdown.

D

We use that for ortelius, and it works really really nice to be able to do pull requests and that type of thing without dealing with you know, wordpress plugins, and things like that. That just is a simpler way to to have a community collaboration on the site.

C

Absolutely so we use for we use similar.

C

I think it's a community version, but it works pretty well so.

C

um We have a new github arc, which is called city events, and we asked the cdf also for help with the logo. Design has to have a nice logo and they sent back a creative brief, um which is this google doc and I started putting something on it and I think someone else added ideas, but uh yeah, um I feel free to contribute to it. I think once we fill, uh we have a satisfactory status, we send it to the cdf and I guess it's an integrative process.

C

So maybe they propose some ideas and you say yes, this direction looks good. This doesn't and continue from there.

C

Okay, um anything else on the name.

C

All right um next, I wanted to briefly talk about the relocation to destiny. Events org, um I guess we created a ddr in the github um we kind of assumed gita is the hosting service. I just wanted to put the question there. We want to use github or gitlab, or else both as a kind of replication mechanism in place.

C

um I think github is good for at least for a starting point just wanted to ask. I think, maybe concern.

D

I would just stick with github, since that's uh what most of the cdf projects are under.

C

Right yeah.

D

Just yeah.

C

I agree.

B

Yeah, it feels a bit weird to if we are using github for the rest of our stuff, that we actually use gitlab for one thing, if it wasn't kind of a transition over to it,.

C

Yeah, I I agree: okay um with that out of the way, so in terms of free pause, my recommendation would be to kind of follow what cloud events do, which I think looks nice and makes sense um so to have like a spec document which would map what we have in the vocabulary: draft folder in our sync events. So we basically host this back there.

C

We could use the spectre for other documents like a community nd or governance nd as well, or we could create a community repo if you want to um and then we could have sdk-star repos for various sdks um and eventually you could have one repo for the website hosting containing basically the doxy and whatever documentation we want to put there.

D

Yeah that that sounds good uh one question on um the license. Does anybody mind if we just use use uh apache 2 for everything.

C

um But that would work for me.

C

I think it's we had this discussion before for the uh sig events, repo and I think most of the places apache 2 is used and I think for consistency. It makes sense to to use apache 2 unless anyone is concerned.

B

Sounds good.

A

Yeah, that's good.

D

I just know when you start creating uh repos, that's one of the things we got to make sure we just drop in there.

C

All right good point um for the poc: that's a folder in these events, repo, I thought. Maybe it would make sense to have one repo with all the plc's one reaper per plc in the new arc. um I don't know you could leave it in the sick events.

C

um Yeah, so my favorite approach, I guess, would be to have one repo at least one ripple in in that new org, so that you it goes along with the uh the rest of the city events uh code.

D

Yeah, I think.

E

The one.

D

Repo would work um best because then you can have uh the read me kind of explain what's in the repo and where to find things instead of jumping around to different repos.

B

How does um cloud events do this? Do they have any.

C

Oh, they don't.

B

Like they don't have any.

C

Poc type of repo in new york.

B

And we could have, I don't know if this good idea, but we could have something called experimental, for example, uh where we put all the extra experimental stuff. What were you doing.

A

Did we also discuss having an experimental concept for the specification itself?

A

I know we discussed something like that, but I don't remember exactly what just so we don't use the name if we also want to use it for experimental extensions to the specification.

D

I think in that, when we talk about the spec itself, that we would instead of being experimental, I think that would be kind of more slated as a draft or you know version you know, 0.1, you know type of designation.

A

Yeah, that's.

D

Pretty good, I think I was.

A

I think I was more thinking about extensions to be honest and that's something else, yeah that makes sense.

C

Okay, but.

D

I think I think for um like you're saying for the the poc um side of things that we mean, like you, have uh experimental at that level like we're, trying out a new like, for example, the deployment, a deploy vocabulary that may fall under an experimental part of the poc.

D

Type of world.

C

Right, yeah and I think for the for this pack, um I have one bullet point underneath it's from afterwards b01.

C

Maybe we we can have a general discussion in life today about how we want to handle versioning um what it means to a certain version number and what kind of stability we we provide. So.

D

Like you know, you start at like version 12, because everybody will take you seriously. Then.

D

Nobody says he had to start at zero.

C

We could start a version.

C

Okay,.

C

We have some code that we wrote for the poc um some adapters for captain and also an experimental controller for tecton. Do we want to gather those into our organization or let them try to maybe move them into target organization? I mean the the techno one is already on the tecton cd.

C

uh The captain of adapters are under mauricio's own account right now we don't have to decide today it was just. We just wanted to bring it up, and if someone has ideas we can discuss.

E

For this I feel like as a user. It makes more sense if it's inside the same like repo for um cd event, so inside maybe like experimental, someone can come and check out uh the poc, and then you know all of the information for that uh that adapter code.

B

Yeah also, it could be good to have it um collected, uh because currently it is a little bit of a kind of like uh I don't know. A cumbersomeness is that when he's trying to set up the poc, um you need to download these ones uh separately.

B

So it could be, for example, that you're. I think it would be good that everything in the plc is collected at once, uh because I did actually run into an occasion when I had. uh I had to pack a puck up and running, but then it's I had to redo some things and it didn't work.

C

Yeah, it makes sense. The only downside of bringing everything together might be over time that the experimental becomes a huge people to download, but I think we are not quite there yet. So it's something we can consider from the.

D

On the techdown side, how did um with the catalog and uh the techton hub is that bringing in like tasks and pipelines from different organizations?

D

So um if I, let's say from the or to the side, if I wanted to contribute something, would I contribute into that repo, or would I have my own repo um where people would go get it? You know how's the how's, the organization kind of handled when you want to when we start having more outside people contributing to this that you found that makes the easiest.

C

um Right for task on texas side, we have a different level of support if you will so there are some of the the tasks that are supported by the detecting community and they provide like automated testing um so that it's it's verified other tasks in the catalog that can be contributed by anyone um and depending on how the level of commitment, so if they want, if they set up the same level of ci and testing, then they get the same level of kind of validation as the community wants, and you can also have tasks in outside repos.

C

So the hub technically supports displaying tasks from multiple catalogs, so the catalog is a git repo and the hub is the web interface and the web that you can configure it to pull the task from multiple repos. So today it only pulls tasks from one repo but yeah. It could pull from more repos in future. Or if you have your organization and you have your own, um then you can collate tasks from how many catalogs, as you want.

D

Okay,.

C

So what you're thinking we could have kind of a catalogue of adapters or so.

D

That's what I'm kind of thinking that it's kind of falling into that it feels like that right now.

D

I think we need to flush it out more, but it it feels kind of that we'd have a catalog, because you know if, for example, if somebody wants to find um some events around security that they would be able to go to the catalog and find out what adapters are out there, that implement security, the security vocabulary, so they can either use that example or bring those in to their pipeline. For example, you know, so it's just a easy way to find things is what I'm uh thinking about down the down the road.

D

um Like you said, we don't have to decide these today, but that's kind of what it it looks like to me from now. From this point of view,.

C

Right now, yeah, I I agree, I mean I think um it makes sense to have at least one central place to discover all these things like, like you said so you you want to use a certain type of events that you want to see where you have adapters for um in terms of actually storing the codes having one central repo might have some organizational uh issues. I think because then you have approvers for that people, and but it depends how you set things up, but yeah we can. We can solve that as we go.

B

I mean as long as it's easy to to use it. It's not a problem, but currently as the pockets. You need to clone three different repositories to a certain path, and so it's kind of like. If there is an install or something, then you can have a different repos, but it's more for you know, ease of doing something.

C

Yeah yeah yeah, we could, we could add some automation into the pse or we could even try to make the current script more like a framework, so you can decide which parts you want to pull in, but um yeah. That would be some extra work, um but I think we it's fine to start with the experimental repo in the org and we could pull the code uh in there.

C

And at least we have a starting point where we have. Everything related would be in one place.

B

I don't know if we can mention it here or not, but I've seen that the yeah the cloud events actually in the respect. They have something called the cloud events primer.

B

Which is a little bit of history around the whole thing? So, if you want to have some, it seems like they are capturing back thoughts about how they they were thinking when creating the cloud of unspec.

B

This might be something for us to think of.

C

Yep.

C

It's a good point.

C

Is that in the spec repo yourself.

B

uh Yeah I can post the link here.

C

Yeah, I guess it's good to capture why we took certain decisions.

C

Otherwise,.

C

Nice.

C

Are you mentioning these materials because you want to start a draft or right now.

B

Yeah well, I've come across it. Sometimes when I read it so I wanted to mention it but uh yeah. Well, if I got the time I could, but uh I won't promise something sure sorry.

C

Okay, but yeah thanks for the reference.

C

um All right anything else on the new org.

C

Or repose.

D

I just said it just looks like a good start.

C

Oh okay,.

C

Cool, um if fox, wants to be added to the orc free to sign yourself in or send me a message with your email. If you don't want your email to.

D

Be.

C

Written in here um make sure everyone is added to the org.

B

You just need the email.

C

um Yeah, the email that you use for gita, so I can invite.

C

All right, um the other thing, then we discussed during the last kind of sig meeting about jenkins and cd events and text on possible pocs, and so I wanted to to discuss this today so make sure to join the meeting. So maybe uh we can have a discussion on these and make plans for um a potential plc that would involve jenkins as well similar to the one that we have done with tactile men.

E

There we go.

C

And yeah, so I think uh one thing that I wanted to to capture um here is: um what kind of events does jenkins said, and how does this match to existing cd events and the buckets that we have?

C

So we can get an idea of what type of work we need to do, whether we we need to make some changes to this, to the existing vocabulary at more events to to match what we need and yeah.

E

Yes, so let me share the link to the repository between all of the events and I can also share my screen and walk through um the events which are currently supported.

C

uh Yeah sure.

E

So at the moment we- and this is also part we like this- is participating in hacktoberfest and there is an issue to add more um sort of like events which are supported in like the pipeline, but as a whole. The parents supported our cue events, so when a job is entering the queue um or when a job is left to queue. So again, this is like a single job existing by itself.

E

um There's some build events for when a job hasn't started or it is completed or it's in the in the finalizes state, and I think this was more so when we were picking up events on what to choose. I think what came into mind was the more relevant events which would make like designing systems on top of each other um more easy. So you know if a job is completed, you would ideally want to trigger something else in a different cd system or when a job is finalized or a job.

E

So the finalized event also sends an event if the job has failed, so the finalize would be sent out if the job has completed, but it is failed and.

C

um Sorry, what is the event the difference um between the finished and sorry completed and finalized.

E

Yeah, so completed will be sent out when um they're, basically like two stages, so the event completed is only sent out when it's successful um and finalized will be sent out like either way. If, if a build is successful or if a build is failed or if it's still in the pending stage,.

C

Okay,.

E

Yes and then fail is being sent separately as well. So, for example, if someone is, they have a job um and the job was built, but they only really want the failure when they they do not care. When it's ended, they really only got the fail.

E

So that's when this event, like the field will be sent, but if they also want to know um the time between the event being completing or like that particular job competing in the job, failing that's when they would want to use finalize so there's it's it's a tiny bit of a difference, and I think we need to make it like. I need to add some more detail on the difference. That's a really good point.

E

And and then there's the job event for if a new job was created or updated and and possibly like deleted and and the known events for want to note is online when a node is offline, uh and there are some more note. Events for you know like an agent is, let's say, like added to a queue or if an agent is in the waiting stage, and not all of that stuff like that, but right now these are the events which are supported and moving into like the future of maybe like a month or so.

E

There is a plan to add more pipeline events, so when something is moving between stages of pipelines from one stage to another stage um or when one stage has failed, so that's going to be a bit different than individual events.

E

What.

E

Stop my share, so you can go ahead and share if you want.

C

All right.

C

um

C

Thanks so.

C

I think we don't have a matching job for matching events for all the events in here.

C

I guess.

C

Let me check the, I think, mainly the queue with job events which match the kind of core core category where you have.

C

Kind of pipeline started pipeline completed with this kind of events.

B

Wasn't it pipeline job and build events.

C

Yeah but.

B

uh

C

Yeah yeah uh pipeline task, I think tasks. Maybe we correspond to the stage once uh once they're become available, but the three events that we have our pipeline run cued started and finished.

C

um So I guess the q enter would be the cute one.

C

um I'm not sure when the eq leaving queue event is generated. Is that once the job is completed, surely.

E

Yeah, so I would say that would go into more like the finished in a queue. So when a job was in a queue and then it left the queue uh and then when it leaves the queue. That's when the job will start building.

C

Oh, I see.

C

Okay, okay, so basically the cue enter with the pipeline compute and you leave the basically the pipeline start.

C

As it starts executing- and I guess we don't have anything for the completed or failed, but the finalize would be a pipeline.

C

Finished one which is sent in any case it will contain the result.

A

Yes,.

C

um In terms of job created and deleted, so this is about the definition of the job itself right so create.

E

A new.

C

Project and define a new job and so forth. Okay,.

C

I don't think we have anything like that.

B

No, uh but we should probably mention something in in the continuation integration events: um we have build, queued, build start and build finished.

C

um Yeah, even though these jobs might not be ci specific, um in fact, so they could be for cd pipeline.

B

However said there are, can you send both events.

B

I'm trying to remember what we when we were supposed to use the build events.

C

Yeah, I think it builds events are specific to a job which is a build, so that creates an artifact um and so after a build we sent like already for published or artificial packaged events as well. I think that was the.

C

The idea.

E

Yeah, I I do agree with that and we can uh implement that in jenkins, but I don't think that's going to work for all um jobs, because there obviously are some jobs where someone would might want to build and publish an artifact. So uh that can be a possibility of implementing that event inside of jenkins. But it might become a bit hard to figure out. When exactly would we want to trigger that.

C

All right, so the the way we did that in in tecton. If we wanted to have extra kind of events, we use some metadata on the job definition.

C

um So, in the case of tech turning the pipeline, we put some annotation so that to if, if the annotation is set and certain results are produced, then uh the tecton controller uses that information to to send the specific events and because the the other thing is that if you send.

C

An event, for instance that requires an artifact id, it's an option not to be, but if you want to send an artifact that you need to to be able to understand where, where to take that argument id from so it's a similar kind of problem, we have an object inside because jenkins is kind of high high level pipeline orchestrator. In this sense,.

B

So basically yeah we should the state and recommendation of these events should be sent specifically for the job, but the other ones could be, for example, implemented by plugin, because they're more general.

B

If you're, following my thoughts.

C

Yeah so let's see our events- okay, let's.

C

Package.

C

And try the job yeah, that's the possibility. I mean the job should present the events directly um or yeah. You could have some facility in the plug-in so that specify a certain attribute in your job and the plugin will send you.

C

They add for you.

E

We can also offload this to the user. Who is um configuring that particular sync, since that's how it's very like ui, based at the moment, what events would the sync like to receive and then act upon, uh so the user can maybe select. I also want to send build events, for you know my.

E

My job is also building artifacts and publishing, but I'm not sure if uh it might make it easy or hard for for the users, because it might be a bit difficult to figure out the difference between like build events or build like events or jobs that you're building an artifact versus just plain jobs.

C

Yeah, I guess, if you, if you know what you're doing you could select the extra events, but it could be optional, but yeah.

C

I think it would make sense um and certainly would help.

C

It might help with the plc, at least to prove this is higher. This kind of advanced sent.

C

It makes it easier for integration like the tecton skeptan poc sends an event about an artifact being packaged.

C

If we only send the pipeline finished events, I mean that could be any pipeline and it would be difficult and you know kept inside to take a decision. What to do based on that.

E

Yeah, I think that's a good idea. um Definitely thinking of offloading it to the user itself.

C

Good for no type of events- I think that might be. We have something in the.

C

Continuous deployment environment created, I guess we could.

C

It's it's a test environment. Basically, you know in a way.

E

So, like environment here would be more like what's generating creating and testing, because node in jenkins is more related to actual infrastructure.

E

So I'm not sure if they might match, I think they're quite different events.

C

Yeah: okay: it's where you execute your builds and not where you can deploy to yeah.

D

You're right.

C

That's a different.

B

I thought it was at least we had some, uh I guess when you're running your tests, you want to have the environment where you run it, uh but maybe that's not exactly corresponding to node, but I guess you could use it's in my head at least.

E

I do uh see I do see that point um because, like you know, and when, whenever someone would want to have a special sort of testing environment for their job, they might create a node and add additional capabilities to it. uh Yeah. Okay, that I think that's something that I might need to look a bit more and ask jenkins community who's, more familiar with environments and like node, but that that that can, as mathias said, that is. That is true. That they're in in a way that that's both executing.

C

Something right.

D

And from a a deployment perspective, you may have a step in your process that would be doing some terraform to stand up a kubernetes cluster and kubernetes would be more like in standing up. Kubernetes from an infrastructure level would be kind of related to a node event.

E

Yeah it aligns more with infrastructure and like uh starting up or tearing down an infrastructure, then very clear alignment with environments. But I'm sure that it is something that jenkins.

E

Maybe just in in some different architecture, but again you might need to ask the community about it.

D

Yeah in in our world the artillious world, we view we call them endpoints, but nodes are belong to an environment. So you'd have you know a database server you'd have your kubernetes cluster and then you may have some lambda functions that make up the qa environment and those are all going to be part of different types of.

D

I want to say like for lack of a better word appliances that live in the environment, that we have to make sure they're they're up.

C

And.

D

Going.

E

That makes sense.

C

So I think it makes sense maybe to um to some discussion around on this kind of events or cd events as well. So maybe what I can do, I can create an issue or a discussion, and then we can um continue the discussion there on this specific topic and see if we want to add some some events to the data spec.

C

um Yeah, I don't think they would be vital for um initial pocs, so I think it should be okay if we don't have support for node events right away.

E

um Yeah, I don't mind either way, but it's still um I like creating and maybe figuring out that environment. Usually, I think that's a good idea.

C

Yeah, okay,.

E

Thank you.

C

um So.

C

um Where do we go from here? um So do you think um this is something you you could be working on surely and like starting to look at implementing some of these events, or is that something that you, you would not be able to work on.

E

Yes, no I'll definitely start working on these, uh and I also pull in some more uh people who are familiar with the entire jenkins ecosystem and they might be to help out as well and the terminology and the differences between you know um jenkins and other ci cds, especially like tech drawn. While we were since we're using that for the poc.

C

Okay, so should we keep this? This meeting like as a sinking point to see if there is anything that needs to be discussed, and we can also interrupt by as luck if there is anything more urgent to discuss.

E

Yeah definitely, okay,.

E

So.

C

um Anything else on this.

E

Oh, I think we're good for.

C

Now great, um we only have a few minutes left. um Do we want to get back on the discussion in terms of uh the format for the spec and the generating sdk code, or anything else folks would like to bring down.

A

There might be some background noise from my side. I apologize for that, but I went through all what I consider open discussions and all action points and put them on the wiki. We definitely don't want to go through, perhaps any of them today, but.

A

Most likely some of those discussions or some of those actions are pretty close to being done, and what I would propose, as is that we as sort of a standing bullet for future meetings, we try to to look into yeah. Whatever discussions, I think, are either important or soon to be closed or, or can be easily closed just so, we can basically shorten down the backlog a bit.

C

Yeah, it makes sense, um so let me.

C

So.

C

Okay, yeah thanks.

C

All right shall we start to go through those.

A

I think that that might take too much time. I think if you look at there might be one bullet. Actually, if we look at it that I think I documented some discussion as basically just needing a formal decision, it seems like everyone is in agreement, but uh I'm just not sure about the decision. Let's see if I can actually remember which one that is, I hope I noted.

A

The detective itself look for a second.

D

Maybe when, um when we look through these, if there's some way on the wiki page, we could just color code or tag um the ones we think that are close just to make things easier to find again.

A

Yeah, that would be a good point. In fact, I think it's the first one, uh it's one of the ones that it seems to be really close to to at least partial decision. We were talking about generic versus concrete activity events and I think everyone seems to be in favor of having generic activity events.

A

What is not clear to me is: do we only have generic activity events, or do we also have concrete activity events that we don't need to solve it now, as I said, but I mean answering that as well, would make this a complete decision rather than have a decision in some sense.

C

The person, I think we we need to have um concrete activity, events as well and and that's, I think, an area where we gain a lot of value by having this shared vocabulary, because especially the concrete activity. Events, probably where you get a lot of letter of different names in different systems, and if we can, at least in this place, have one name which is explained um with a clear semantic.

C

And so there will be adaptation layers needed for the different platforms to converge to those names. But then, at least, if you receive an event, cd event that talks about a test or a build. You know what is meant with that, and then you can take an action on that. Whether if you only get events about tasks and generic tasks and pipelines, I think that's useful if you want to display the progress of a pipeline or of your work flow made of multiple tasks or pipelines.

C

So if you want to build metrics about how many pipelines you executed and so forth, but if you want to take an action as a reaction to that event, we need to have some more information. Some more concrete information about what happens.

D

Yeah, I agree, I think, when we talk about the concrete events, I think it's going to be helpful in the long run, but also, I think, we're going to end up needing for a a translation matrix. So um this is our. This is from the spec side. This is the definition of the concrete event now in jenkins. You know, just like we had the conversation about.

D

What a note is, you know, so uh a node in in the spec is defined as this and jenkins uh it maps one to one it maps to something else and in like uh arterius, it's a map to something else. I think we're going to need a matrix that kind of helps people digest or or a way to bring things into their their frame of reference.

D

Does that make sense, because just.

E

We.

D

Have so many different namings for the same thing.

E

Yeah, that's a really good idea, because that is what sort of is the goal for this like standardizing events and defining that vocabulary. So I think that translation metrics might be really helpful. In that case, yeah.

C

And I think we started to collect some of those names so um yeah. We should keep those in a document nicely in a nice table all right, um so we are at time we have a bit of a hard cuts and another meeting coming up.

C

um So I would leave the meeting for now and, if folks want to continue the discussion.

D

Let's I I have to drop off as well, so.

A

All right, I think we could continue the discussion in the actual discussion if you want to and get up so that might be a good way of doing it.

D

Sounds like a plan.

C

Yeah thank.

D

You everybody.

C

Thanks everyone for joining today.

D

Good to see you.

C

Bye.
youtube image
From YouTube: CDF - SIG Events Meeting - Vocabulary Workstream - 2021.10.05

Description

For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/