Summarize this meeting:
I think it's just about leading the stop or the process, but it's not necessarily you doing
those processes. I think you're already doing well on asking the guild about the, you know,
rotating the ending of release. It's just that they are not that responsive. It's not like
anyone is willing to, I've asked him and he said that he's on flight this week, so he can,
but yeah, so the ideally we want to have a release candidate before sphinx review,
because sphinx review needs to be demoed from staging apps and production apps, and usually
we demoed the tickets that we did in the past film. So we want to have release candidates ready
before like I think Monday, since Tuesday's review, I think we need to have the PR, the PR
bomb that's bombing the version. By the way, the PR should bump the version. Like for example,
if we're releasing 3.14 now, the PR should be bumping it to 3.15. It means that starting from
that bump, it's already 3.15, and that will also get reflected to the preview builds.
Oh, okay, okay, okay, okay. So after we release 3.13, so from that moment onwards,
we bump to 14, right? From that moment onwards?
Yeah, yeah, yeah, yeah, yeah, we bump to 14. Should have been bump to 14.
Okay, okay, okay, perfect. Because if we don't bump to 14, then the other preview releases will
still use 3.13, like it will, and it will, like the good thing there is that you will see, for
example, you're developing a feature, you can check the pubspec file to know on which
full release it will be included, because we have already bumped that.
Yeah, I created a document where I tell there that we need approval from delivery leads,
so that they know, for example, if they have some tickets that they want to push before,
like it's a very important ticket, maybe we could consider that, but it should, you know,
we should then pass, we should still be able to build it before the interview, like we could just
tell them that if it's taking long, then they should just patch those tickets,
as we won't have a release candidate to demo. Okay, okay, okay, got it, got it. So Monday,
we will make the release candidate, and we will release on Monday itself,
such that we will have the bills for ready for testing on sprint review. That's, am I right?
Yeah, okay. And the end of day Monday. Every Monday, every Monday, okay.
Ian has a comment there, if maybe you could, yeah, if you could help me with updating the
documentation on that comment based on this discussion. Sure, sure, sure, I will do that,
definitely. He's asking for that. And yeah, so we don't need to manage regressions. We have already
talked to QA for them to delegate regressions to the squads, and it should be the delivery
leads responsibility to chase for regressions. Okay, like you could chase, like you could chase,
for example, to do a chase on the delivery lead. Hey, we still have regressions on,
you won't chase the developer, you won't chase QA, you just chase the delivery lead,
because it's the delivery lead that's activated to chase the developers and the QA.
Okay, so the delivery lead means like Hershey's the delivery lead, right?
Yeah. And for the, for the flutter? Hershey's the delivery lead. For flutter?
For, no, no, for a squad, it's a delivery lead for SEO, and they have some flutter changes as well.
Okay, okay, okay. What about the board of red owners, who is the delivery lead?
I think it's Greg and Martin. Okay, for the new squads?
It's in the platform. It's usually, it's engineering managers, and then I think the other
delivery leads are Hershey and then Norman. Okay, okay, perfect, perfect, okay, okay.
So we ask them for the patches, for the regression results, okay. If you think that there are just
tickets that have not moved for ages, like for example, we still have regressions and foundations,
then just, just, just, just, um, tag me that, hey, Blando, we're waiting for you. So, yeah.
Okay, okay. But, but, but, um, if the delivery leads, um, like, performs their responsibilities,
you shouldn't, you shouldn't chase anymore. Like, I think we will just let you know, we will just
let you know, or the channel know that we have already merged the patches and the regressions,
and then can we build a new release kind of new. Okay, okay, okay. And releasing is not your task,
just, just create a process and then the, you know, how, how, how you will rotate the, the
responsibility. Yeah, yeah, perfect, perfect, perfect. After that, when we release, then things
will go for regression and the QA will take it over. I know she will test it. So there was a
question, Orlando, like, you know, she was asking, like, which one we should, because when we release
to three of the builds, like to honor, uh, a you and also never tell. So which one should we test
first, and should we release all of them together always, or should we release priority to never
tell first, or do we have a process like that to prioritize which part of the app we release?
And, um, before in the past weeks, or in the past prints, never tell is our priority because
we are working on mostly us and city cats. Yeah. But now I think I'm not sure if we can do it in
parallel. It, it, it gonna depends. I think, um, the delivery, it's, it's the responsibility up to
the delivery lead to, to let you know, like to, to let you know that, hey, we can release this
without us releasing Navatal because some features are, you know, interconnected. But it's, I think
the approach there should be to use feature plan so that you, you release it simultaneously. For
example, if we have a feature that restricts login or sign up for Uber, then instead of it being
enabled on, on a release, and then there's a chance that you release on Navatal and then
it's, it's only restricted on Navatal, but not on native apps. And there are also other
users that are using native apps. So we can just use feature plug instead so that we can force,
we can force the version, like we can ensure that everyone is on this version first because
this contains the login restriction. And then we turn off before we turn on the plug.
Okay. Okay. Okay. Yeah. So then we go for testing them and also I will test that and she will let
us know if there are some regressions, right? And the delivery, delivery leads should be taking
care of that. And the person who is releasing, he should be keeping an eye on the regression
tickets. And one in one city is ready to be merged. So we make a patch. So how do we make
patches like, you know, when we have this multiple regression, should we wait for all of them to
complete or do we have an agenda like we make the patch releases after one after other?
Yeah, that's a very good question. So we can definitely, I think it's gonna be faster if we
could verify, verify the patch. And it's not like, for example, for it's true that maybe we could at
least release one, one will release candidate per day. We could standardize that. So, so it's
just a release train. So we have our RC one today, and then they, and then squads will fix,
can fix their regressions. And if they want their fixed to be included, they need to be,
they need to merge the patch. We are like, for example, can set a time, you can set a time,
I think that's the problem with it. I'm too flexible. And that's why everything is being
extended. It's, it's your, it's your strategy as the new owner, you could maybe set a schedule, hey,
hey delivery leads, I'll be releasing a new release candidate at this time. So please
ensure that you have merged your patch PR or patch fix any. Okay, okay. It's their
responsibility as well to operate a patch PR. Okay, okay. So then we mark the patch release.
So then again, we, we, you don't merge the patch. You won't merge it. You'll just create the new,
the new release based on the latest. Okay. Oh, so the patches will go to the new candidate?
Yeah, it's, yeah, it's the, the, the reason why I created it that way is because when I was doing
patching, I was doing patching before on my own. And it was, it, it was very hard to fix the conflicts
on my own because I don't really understand how it should, how it's supposed to work. So,
so it should be the, the squad's responsibilities to, to ensure that their, the picks on the
regression is fixed, is merged on main and then they create another patch for, for the release
branch. Okay, perfect. I understand. Okay. Well, next question is like on last, last day I have
seen like some problem happened with Nava tile and we rolled back our release, right? So I'm not
sure yesterday, I'm not sure about that yesterday. Not yesterday, not yesterday, but I have seen the
comments like you did the RCA and the last last week. Okay. Yeah. Yeah. So how do we deal with
those situations? Like, how do we understand like, how do we do actions? How do we roll back?
Well, I, I actually just rerun because since we're not like rails, rails is always deploying from
the head of master as we're just, we're just based on git tags. So you could deploy, deploy from
anywhere. Okay. And to roll back, we just, for platter web to roll back, we just need to rerun
the, for some, the build, the bitwise or GitHub action builds, whichever build it is. Okay. Okay.
Then it will deploy the exact codes. Okay. That's why you could, you could also replace it. For
example, once this has fast testing, then this is already good to go, we can replace it with another
bit. Okay. Maybe if we could solve the challenge, if we could have multiple staging
environment as well, the, the thing, I don't want to copy the, the, our approach on preview and
staging because we want staging to be almost the same as production. And there are complexities,
like for example, Uber, boosted checkout, it, it needs, it can, it just works on a fixed callback
URL. So you can't really use versions there. Okay. Okay. So things like that. Yeah. Okay. Okay.
Maybe one of them thinking is that, yeah, because they usually they, they want to test the old,
like the old version, the currently released version to verify if a bug is, if a, if a regression
is indeed a regression. Okay. What we're doing is just we're deploying it on preview. And I think
they can also deploy it themselves the way they're, they're also technically not. So it's just about
enabling them maybe. Okay. Okay. Okay. I understand. So then how do we, when you say about patches,
like, let them do the patches and do, they also, do we make releases in between from Monday to
next Monday? In between, do we make releases or do we do the patch testing only using preview
environments or do we actually make releases in staging for that, for the patches?
For, for the patches. Yeah. We also, we, you can just like what I said earlier, you can do it on a
daily basis. Okay. One at times, specific time, then they will do the PR and they can do the releases.
Okay. Okay. Perfect. I understand. Okay. Okay. Okay. So what if, what, my next question is like,
what happens if some regressions are not over on next Monday? So it will be kept for the next
release, right? It will be over, it will be passed for the next release, right? So we need to,
sorry, sorry, sorry. Actually, we release for 90 or do we release on every Monday or do we
do release just before the sprint review on 490? We release 490. So if a regression,
a regression needs to be fixed before we release. Okay. So what we're doing is, for example,
if it's take, if it's too complex, if it's taking too much time to be fixed, then either we ask the
PM or EM, like, do you accept this as a bug? Because it will, once you release the,
that version, then the regression will now become a bug. Since it's now, it will now be in our
production environment. But the other approach is you could, if you know the ticket that's linked
to the regression, then we could just revert the ticket. Okay. So because it still has regression
and we don't want to introduce bugs to production. Okay. Yeah. Okay. Okay. So we will revert that
ticket. And then we release, then we made for the patches to happen. But it's going to be the
squad's responsibility. Responsibility. You just, it's, you just need to chase them. Hey,
it's this, this release is taking too much time. You need to decide now, like, it's either you
revert them or you accept, they need like the PM needs to say that, okay, I accept them as bug,
so that it's not our fault anymore. Like, the PM has already accepted. Okay. So after doing this
regression, when do we actually release to production on Fridays? Or when do we alert
Chris for releases? Or we don't release on Fridays, at least for NABATL. Okay. But for,
for native apps, I think QA can just tag Chris. And then Chris,
usually I'm already asking Chris before, like, for example, if I feel that, if I feel that this is
the, that there, there's a chance that there's no regressions anymore on this release. For example,
you, on Monday, you find five regressions and then you were able to
fix four of them on Tuesday. You know that, that RC two, the RC two won't be released because
there's still another regression to be fixed. Then RC three, you have already completed the
fix. So you can already ask Chris. Actually, you can, even when you start the release, I think,
on Monday, you can already ask Chris, Chris, can you help with the release notes?
Okay. Okay. Okay. Yeah. So he's only the engineering managers can put it to stores,
right, to submit to stores. Since you're the owner, you need to be admin as well. So you could,
you could put it in the stores. Okay. So let's say if I am not releasing manager, so someone
else is releasing and he don't have the access. So how do we proceed with that? Who should he,
for example, I'm asking Shan for this week's release. So we, when he wanted to put it to
production, so whom should we, whom should he approach for making the release?
Yeah, I think we, you know, this one, it's, it's not really about trust. This is about,
these are sensitive stuff that when you did, like you, when you were not that careful, for example,
you, you lack attention to details that you missed the pace release, for example,
and you'll lose 200% or maybe you picked the wrong deal. So usually you, it's just the EMS and
and the flat, the app owner and the app managers. So they need to reach out. I think there will
always be EMS online or whatever, or Chris will also be online. Okay. Okay. Perfect. So actually,
that's the other loophole of our release process on Navatal. Anyone can just tag
every branch. We need to restrict, I think we need to restrict release, production release.
Yeah, I got it. Yes. Perfect. Okay. Okay. So I think I covered all of my questions. So
I will bring you whenever I have some, because all these questions I have,
creating confusions and I don't know what to do. So yeah, just, just, just feel free to
huddle with me anytime. Okay. I'll be glad because you're helping me. It's, it's my payboard to
be honest because you're, you're letting me, you're paying me off responsibilities. So
I should be, I should, I should help you. So don't be, don't hesitate to ask me.
Definitely. I will do that. I will create a documentation based on whatever we discussed
and so I will create a documentation right away because I don't forget things. So I will
make a document dots first and then I will document that. And then after creating that,
I will submit to you for revision. Then we can revise it and then we can pass like that. There
will be a clear cut process written for the release. Then next week onwards, we can ask
someone to release and try. For example, we can ask Shan to release and let's see what are the
blockers he's facing and then improve on that documentation and we can move forward.
Actually, we need to, I think we haven't released 3.14 yet. We haven't started releasing. We need
to start that release soon. I mean, since we have, we didn't have any release last week, right?
Oh, okay. Yeah, we don't have it. Only 3.13 was the last one. Yes.
At 3.14, have you released 3.14? I think we haven't started 3.14 yet.
Yeah, we haven't started 3.14 yet. We should start 3.14 as soon as possible.
Since it's already in June, it's supposed to be, we were supposed to start its release last Monday.
Okay. But it's fine. It's not me. Yeah, I understand. So because I was learning and I don't
know, like I was confused, like what happens and things. Now I got almost, almost all of them
in my head right now, but I will bring you any time when I need your help and I will ask you for
help. And should I initiate, do you think it's today, Monday, so I can initiate 3.14 as your
least candidate? Yeah, yeah, yeah, you can, you can initiate. Okay. Thank you so much. Thank you so
much. Thank you for your time. See you. Bye. Yeah.