On today's episode of what happened at work this week, well it's pretty boring. I've been tasked with building out a mobile application in nativescript for our web app, and I got pretty much nowhere on it outside of setting up a local environment, which honestly might be a post in itself but I'll save the next few weeks for when I make some major progress. So today I'm going to talk about something that I consider somewhat controversial as far as what I'm doing but the more I look at it the less guilty I feel about doing it.

So lately we've had to make some major changes in our Models, for instance we went from html to markdown and then back to html again. Why you ask? Well to be honest our admin dashboard is built in Nova and the markdown editors were not quite giving us the flexibility we needed, not to mention there was a mass import from a WP database and not all of the data was synced properly. That my friends is a story for another time and another place. So ordinarily for something like this I would create an artisan command and then once working locally I'd run the command on forge and BAM. Is this bad? Not really but then you get to a point where you have quite a bit of "one off" code that will literally never be used again in the project.

So in come laravel migrations. If you don't know about migrations in laravel this won't make any sense and I highly suggest going over to Laravel and reading up on them as well as all of the documentation available. Outside of some small little one offs, it's 10 / 10!!!!! So I'm going to pretend that I now know about DevOps for just a minute here (I really know nothing). So with every web application that I have every dealt with there is always some sort of pipeline that will integrate code from github to code on the server. Well in our project we use forge and it's connected to our git and yea we have a dev / staging / prod (like most people would / should) and whenever the associated git branches are merge, code is deployed. During this deployment we clear cache / npm install composer install and run migrations before this code is fully deployed. Why do we do that? Well if we update packages / models, we want everything to be on the same page before code is fully deployed. Make sense?

So here is the "beauty" about writing code into a migration. If the migration (code) fails, code is not deployed, you can fix it (which you should have tested it thoroughly before hand with hopefully a QA team, but in real world situations not all of us are that lucky). Also migrations are never run twice unless you rollback (which I personally have never done on a production server). It's all about version control and laravel keeps migrations in the DB and what is ran / when it is ran. So once your code is ran you can remove the code, keep the migration or remove it all together since it won't be used again. So why is the better / worse than a command? Well honestly I'm not 100% sure it's just something that I've been doing recently and just showing an option to other devs out there. Here is an example of what I'm talking about:

        Schema::table('bookings', function (Blueprint $table) {
            $table->integer('cost')->nullable();
            $table->integer('cost_per_extra_customer')->nullable();
            $table->integer('extra_cost_after_customer_count')->nullable();
        });

        Booking::chunk(100, function ($bookings) {
            $bookings->each(function ($booking) {
                if($booking->trip) {
                    $booking->cost = $booking->trip->cost;
                    $booking->cost_per_extra_customer = $booking->trip->cost_per_extra_customer;
                    $booking->extra_cost_after_customer_count = $booking->trip->extra_cost_after_customer_count;
                    $booking->save();
                }
            });
        });

So we discovered this bug, well not a bug just more of an oversight and realized we needed to adjust one of our models. We had to add a few columns to the DB, and I figure while I'm doing that I may as well get some data for those columns. As you can see I chunk then loop and if there is an eloquent relationship we save data!!!!!!! Look at that. Why chunk? Well we don't want to overwhelm our server and timeout. Why not put everything into jobs? Well again more code that will only be used once and that would bog down our server as well. So is this solution reasonable? Honestly I am not 100% sure. I know that it works and it is something that I use now when needed. I'm not sure if this is acceptable for all devs but again I'm just showing you all what is out there. I learned this from my Lead, who learned it from a friend, whom I honestly don't know if they still use this technique. The one thing I will say about this is as you would with a command use caution. Anytime you modify entire tables, make sure you test test test before running this up on production. And make sure you back your production DB up just in case you screw up. What you don't screw up? Well sorry you are perfect, me on the other hand any time I push to production I clinch myself hoping that there are no errors. Why am I not confident? Well I am but one error that shuts down an income stream for an entire company is rather stressful, and if you don't think it is then you are just a better person than I am. Hope everyone has a good upcoming week ahead of them.