GitLab Engineering Productivity Team, 25 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Engineering Productivity Office Hours - 2021-08-25

Description

Discussion of https://gitlab.com/gitlab-org/gitlab/-/issues/225101

A

All right, cool.

B

This is the august 25th uh engineering, productivity team office hours still the 24th for me, so I was a little caught off guard by that um we're gonna start off talking about the eliminating usages of gitlab.com issue that we've been kind of going around, and I kind of wanted to start off asking a question that might help with prioritization on this because there's a lot of discussion and proposals in the issue, um but I was curious what you all what you all were thinking on this?

B

If, um if we would need to do this as a requirement for project horse, so like I made some notes as to what that code name is in the dock, if you're not familiar with it, because I think we may the way that the current method works. It may not behave correctly in those environments that are being considered for that project. Do you all know.

B

And if not, I'm happy to find.

C

D

Just more chances, I probably will sometimes work and sometimes not work so yeah.

D

As we found out for um jh most of the time, it works, but I'm going to get caught on really tiny uh trick, wise yeah and and the biggest concern is that it's just unmaintainable.

B

And it's growing right, so I think you have the script that looks at how it's grown each each release and comparing it to master. So that's where I.

C

D

uh If you don't mind I'll just share my screen.

D

D

So we started off like in dirty knows a long time away at 76. Now it's 196, so I think we're at a time where I think we need to start stopping. We need to stop new ones from coming in because we're at 200 mark- and this was at 13.12 right so and if I like, it's very slow growth.

D

But the worrying thing is that if I kind of run the most recent one, which is for the note 3, we start to see like this 5 7 1 6 here, which is all g lab.jh and we're starting to grow that as well. So this is kind of like essentially it's adding one additional dimension to it right because so far we've been dealing with commonly.

C

It's only a binary.

D

Thing now, when we actually get dot gh growing as well, this is essentially a sort of a two 3d dimension. So it's like two times three permutations, so self managed.jh.

D

And not necessarily or tested, and you can see how that becomes a problem if you keep growing at this point, so that's why I think this is now sometime soon is a good time to start to start banning new ones. That's that's a stop.

B

And, and it seems like the place to start is just with the gitlab.com method, um trying to I'll say like cordon off those and uh prevent new ones from coming in right.

C

Or do you think.

B

Or do you think it just? We just need to do something for all of them. Initially,.

C

D

It's not that hard to extend it to all the methods um because strangelyweargila.com and girl.com or deaf, and then you know, there's sort of variance right. So it's not that hard to just say: okay, just methods uh bandit okay uh using record should be all right. uh Someone can correct me um and then I put a note in the dock as well to make things even clearer. We can move this methods to a different module and then they say this whole mode. You don't use it.

D

Specifically, I'm taking the gitlab sas module, so we can move all those methods.

D

Yeah, don't use it.

D

And, of course, they're caveats right so.

B

Yeah yeah, so so the next question would be is what um so, I think we talked about application setting applica. I think those application settings or trying to get the information from other sources.

B

um Would we I I mean I I'm sure it would take just someone to identify those. But is there a known like a known path to migrate? Are the biggest defenders like the ones you just talked about.

D

Yeah basically applications, so um the clearest example that we have already currently is the uh check name, space planes, uh application setting, which is a very good example right. That could have been again calm check, but we have an application setting to turn it on and do it that way.

D

So a lot of things could be moved to application settings. um The only thing is that we can't, then we just have to do on on case by case basis, whether it's a different thing or whether it's just application something, but it will not never make any sense for someone. That's not assessed instance to turn on so, for example, uh features that deal with building a 700.

D

We know that you're connecting to nothing.

B

So so how does that improve the maintainability? um Sorry if this this is like a silly question, it seems like we saw the same permutations from like a test and validation perspective. If we move to something new from what we currently have it just may slow the growth.

C

So basically, um it just means that anyone.

D

Can turn on that the application setting or development audio testing thing and run tests again, if we hard code things like if gitlab.com um you can't test it, unless you make it all the way to glit.com, and then this is how we end up with uh text on top of hacks, where we say ifgillar.com or some other testing environment, which we pretend to regular.com right and then you can see the issue where now we want a different sas environment but slightly different settings, then we need to add more hex on top of it, and then we eventually would end up with an if-else statement where it's like, if killer.com else, if something somebody says elsa some other says we, we definitely do not want that.

