GitLab Think Big! - Release Management, 28 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Release Management Think Big #10

Description

Welcome to the Release Management Think Big where we discussed supporting releases at the group and much more!

https://gitlab.com/gitlab-org/gitlab/-/issues/121476

A

B

Hello, how do you I'm good I go ahead?

B

Alright, welcome to the 10th I think, release management think big.

B

So last time we talked a little bit about the CI CD director dashboard, this time we're going to have a couple of different issues, one of them being a brainstorm about specifying some tags and releases work that nathan has added to the agenda. So we'll wait for him to to join. I would like to review kind of the future of release management and give you some perspective on what I'm thinking about and we can discuss them while Nathan joins sound good.

C

B

Feel free to add anything to the agenda as we go. So when I looked at our environments, job to be done, research, we did that last month, kion and I interviewed a couple of customers. We had a survey, go out that had 60 respondents.

B

We learned that environments are ultra flexible, people, use them in all sorts of creative ways and it's crazy, and then people don't like certain aspects of gitlab which makes them not want to use environments, release management's number one goal is to drive deployments out of gitlab and if you look at the api deployments are only tied to a specific environment, so our closest path to drive deployments is to help encourage and make using environments as easy as possible. So a couple of the quick wins that we identified.

B

One of them is making the environments dashboard, like usable, so being able to pull more than seven projects and more than three environments. This will really help users be able to see all of their environments across their project and then the other one is sharing environments at the group level. So this means, if I, have a target. Url name production project a and a target URL named prod and it's the same URL in project B.

B

These would currently show up on the environments dashboards as two separate environments, even though the URL is the same, so us being able to bridge that gap and share that environment across the group will be really powerful for our users. So that's kind of the the first two things that we should be knocking out to help make environments more usable for our users. The next piece that I'd like us to start thinking about is release generation.

B

Now that we have that MVC of being able to generate a release from the CLI that Jaime created, we can start expanding that CLI to have release versioning and auto changelog and uploading assets.

B

Well, the last thing with release orchestration is the releases page user experience. So a couple things about this right now we have duplicative pages. When you look at the release page in the project, it looks the exact same as the release page view once you click into that particular tag, there's an opportunity that we have here to be more competitive and allow our users to see different details about a release. For example, is this release to a particular production environment? Is this release scheduled across a different like deploy? Freeze?

B

Is this in a particular group milestone or in just a project master, so by allowing us to provide more usable insights at a different level, whether that's project or group, and then give people the detail view once they click into that particular Wrigley's name is something that we really have to kind of parse and figure out.

B

Then, of course, we have secrets management and release evidence. These two items are kind of in parallel with release orchestration and they're pretty minimal right now, so we're just thinking about how do we build up our hashey Corp integration and then the other one is making release evidence more usable for the auditor. So for this think, big I'd like us to dive into either the release page UX or talk a little bit more about environments as we wait for Nathan to join that sound good.

C

Yeah thanks thanks Jackie, that's awesome, I'm gonna say the environments issue is quite interesting to me. I've always found it not confusing, but slightly an intuitive. The way that environments work where the environments don't really know about each other and also their environments are not really.

C

You know you can have any number of environments right. There's not really a clear definition of this is the production environment and this is the staging environment might have in, and so you know obviously offers a lot of flexibility to customers but good to not have to not know which one is the production environment. That was a question that we raised when looking at windows there was, you know a bit strange that we don't have that definition, I, think and so I guess I guess.

C

The question is you know is that is that a is that something that customers are always asking, but also asking you know: do we my wish environment means a lot of local food. Do? Should we tape this flexibility, we're carrying? They have and not upset the applecart.

B

So, in a future job to be done, iteration that Han and I are working on from the research perspective.

B

The biggest question that I have to customers is how important that, how important is it to know what your environments being used for and I would say that number one most of our customers are using the name to distinguish the environment so prod, or they have a URL that it's named prod like they have prod dot, whatever URL location. So those are the kinds of ways that they're using to identify the production environment, making that more native and get lab could be a really positive user experience.

