Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

And this is Aaron. So, Joel, I've went on record and I've sat down in the podcast I believe, I've written blog posts about it, and everything about my strong support for down migrations in Laravel projects in a database layer.

Here's a challenge for you, because I think you agreed with me. What were my points? What was the reason why you agreed with me? What was the point of that? Why did I support down migrations so strongly?

Is this a pop quiz, Aaron? Are you challenging me?

Maybe. Because you agreed with me so you must agree with that too.

Don't say past tense. I do agree with you.

Okay.

In fact, I've gone on record pointing people to your article. So-

Okay.

... my takeaway from it was two things. Yeah, maybe there's a third, we'll see. But for development, when you want to switch feature branches and do this and that, sometimes it is nice to just back out one migration, switch a branch, apply it, back it out, and so on.

So it's kind of like a local development experience. That's one thing.

Yeah. And, you're right, that was both as a developer as well as my role, I'd later said, as a team lead or a manager.

Oh, yeah.

Because sometimes I was a developer and would move through multiple projects in different branches. Other times I had team doing that, and so my job was to check out each branch. Kind of move through them and approve all of them for that week's release.

Yeah. So, you're probably bumping into it even more in that role than as a individual dev. The second thing, and maybe even a stronger reason, at least one that resonated with me. Is the sheer act of creating the down migration and testing it locally was almost like...

It's not quite the same as writing a test, but it like forces you to think through the problem in reverse. And every once in a while, not a lot, but every once in a while, I'd be like, "Oh, I actually don't like the way that migration worked because it was hard to write it down."

Or, like, "Oh, that was destructive. There is no way to write it down." And it just gave you pause and another opportunity to think through the schema change that you intended to introduce.

So, I don't disagree with the first part of that. But the second part, where you kind of said where it showed whether it was destructive or not, that kind of points a little bit to the first part. Which is, are you moving your data forward irrecoverably or not?

Right.

And so, a down migration helped you understand what decision you made moving forward. Not whether it was right or wrong, but it helped you solidify that that was that decision moving forward.

Yeah, that's fair. And then I guess the third thing I'll say, and this I think I'm pretty sure you acknowledged this is way, way, way down the list of reasons to do it, is if you ever actually had to use it in production.

Like, I think we've even had a podcast episode where it's like, I don't think I've ever run down in production. Because by the time you notice something's wrong, you probably would just destroy data a different way if you tried to run it down.

But that is a theoretical thing that you could have deployed it and half a second later noticed it was wrong and wanted to run down. So, that's like a very, very minor reason.

Okay, great. Great summary. I couldn't have said it better myself. And I don't know if you remember, we had another different podcast episode before, but I think I'm wrong.

Oh.

I think I was wrong. Well, I don't know, wrong. Again, it's nuance here. So, I think I'm changing my mind that I don't want to write down migrations anymore.

And I have spent a lot of time reading a lot of the supporters for no down migrations, and I was able to reconcile their opinions against my choices in the beginning, being like, I disagree, you know?

Okay.

And as I kind of went through that some more, I'm not sure if it was their input. I mean, there was a lot of cool blog entries, some from other members of the community that we all know. Or, if it was, you know, just looking at the actual use case that I'm working on now, which is a lot more smaller teams and stuff like that.

Or any of these different things. But I think I've gotten to the point where maybe I don't want to write those down migrations anymore. And there's a couple of things, a couple of different directions we could go.

We could either talk about why not, or I could sort of re-argue all those points that you supported and say why those don't actually matter or apply with what I now know.

Yeah. I mean, I think I would start there. Because deconstructing the original argument would sort of chip away at the foundation, and maybe any resistance I would offer to why you think not writing them is a better approach now.

Okay, cool. So, the very first thing was sort of keeping your data intact when you're doing local development and switching between branches and stuff like that, right?

Yeah.

I found that as I understood my migrations running from fresh, you know, migrate fresh and then running seeders, I should be at a point where I can use my application no matter whatever code change I'm working on.

So, if I am developing code that has new data in it, well, one of the very first things I should be doing, I think, is writing seeders to put data into that even before I have a UI. Because otherwise, how can I exercise my UI, you know? And it's a chicken and egg, of course.

But I tend to write data into there just to make sure that the model made sense, you know, my fields are all there. And as I build out that factory for it, I kind of understand what's in the database.