A

So so we need to understand, like what kind of other skillet.com actually represents in terms of application settings and then um abstract that, like represent what we currently call gitlab.com based on the settings that we have like or a combination of different settings that we have or a new setting, that if we need any and use that instead of a hard coded hostname like github.com or gilabth, or something else correct, so correct right now like do, we know how many?

A

What are these representations that do we already have them or do we need to investigate and like list down like all of the current uses of the level.com, what they are? What do they represent.

C

um I think it's definitely not something that.

D

uh The engineering productivity group or anyone else should be looking uh into what this group should be looking into is just kind of setting the line in the sand to say you know and writing code to ban it and to allow exceptions for it, and the opening issue is to say: okay, um this is a problem um and then explaining why this is a phone and then asking them to well and then saying, and maybe application settings is a very common way of migrating.

D

What application? What kind of application settings do you think we can use or what new application settings that that you need to create in order to migrate this across yeah.

A

D

So it's it's fanning out issues to to the groups that are using these calls.

A

So we, so we start by stop uh preventing new occurrences of this and then when, when this, when someone introduces this, then we can ask them. um Can you think about a different way of representing this and in the application settings use data that we have in the application setting to determine this condition or add a new one? If there isn't any yeah yeah.

C

D

That instantly something right that.

C

That's uh that solves the maintaining of the probe now so everything now becomes is the application setting anywhere off versus if it does um yeah, um and then I think this is where we like uh the person kind.

D

Of driving this is a dri potentially could partner with the growth team or the adoption team. I don't know who, because that's probably the biggest uh issue is like. Do we want a stronger guarantee than application settings, for example, um I'm speaking in a sense like a cryptographic guarantee uh for places where we really really want onlyget.com to to use this thing or whatever, because offenses and the licenses is one example right where we specifically say only people with this license can access scalability features, for example,.

C

D

We want something similar for github.com and only for github.com and that's going to be.

D

And then maybe we want to extend it to this other substance or.

C

D

We, but we want that option. Potentially, I'm thinking like the customer's license.

B

Okay, so um so so uh what I'm hearing here is um ep, or you know the person who's, the the team who's picking this up would be the dra to drive it forward, um but if and and if I'm talking about the benefits here, I'm still disconnecting like maintainability and testability, because it sounds like it's getting like exponentially more complex to validate um features. That would be.

B

That would have like these multiple layers now of things that could toggle them on and off in a test environment, whether that's staging debt like wherever it could be in a femoral test, environment.

D

C

I wouldn't say it's exponential.

D

But it is stays some like permutation of x yeah, it's at least multiplication.

B

Yeah, okay exponentials may be too strong uh because we wouldn't say: there's one application setting for everything, but I'm just kind of seeing we we'd have this interlay of feature flag application settings that would need to be confirmed, um especially with end-to-end tests, but maybe even lower level tests in test environments. Yes, that's.

D

A

D

The difference.

A

The key difference is that now it's we can control it like through, because we know what the input is right now and we can control that as opposed to using a url which we don't have uh control at all. In terms of the from a testing perspective, we can't change that good.

B

Yeah I see here, okay,.

B

Okay, um so if we were to start somewhere small.

B

So, like we talked about having the cop and then starting to work with teams to migrate, are there maybe some good offenders? That and I'll admit I haven't looked like. I know. I know where they're being used. um I, but I I don't know where maybe a good place to start and try this out might be um do either. You have an idea like if we were to just say: let's pick this feature or this usage of gitlab.com to try out migrating its application settings and look at the complexity.

B

What would be a good place to start.

C

um There's 200 instances of github.com.

D

So we can pick any one of that. You probably want to invite migrations a little.

C

D

But other than that, like any any, is fine yeah.

B

Okay, so so nothing special to look for just pick. One.

C

B

D

C

With migration, the first one is stop.

D

New ones and then from there.

C

Don't always pick.

D