C

Yeah again comparing to Heroku, they may have this situation, these environment pipelines, so they call them pipelines where you know. This is your production environment and in the and then you might have a staging environment. It directly feeds into the production environment, its solve a different problem there. What they're solving is, you know, compilation of assets and you know to reduce the the released alum, but it's just it's just really clear that this is your production environment and in these other environments, are critical to all they've got identity into it.

C

Okay- and you know- maybe that's- maybe that's also something that's only applicable to a smaller site and because we're using kubernetes, you know we have a different view, but it is a simple approach. That's easy to unsay another say.

B

I would like to maybe we can open up an issue and start kind of landing, some of the competitive analysis with our Heroku here and see what the community has to say about it, because maybe that will be something that would be really meaningful. Something I'm struggling with when it comes to the environments. Dashboard is how do we create like a deploy board for companies that aren't using kubernetes?

B

You know like how could.

C

We yeah it's such a great question Jackie, because you know the whole world went to kubernetes and, however, there's a little bit of a backlash lately, because it's just so complex, and so you know how do we support other people, other methods in the way that we admire I, wish they made Italy supporting communities they'd not lose their focus as well, because I think big advantage for us and.

B

I think what might be a good fork in the road is if the configure team handles all of this cloud native deployment with Auto deploy and if we figure out the more not cloud native releases, I think that that might be a good way to ensure that we're still k-8 first.

B

But then we have this multi cloud support from a release, orchestration standpoint, because that's the biggest thing that analysts are going to be looking at is: how do we stack up against tools like electric cloud and Jenkins and and ZP Labs, who really don't care what your target is, and how can we see those tasks regardless of what you're planning to deploy with? So that's a good a good point. There, a.

C

Little bit we might already have I mean our city is supposed to be SoCal from the flexible. That I mean you could more or less put anything in there are scripts and, and so may be, a part of supporting other platforms or other deployment methods is simply a matter of documentation and producing examples, financial that all falls within our group. But you know as as gitlab as a whole.

C

You know templates even I, don't know, but you know an easy way to get from element code to production, environment.

B

Is what we're seeing when we look at the relationship between deployments created and release is created? We see two lines we see releases are right under deployments, so people are denoting a particular deployment with a release object. So the best way for us to increase the number of releases is to create the object by which they're denoting and improve that so I think empowering these multi cloud deployments more effectively will start naturally seeing people leverage that releases features more and create more releases because they're going to be denoting more periods and times and get laughs.

B

That is because we have this whole part of the user base that we learned from the environments job to be done, that aren't deploying with get lab and it's because they can't see where they're deploying to and it's much easier to go to, AWS native to see their environment rather.

C

Yes, yeah, that's a huge, that's a huge opportunity for us, well-known examples.

C

Again, just came back to Cooper knows we don't have a lot of good examples. People do not originate all dates during the sinkholes. You know they lock on to applications.

C

And say include: manami's is really you know, I think the experience is showing us that it's actually grateful legible, complex customers.

B

Because more customers that are smaller are more likely to ploy using ECS or an.

D

C

B

Those are easier to manage for a resource perspective like they're not as expensive, so indicating like that connection could be, could be interesting. Yeah.

B

Anything else on this environments, job to be done any other questions.

B

More to come on this as hi anna and I and uncover different kinds of pain points. I do have a user insights, epic that I'll link here, if you're curious about whatever cutter customers actually said and how I actually interviewed them I'll definitely provide that information. Hi, Anna I think you bolded the releases page UX. Do you want to dive into that topic? You.

E

E

But I want us to talk about and a little bit about the personas Jackie are the consumer this overview, because we talked about the jobs to be done, but I'm really interesting. Seeing what and trying to identify what are the tasks that those people will try to complete in this view, so that we don't create friction once we start to incrementally adding these changes to the 2dy, it's more of a dog. Oh no,.

B

I love this. This is such a good question. What personas are we trying to tackle by separating these two views? So I would say that all of the conversations that I've had I've had about six to seven interviews with customers that are very focused on managing teams.