And building out a factory and being able to run some setup for my local, not for test, but for local development, sort of will explain to me whether or not I even have the right columns, stuff, and if they're nullable or not, and things like that.

I can look at that data structure because I understand my data structure, it doesn't necessarily match with the UI all the time. So, I'm one step further removed from what the business needs, but I'm looking at data structures and I'm kind of building that out. Does that make sense?

Okay. Yeah, it does make sense. And, as you were... I mean, first of all, I agreed with your reason for having that. Like, the team scenario. It was not one I felt a lot personally, but I could see, like, "Okay, I don't work on a lot of big teams.

I'm not, you know, reviewing a bunch of junior devs code." So that one was already a little weaker for me from personal experience. But as you're talking about it now, it's like, "Well, yeah." Like, when you and I work together in that scenario where I'm pulling down your branch and playing around with it.

I do just run migrate fresh seed. Like, it's not even a second thought to be like, "Hmm, do I have any committed migrations that I should roll back?" So, I'm tracking with you so far.

And I want to take a little bit of a side on there, though. Which is, it's interesting because I developed an answer for database migrations, whether or not I should use them or not. Which was dealing with, I believe, the pain of the issue not necessarily solving the core issue.

Which was, I shouldn't have been writing those, I should have been making sure that seeders were written. It kind of shows me that I was pointing at the wrong things with that as a solution, as... And that's easy to do, you can kind of cover that up, and like, well, I want to move forward.

But that wasn't the... It actually required more work, maybe the right to seeders than it did to down migrations too. Not sure, maybe. Probably actually.

Yeah. Well, I mean, you have to keep writing seeders as you add models, and you have to keep writing down methods as you write migration. So, I guess it's which one do you write more of over time, which would take more effort.

But I agree with you. Like, we always preach about not having your local dev database be this pristine thing that you have to maintain at all costs. It's like, it's a development asset, you can blow it away and restart, and nothing should be lost of importance.

So, this aligns with some of those other things that we've already made decisions on, so I like it. What about that second one, though? That's going to be an interesting one.

The second reason was kind of more about, you know, are we doing destructive data migrations one way or the other? And that one's a little bit more fuzzy on this because that's sort of something you kind of brought up that I actually hadn't really thought through that much.

I don't remember making that point, but it's not that I didn't make that point, I just don't remember making it. It's one of those things again where we kind of go to the first point, which is like, that migrations was a tool set that was covering up some sort of symptom of another problem.

So, this would be another situation where it's like, well, if you write it down migration, you kind of show that you would maybe had destructive data. Well, maybe you should never write destructive data then. There's nothing wrong with moving your stuff forward in two steps, right?

Yeah.

So, maybe it's one of those things where, again, it's like, well, that was a tool to catch a problem or show you where there could be a problem or kind of elevate that into your mindset. But maybe that shouldn't be a problem at all.

Yeah. And, you know, thinking more about it, it's not like there's no destructive change that isn't visible. Like, it's going to have a method, like drop column or drop table. You know what I mean? So, it's not like it's hidden in there.

Whereas, writing the down forces you to recognize it. Like, the person reviewing the code at the least can look at it and see it too. And the two-step thing I like better anyways. Especially when you get into deployment scenarios where you have multiple instances of your app running.

Like, you have to do that anyways. You can't just drop a column while something might still be using it, so it has to be a two-stage thing anyways. So, I have to think more on it, but I'm there with you so far. Like, nothing so far has made me like reject it out of hand and be like, "Aaron."

Yes.

"We have to stop this podcast right now. I just can't see eye to eye with you anymore."

"I want to argue with you offline."

That's right.

Well, and then the... Okay, so the third reason. You know, I can't really argue one way or the other with that, but what I can say is that maybe the first step would be for us in our projects.

And I'll be real honest about this, is having a button somewhere, I guess in GitHub or something, where I can take the site down.

Like maintenance mode down?

Yeah. Because what we're really talking about would be taking it down, maintenance mode, migrate back, and pull it back up. Right? That's the whole process. But we don't even have a system even take it down if there's a problem, so I think that one's more of a middle ground.

Where it's like, "Hey, maybe in a perfect world I could migrate this all back, but is it necessary?" And also, is my change so very small that there isn't other things that are working successfully that have user data that I could undo?