Any yeah yeah just picking in and I'm sure, once you pick one or two, uh we can figure out. Okay, there's a common pattern here and then just then you might have a better sense about which is a better place to start.

B

C

D

I come in with his name: sorry, I'm always using it. I think god, fat has has a good sense of my head. A good sense of light start.

C

Sorry, I don't even.

B

Remember him: that's right! Yeah, that's! Okay!.

D

Yeah yeah yeah yeah.

B

So I guess my reason for that question is I'm.

B

I I'm really hesitant to draw that line in the sand with that chat like that challenge that I see of application setting and permutation um like the permutations caused by this for testability. I totally understand that this needs to be better I'll say we need to stop so that as we, um so we can have more consistent behavior, but it feels like we're trading like we're, creating a bigger problem than what we have convince me that I'm wrong like why. Why is the new state of application setting better than the current state.

C

D

Think it's it's a very easy, two-way decision right now. So if you ride the cop and ban it and we discover it doesn't work and we just stop the call right okay, so I think that's definitely better, but to kind of illustrate um why it's really really bad.

D

uh I mean now is a good time before it gets even even even worse. So uh let me kind of kind of illustrate. What's going on, show you what's what's the problem yeah, so the issue.

C

D

If we kind of write code like this right and then say, do something else, maybe.

D

So this is why we started our ad now, once we have something like uh the other project or something maybe maybe there is a world where we can just say so, just copy everything.

D

So this is okay right, but already we are saying that uh we require something a little.

C

D

More complex in a lot of places, I'm not not super a lot like already we're, seeing that, where uh we kind of require something like this.

B

But like where it's dev like dev or staging or jh, probably jh, more often than not right, yeah.

D

So already we're sending something like this and then, to put it even worse, is that this code, if you have this on the controller you're going to have to replicate the same thing in the view as well, so it's like very contagious technique of that. So whenever you do something like that chances are you set some some kind of um special thing? That's only an instant builder! It's only available in that and then now you have to do something. The same case statement in views as well so like it gets worse and worse. So some.

A

D

Will say: oh use. The case statement like that. That's just this is a reformulation of the email statement so and then contrast that, with what the application settings does or some other thing and we just go future application settings.

B

Yeah yeah, I get the general idea call some method with whatever the setting is yeah.

D

Whatever the thing is right and then like it's that like and you never, you never have to change it right. So.

D

So you know and then this.

C

This can be turned on all.

D

Like different different things, now the complexity becomes here.

D

You have to kind of ensure that for something on github.com, if you really want to turn this on, you write a migration, some script to automatically turn this on sort of thing, so yesterday some costs, then a trade-off where you have to manage to set up things, but it's far better to manage that on the data level than having to manage their own code.

D

So this is what I mean that makes sense.

A

I think uh to link back to the horse project, so imagine like we have a host project, which requires multiple deployments, and some of this requires similar features to like gitlab.com and some don't.

A

Then we need like going by the old way. We would need like individual of this branches added in, but by extracting that there was setting application setting or something like that. That is abstract.

A

um We can have like each individual instances of the horse, implement the same configuration and then that will provide them with the same set of features.

B

Right and it's unlikely that what's being done for jihoo, is done for that too, because, like what I can see when I was thinking about this a little bit more closely, I see the potential of project horse taking off and needing a similar like slightly different flavor of some of this logic uh in some some instances. Maybe I'm completely wrong here, but I don't think it would necessarily work for gitlab.com and our current um logic wouldn't wouldn't cover it.

B

um So so that was one thing that came to mind that I think could really uh reinforce. Maybe the urgency a bit more to some to other stakeholders who maybe aren't necessarily working in the code as much right. um I know there's a big focus on technical debt right now too.

B

I'm just trying to think how we can make the case to prioritize us a little bit better um and really I'll say like understand that testability aspect um where, um when, when we are on different environments, how do we ensure that that state is what we want to try to validate against.

B

D

I would say we are hitting problems with jh already, so that should quite a big part of this center. Actually.

B

Right- and that would be where maybe a word jinjin could could provide some ideas on, because I um so it's like, if the feature like if the application settings on do something for the feature, even in jh, if they're doing something slightly different with that feature, what would they do in that situation? Would they have a different application setting, or would they have?