B

Whether this is a development team lead or a release manager, or perhaps a platform, an engineer that are in a matrix environment that are just trying to see what is the progress of the things that I'm working on and sometimes the progress of the things that I'm working on are not in the same group they're not in the same project they're, not in the same instance, so building out more visibility that we can create connections for users using the architecture that gitlab offers today, so more intuitively, providing aggregated views of the release page at a project level would help this development team, lead or release manager or platform engineer persona, be able to target triage and dig into details as needed.

B

So if we think about the tasks I'm starting my day, I want to see what trash cans are on fire. I want to see what things are not on fire and I want to triage those items. Accordingly, they would go to that project releases page see. What are all the releases are doing or they'd go to the releases group page and see what those releases are doing.

C

One thing that came out recently that well I read recently I come back two-week vacation. Is that this question of you know, so we clicked evidence, possibly mole evidence, objects per we release and then we delete the release, and so what happens to the evidence, the evidence? This is the audit trail and so I think that I think the decision well are.

C

Certainly the comments in the issue were that we should keep the evidence, which is, of course, define what it does mean is we'd have to have a different way to access the evidence through the UI, because we've no longer got the tag and then who would have access that? Possibly only the audit of all yeah.

B

Like how do we handle orphaned evidence, yeah.

C

B

B

If we don't a lot of people to access it in the UI and it only becomes an API yeah.

C

That's well that actually is those the user, simplest approach and and I guess. We need to consider how frequently would this happen and who needs to access it, because they can always access it through the API. What.

B

I would probably say is that it's an undesirable behavior to delete releases, so this could be one way to deter that behavior. Is that hey once you delete it? You still have your least evidence but mind you you have to. You will have to retrieve that from the API and then figure out how you're going to dip that release file from a different release file to leverage the the native capabilities that will eventually offer in release evidence.

C

You don't necessarily compare ourselves to um github, but I. Don't think you can delete it. Release can do yep. You can okay, interesting.

F

You can delete a release, but you I, don't think you could delete a tag right so will still show up and that releases page, but you can delete like your Associated stuff with it.

B

Welcome Nathan sorry, oh yeah.

F

A

Good quick question before we move into Nathan's points and just on what John said about comparison to github with the whole did challenge recently. If they get Latin versus github for users, I'm just curious, are we putting more of an emphasis on like features that keep us competitive across versus prioritizing? You know, market differentiators I was just curious. If that has changed recently.

B

So, typically, release management is very focused on competing against the current market leaders in release orchestration. So this is going to be ZB labs, electric cloud and some Jenkins stuff, as we get more into the CD capabilities of release orchestration. So github has not been a priority for my my focus, as our team looks into this, but I think that's because I came in right as we implemented the releases API and the releases API was meant to be the response to being able to create tags and releases, which is how github does it.

B

You know, like you, create releases from tags, ah so github is not a priority, but I would say other competitors in the release, management space are and I would say about 30% of our milestone. Plan work is about prospects and getting more prospects at any given milestone and then the remainder of the work. It's usually existing customers, whether that's bugs tech debt or feature enhancements for existing users.

A

Great well, thank you. Yeah.

C

Yeah I think in many ways I mean we're still. The product is still needs maturity, but in many ways the feature set is already. It's already support, that's what gives offering we need to be more polished, but we'll get there.

B

And actually I think one of the things that Michael who's on the call with us right now. Inspired me to create. Was this issue about supporting github releases and get lab releases so finding a way to like import, your github releases and to get labs, and this is one way we're like we're, not competing we're more like just trying to make the best developer experience possible, where no matter where you manage your code and I. Think that that's that's one approach that I would say contrary to competing it's just.

B

How do we provide the best experience? It's.

C

A good point, because if we you know if we want to encourage people to do, for example, migrate from github, and if you know, if they, if they release a structure, that's that there can be, you know, can map into something that we that we have. You know losing data without breaking anything. Then I think that's. Definitely a plus.

B