So, it might be that, like, let's just say there's four positive moving forward changes. Three of the four work, another one's buggy. "Well, I'm going to get rid of the three of the four that have good data in there. I just want to stop the website right now and figure this out."

So, I think it's really that... Like, reimagining that I was like, "Well, we're not even at a place where we kind of take down the website if something goes wrong. We just kind of try to fix it real quick. So, again, a down migration was sort of a sort of tool set that point at a different problem.

Yeah, I think whether or not you're going to write down migrations or whether or not you're going to ever plan on using them. The thing you're proposing, which is like an emergency break-glass, easily take the site offline without having to SSH in everywhere and run the command, makes sense.

Like, it's a good safety mechanism to have. Again, you hope you never have to use it, but if you ever do, having it there will help a lot.

So, I kind of just sprung this on Joel. I sort of alerted him that it was something I kind of wanted to talk about, but I didn't tell him that my mind is drastically changed in this way, and I feel reasonably strong about it.

So, I'm not sure if this is the end of this conversation, but it kind of shows that, you know, you should always be looking at these things and say, "Are the decisions that we made making sense now as it did in the past?" And, "Are they addressing the actual issue, or was it just a cover for something else?"

Yeah, I like those principles. And just so you know, I'm not done talking about this. I have one more question to ask you, maybe two.

Okay.

So, keep those principles in mind, that's a good takeaway. But I guess the first thing I have is a comment, and I just want to draw a distinction because... And you can distance yourself from this if you don't agree.

I would say, for myself personally, when I would see people talk about, "Oh, we don't write down migrations," it was almost like cowboy coding. Like, a pride in like, "We go fast, and we don't want to do this."

Absolutely. I completely hug onto that. That's a thousand percent why it would also... That's the reason why it triggered the whole argument in my side too.

Which was like, I never really took that strong of a stance, but when people started being like, "Oh, yeah, we move fast," and whatever, "It's never going to matter." It's like, well, have you worked in the enterprise world before? It does matter.

Yeah. So, you know, and maybe the principle there is like you and myself, maybe we overly reacted to the attitude without thinking about the actual message, but we're coming around to it now.

So, that was one thing. You know, so this is not just like, "Oh, we just want to save time." It's like there's a reason for it, we've thought through it.

Right.

It's discussed at length here. My last question, would you go so far as to change the stub file to not even publish a down method? Or, would you just make migration and just delete down or leave it there with a note or something? Like, I'm just curious.

I don't really edit my stubs.

I don't either.

I probably should. But to be real honest, that's a great idea, but I'm not going to do it.

Okay. Yeah, I just love defaults. Like, even if I don't agree with the default, I'd rather have it and change it. I don't know, that's just my off-the-cuff.

I was just curious what you thought. So, anyways, think back to the principles Aaron shared. That's a better way to end this, but I just had to satisfy my own curiosity.

I've been working out a little bit lately, and that's been doing some stuff to my clothes. Makes them a little bit looser. It's awesome. I mean, that's-

Good problem to have.

Yeah, I like it. But something happened recently because of this that I wasn't expecting.

Okay.

I open my windows in the morning, and I live in an apartment complex, and I can see my other neighbors, but we don't really... I don't wave. But, you know, you can see them. I think I've even mentioned that before. Like, you can see stuff in the window sometimes, not a big deal.

So, I open the window, sliding door, letting in some fresh air, and I suddenly get really cold and see my neighbor make eye contact a little bit, and then I realize something horrible has happened.

I have just Donald ducked my neighbor, and I immediately then closed the sliding door, the curtain, and ran away. Do you know what I'm talking about?

Oh, absolutely. Yeah, absolutely. Like, of course.

Okay.

And I never want to be there, but I know what it is.

For those who don't. Donald Duck being a character who famously wears a nice, amazing top shirt and has no bottoms. So, apparently, I had woken up in the morning and started doing my morning routine, forgetting to put on the downstairs, and I just gave my neighbor a free show. So oops, quack.

You're welcome.

It's always a good time to refresh your knowledge, especially now. Have you checked out Mastering Laravel at all lately?

We're publishing new things every day, whether it's tips. Or, maybe check out one of our books that you missed. So head over to masteringlaravel.io.