B

Another branch in that in that method chain is what I I'm trying to understand like if we're just gonna shift the complexity to a new model, and it's still going to be the same amount of complexity or if it will really actually be simpler, and I'm sorry that I'm being dense here like this, is probably super clear to you and it's it's just not like.

D

I've been I've been kind of like thinking about this for a year now, so I got a bit away. It's done. um I understand. Yeah. I've had apprehension about shifting the complexity to the data model, but um I've been through this like twice now in different projects, not not gitlab, but you know previous roles. So a.

C

D

Or a database setting is always going to be better than randomly modifying code for different code functions, always always.

B

Especially where yeah.

D

uh And in times kind of like we call that white labeling, but you know like different instances, is our parents yeah.

B

Yeah that that uh that pattern, that fits with 12-factor app right, that, like this sort of behavior shouldn't, be managed like like it should be managed somewhere. That's.

C

B

D

B

Yeah configuration that's what I was looking for. I don't know why that word escaped. My brain could be that it's 10 30., that's all right and, as albert knows my day started her like five. Today too,.

D

B

My apologies go ahead. Yeah.

C

So so I think, like.

D

The question for me is that uh it seems like we don't know what the priority is and whether we want to start now or later. um Do you have any thoughts on that? I'm just curious. uh It's.

C

Someone, I know our own quality.

D

But I don't know whether you agree with that or not.

B

So I I would say my stance is that quality should be the people to draw the line and help equip teams to to do it. The model that you pretty much talked about it could be ep. It could be. um I think it belongs more with ep than scts.

B

But prioritizing it alongside everything else right now like rapid actions and why not rapid action, engineering allocations and other things, I I believe, would be a challenge for teams, which is why I'm trying to have a crystal clear, concise value statement that I could relate to start to at least relate to the other quality managers. To say this is something we need to consider much higher than what we are right now.

D

um Can I see things.

B

uh Albert I'm curious what your take is on this like there's not really to me. I don't see a team in development or another department that would steer these kind of efforts.

A

um Yeah, I think, in terms of going setting, drawing up that line and setting up helping other teams um make the migration will be sort of relevant to ap. In my opinion, but uh like actual changes like eventually um will still need to be done by individual teams who maintain the features. I think what we can do is provide the tools and guidelines on how what are the things that we can, that people can consider.

A

As an alternative to the dlab.com question mark.

B

Yeah, um so so so tong I'll I'll, probably um like one. I want to read through the issue a bit more try to be a little bit more direct about the problem that the technical debt is creating, so that we can look at the prioritization of this alongside I'll, say, reliability, support efforts. That ep is involved in as well as the rest of quality department.

B

It is just a challenging thing to just put somebody on right now, but I also see this runaway train like um if, if we don't have a good way of equipping teams, it's a hard thing to.

B

um I don't know um it's something that we need to think on a bit more for priority and urgency.

D

Yeah every issue I actually try to list out like why it is. Why is this problem um and and what what alternatives we have like? I try to make it as executive friendly as possible. So hopefully it's quite short. I haven't read that guy and my final kind of point would be uh it's probably better to start now, if you can, because there's only 200., yeah.

B

It's only going to get worse like it's not going to get better. I like it that that's kind of what I meant with the runaway train analogy like where it's not going to fix itself and when it's time to fix it, it's only going to be harder.

A

And yeah, okay number: it looks like it's exponentially growing like I think, all that in one it's like five per release and now it's about 50.

D

B

D

B

I I mean yeah, I think that's it on this. um I I appreciate both you joining um albert.

B

If this is something that you're passionate about picking up like- maybe let's, let's chat about it more next week on how we can refine this, um like, like I kind of alluded to today, I we're really gonna, look towards some small iterations of review app enhancements to really equip the create stage um with review apps that are fit for their purpose, to do validation for the definition of done changes, so that'll be an epic that I'm putting together tomorrow.

B

That's the only thing on the agenda and we're the only people here. So if this is all I say, we call it and I'll post this in the morning. For me.

A

B

Thank you for joining, and I appreciate the discussion on this. You all have a good rest of your day. Okay, yep.

A