Which kind of goes back? My honest question was, which is what what persona are we focusing on like right now we're kind of focusing on this? How do I work across plan enterprise level releases and then maybe we'll dive back into the developer experience, and this is where we'll start competing more head-to-head with github.

D

All right, I wanted to add, if we're not, if you're, not only targeting customers but also open source developers, you always have the problem that kidnapped outcome is not so social and they will be hosting the source code on github.com, but they may have some mirroring or something else in place and may see the benefit to like use, get little calm as the primary source and have the possibility, for example, to Center releases to github, which would be a cool thing.

C

Yeah and so I think I think when, given the our future cities in release, management is I think already bigger than what can help do awful I guess the system matter of considering whether you know we can actually directly map the feature set onto what we have and you know then, of course we can consider other. You know Atlassian, for example DeBacker, but I guess you have is them on that? We will be focusing on yeah.

B

It's a good call out, throwing a call I think I tried to do once a quarter, a deep dive into a competitor. This quarter has been cloudBees so moving next quarter. I can look more at the tools that we're seeing people leaving when they come from get lap and maybe get hub will be that tool, and then we can kind of evaluate that. That looks like, uh let's see, only check the time Nathan. Do we want to dive into a couple of your issues.

F

There yeah I just wanted to kind of call it. My one point: I wrote there is I'm curious. We kind of seem like we're, building a lot of like planning and and overview kind of functionality into releases, or that's what we're talking about, but we already have milestones and we have a lot of other stages that deal with that. So I think we need to be a little cautious about not like trying to do to pack the entire software cycle into releases like we can like.

F

If there's something that milestones provides, we don't need to rebuild that into releases like I'm, not really sure it makes sense to be for releases to be the place where people go to plan their daily work, I completely.

B

Agree with you, yeah.

F

My only comment there I think.

B

What's good is that we do have a recurring meeting with Gabe Weaver over plan and it's called milestone and releases. That's the heading of the meeting and what we do is we talk about like. Where is the intersection of releases and milestones, and how do we cross link?

B

The two I think my perspective is: how do we give people information about releases on the release project page and not the view page so, for example, say that the releases project page just has like four boxes of number of active releases, number of upcoming releases number of releases with release evidence, and then it lists out the release tags with their progress views, and then you have to click into that release. Name to see the other details like the changelog, the release, evidence I, don't really feel that we need to include anything beyond the release.

B

Progress for you because I feel like that gives us all the information we need from a planning perspective for release managers and it gives them the opportunity to link off into the planning stage more.

E

Just one also to highlight this: that I think will be nice for us to define iux gold, both UX and fronting, goes to the objectives of this redesign because I see this doesn't be designed. It's gonna happen to some people. It's gonna add friction to their workflow I. Think once we set this this overall goal for what we want to be doing here, it's gonna be easier to have conversations about how we want to solve this problems in different ways like cross-linking information or just reusing.

E

Some existing capabilities and I would prefer, if you have to be aware, not to just incorporate things from other safety groups because they usually come with mathematics or a lot of bugs. So if we can look at you, for example, linking making it like what we do now, there's a counter of how many issues in version 5 so deployments. You have been your specific release right, but then we leave that to the milestone overview, where you can see all that detailed data.

E

I think that's that's a good low-hanging fruit for us, rather than completely eliminate the feeling in the big empty bag with just random.

E

B

I think we need to kind of see what's the intersection of the users who are using releases without milestones, because this is where we may need to run a campaign on how to plan releases with milestones, and that might be a blog post or a couple of webinars that we just published on unfiltered that drives the action of associating milestones and releases and I. Think we'll probably see that once we finally offer that in the web, UI too.

B

But that could be something that could be one of the reasons why we are seeing releases without milestones, which means, when they're not being and they're, not able to take advantage of the planning teachers.

B

But I agree Hannah that we don't want to add bad UX into their releases pages. And it will cause friction once we change this, because every change does.

B

Okay, I think Nathan. You had this other issue down here. Yeah.

F

I've been meeting so I created an issue for this, but I hadn't a time one thought I had since we're trying to increase the adoption of our stage right now. All our releases have to be kind of manually, created or like created from the CI, whereas, for example github they automatically create. They populate that releases page with tags and there's kind of good and bad to that. But one one way to kind of get the best of both worlds might be to have a setting somewhere.

F

That says automatically create releases when a tag matches this filed card, and then you could set up a little like a wild card that matches your version tags and then your releases page would automatically be populated with releases if a tag is created that matches that wild card, and so that will automatically just start what people would be able to start using it right away without actually growing and creating releases. So that could be a way to to increase adoption of the releases page.

C

And we have a lot of the backend in place to do that. Already I mean we we can create. You know just from a you know. We can create the tag just from from the Haitian. Oh yeah,.

E

B

C

B

I love this idea, I think more automation that we can support. This will kind of opt people into releases which is great yeah I love that I do I. Do think, though, I wonder how many users are going to start leveraging release creation from the animal file once we bake that release CLI fully and I, wonder if that will start minimizing the manual actions that people are going through creating tags and associating releases after the fact.

F

Yeah that yeah that's a good point, because we don't want to have multiple ways of creating things and it could be confusing if you have creating things through the CI, and you also have this Auto creation behaviour turned on so right.

B

So we just might want to balance that and think of the wild card will be the preferred way. I think what I've heard from customers the Deb's persona mostly, is that the yellow file will be their primary way of creating tags and releases, but that might be because they haven't seen other options well,.

C

They think about using it while cutting a regex is not. Everyone follows Cynthia, I think might follow another. You know say we could we could try and work what would be the most popular methodologies but I think one of this really strong features of key players.

C

It doesn't lock you in any way really like it constantly allows you to do what you want with their to course goes a bit of extra complexity, but that's yeah, I I do like the idea of having a single source of truth, essentially as you're saying Jackie, but a UI element could still somehow work off there. I don't know what's another close, but we could have a URL on that, essentially somehow populates the em all well links to it like we've done with the rivers. Yes, oh thank you yeah. We.

B

Had like a little.

D

B

Freeze headache.

C

B

Yeah I I can I feel that I can relate. Okay, I think that one part that I remember is having a conversation about was that relationship between the UI, creating things in the animal can be problematic for our system or tool. Today, I think that was a previous conversation that we had so it sounded like that might be something that we want to avoid and have either in the amel or the UI. But maybe that's not true. Maybe that was a misunderstanding.

C

Maybe it completely quick, actually I think maybe I was ever on. I think the what the pair should we ended up with with the deploy race was actually quite where we had. The yam will consider something. That's on a configuration page.

B

I think we still have some time to talk about your associating releases with group milestones, issue Nathan.

F

Yeah, that's just the only reason I am interested in that in particular is because it would allow us to start dogfooding. All of our issue summary stuff that we built on Caleb calm, because we use group milestones so and I. Guess that that's I guess I, don't know, but I feel, like group milestone to be more common than project milestones. A lot of organizations would do it like we do so. It would just be a big wind to be able to yeah.

B

I completely agree with you on that I think we weighted it three four four weights, but I I think crass literally said: I, don't know how much I.

A

B

Know much about group releases but setting weight to three. So that's that inspires a lot of confidence there. So this.

F

Issues is it different, though, because this is adding like a group level release page, whereas I'm more talking about having, even if project-level, release asserting with a group milestone so.

B

It'd be great if releases could be connected to group level milestones. Okay,.

F

So maybe it's support releases at the group level. Okay, so maybe that titles.

B

Misleading okay.

F

Yes, that is that is right, then, because.

B

We can't really create a release at the group level because there's no repository at the group level right.

F

B

It has to be at the project level, but I can change this name. So that's clearer, yeah.

F

B

I, just I just assumed that releases will always have to live at the project level and that the release group page will be an overview of releases and milestones or how. If we even create a releases group page right right.

C

B

Good call there.

B

I promise I tie better than this.

E

A

E

Pressure of all this watching you I, was.

B

Like I took a typing test, I know: I can type. It's okay have faith in me all right. Let's let me find our.

B

Okay, so here's the issue I would be open to just seeing if one of our teammates would be cool picking this up in 13.1.

B

This could be a really big dog, fooding value-add right I'd, also don't want to pressure people into picking it up. I can also schedule it, for you know 13.2 you or we can consider a candidate for this current milestone if peoples work frees up because I do agree like this will help our dog fooding effort it'll also help fill a pass for who is one of my buddies that I brainstorm with who uses our feature so I think that that's a really good call-out Nathan cool.

F

And then my second point there we have to talk about this so many times, but just kind of thinking more through the association between tags and releases. So this is one two today that someone was confused by why in a guest user of a private project when they saw the releases page, it was all the release. Names are all kind of generic and mangled, but again it's because they can't see tagged information. So it's kind of this recurring issue with them being tied so closely together and.

B

Not to mention we did have a deprecation notice from Alessio. That said that we were going to be deprecating tags and releases.

F

Yeah, did he even respond to that? Like did you forgive a a reason why that he.

B

Couldn't link me to a specific issue, so I'm still trying to find like the releases page and Vesey I think is what he said was like the originator of this request. Let me see if I can pull it up. That was his only response on the mr, so I'll Google that, but when I looked at issue, I couldn't see like oh what the reason why we needed to.

B

To disc disconnect it.

B

Yeah I, like briefly, went through.

C

This particularly it's a fairly large separating.

F

It'd be really big, but there's there's two things in particular that artwork kind of are kind of incompatible with the way we're doing it now, and one is upcoming releases, which really don't make sense if you have to tie it to an existing tag, and so that's always been kind of odd to me and then also guest access, because they can't access tag. Information so like those two two things I think are: are limitations of the type the tight on association between the two so.

D

Maybe it's maybe.

F

It's too heavy-handed of a solution for those two edge cases, but.

C

So but we would, we would have like a release on today or something that would be completely different from the tag yep.

F

I think so, I think what I'm kind of thinking that the best solution would be is to use the release the rails ID as the primary key kind of like we do for issues and work, requests and all that and then to allow in the URL you can you can route it using either the tag or maybe like a version.

F

If we ever introduced in version concept mm-hmm, you can still reference that in the URL with that, and that would kind of allow us to migrate from, like the associate the types, the tags to something like so yeah.

C

I mean we could definitely do it that way. I think it would be a really big architectural change, because we're saying we're so driven by tag at the moment, yeah yeah, so I, guess I, guess my question would be what yes, we could do it, but what why do we want to do it so.

B

The two main issues are today: you associate you you artificially create a release and a tag to then later recreate your release with the final tag in order to have like an upcoming release. So our release progress view is only as good as the tag being created today and then you have a milestone associated to that release, so it can populate percent complete, but that tag doesn't indicate what's actually contained within that release, because it's just a random tag and commit right.

B

He's not truly upcoming. It's like a fake tag, yeah.

F

Because that supposed to be like the snapshot, the tag is like the snapshot of the release. So it's it's not the that. Isn't the snapshot discuss upcoming, so yeah.

B

F

Wonder if I'd love to know the background behind this, because I'm wondering if this is supposed to mirror that feature of github, which is called pre release, which any snapshot, something is a pre release. But it's still it's still a release. And if that's the case, maybe we're just being thrown off by the wording like. Maybe because a pre-release does make sense to assign to a tag.

B

C

What we pulling an upcoming release right, three release: yeah.

F

But a pre release is actually snapshot, isn't released. It's like this is the pre release, whereas the upcoming release implies it's not yet released.

E

For me, would you tell what stay another suit from uncle coming release police whatever there was a lot of confusion regarding the baby, where it is and by the time if I remember correctly, we didn't discuss like when the tag will be created, we're taking create a snapshot, etc. I, don't think this was sticking to a comma for ABC I.

F

Think that's really good content. I'm I'll read through that I'm really curious how this came about.

B

Ohio did I just but you're what you're doing sorry so I would say the only benefits that we get by disassociating, not the only benefits, but the two primary benefits that we get by just assuming these three a raise really assist from tags are that we can create truly create upcoming releases, meaning it is a shell of what will eventually have a time associated to it, whether that's a pre-release tag or an actual right. Now, we've deployed a change tag and then the second one is next guest access to releases.

B

So there's two use cases for guest access. One of them is I, am an embedded software project in gitlab and I. Don't want people to have access to my source code, but I want them to be able to download artifacts or assets. So I want to be able to publish my releases to people that are not in my project to then download thanks. There's also. The second use case for inter sourcing again want to publish artifacts when I give people an update that these things are now available, and maybe this is already a change.

B

That's deployed to everybody's device or everybody's intranet, but it's more like a here's, a release, that's been published and created, but no actions required, so we would be serving the two major groups that are currently consuming our releases today. Both of those changes.

C

Okay, yes, give you there then.

B

And with inner sourcing I'm starting to see a lot of overlap with air-gapped companies, so air-gapped companies might leverage releases to publish binaries for their teams to use so that they're not connected to a Wi-Fi or Internet.

F

Yeah anyway, the gist of is I'm, not sure those are those two issues and I, don't know if those two issues weren't such a major architectural change. That's just something think about.

B

Yeah I think it does. We should probably have a deeper dive on this team, specifically about. Maybe we can talk to maintainer or Alessio, or somebody who who said who was a part of the original conversation, because I wouldn't be necessarily super gung-ho about doing this free architecture. If it wasn't decided before that, we should deprecated this relationship, but if I could somebody else decided? It kind of makes me think that this was something that we should consider to also resolve these two issues that you've linked here. Nathan.

F

Yeah well known about that deprecation. The way I understood it. He was mentioning that we were deprecating, creating a release and tag at the same time, not necessarily the association between the two. It was more just the process of creating, though that was being deprecated. That might be a slightly different issue.

B

For some reason, when I think about how people are creating releases, a tag, it's so important to it to their use case, I don't know if that's just because of how we've offered it and that's just what they're used to or if it's, because they really need those two together, that's my only like.

B

We should always be able to associate a tag to a release, but the creation aspect, I think, is my fears that people are so used reading a tag with her release.

B

So I have scheduled a follow-up meeting with Tim later this week. I think the package team wants to collaborate on a feature set for releases and Nathan. This kind of goes to what you were talking about, with allowing semantic version of releases and potentially combining some of the package page and the release pages together. So we'll unpack that with them in their meeting, we think big, and hopefully we can start talking about like a distribution model for releases too. So that might be they'll be a very interesting and compelling use case to solve as well.

B

B

Did have this item here about adding group repositories so I've seen this four times in the past three weeks, couple of customers are asking for us to support group level, Yamma files, group level, pipelines, group level, code and I think what this is about is enforcing permissions Ohio a higher level than the project, so that people can take the animal file from the group and extend it in a project, and it's a weird thing that we get pulled into it.

B

But the end point is I want to continuous continuously deploy and have my projects in a group. I'll deploy the same way using this animal file, but then I want to empower each of the projects to be able to extend that um will file for their own stages between deployments so wanted to flag that here to get your thoughts on it and I have a couple of issues open with both RFI team and the managed game and compliance team. I.

B

Think we can save this one till next time, because we have two minutes left. Are there any other topics or thoughts.

B

So, to recap: I think Shawn. If you could create an issue, I had up here.

B

C

B

For Heroku, oh yes,.

C

B

Environments, I will also.

B

Create a couple follow-up issues and add them to our backlog from the think pick, one of them being Nathan your wildcard sing and if you beat me to it, that's okay, just pay me on it, but otherwise I'll create this issue and ping you on it and then high honor. You and I will continue talking about the persona with the release page breakout, so I'm good.

B

Was this still useful? Did this accomplish what you thought it would? Yes.

C

B

Good, let me know how else we can improve it in our channel, all right, y'all. Well, thank you. So.

D

Much time we'll.

B

Talk soon, bye.