Minimize downtime when deploying new code to your Laravel site

I deploy my Laravel site using Ploi, but I was facing a problem: since I don’t use the zero-downtime option, how can I minimize downtime when deploying new code to my website?

NOTE: This article will be updated over time with any new tricks I discover so check back to see what else you can do. They should also work with all deployment tools like Laravel Forge and Deployer; I just happen to use Ploi.

Don’t recompile JS/CSS assets if they haven’t changed

There is no sense re-running yarn run prod if there’s nothing to do, so instead of just doing

yarn install --save
yarn run production

or

npm install --save
npm run production

let’s be intelligent about it:

# Dump the list of filenames changed in the last git commit
git diff --name-only HEAD HEAD~1 > /tmp/gitdiff.txt

# First, assume there were no changes
yarn=false

# Read the /tmp/gitdiff.txt file line by line....
while read line; do
    # The regex to search for CSS/JS/Vue/.lock/JSON/PHP files in the resources folder
    # We include PHP here in case you use PurgeCSS
    positiveMatch='^(resources\/|).*(css|js|vue|lock|json|php)$'
    negativeMatch='^(composer|public)'

    # Check to see if any those filetypes are listed 
    if  [[ $line =~ $positiveMatch && ! $line =~ $negativeMatch ]]; then 
        # ...and if so, set the yarn flag to true
        yarn=true
        echo $line
    fi
done < /tmp/gitdiff.txt

# If any changes were detected, run the necessary yarn commands
if $yarn ; then
    yarn install --save
    yarn run production
fi

# Cleanup
yarn=false
rm /tmp/gitdiff.txt    

And that’s how you can minimize downtime when deploying new code to your Laravel site!

Microsoft Ignite 2019 Sessions: Were you there?

Microsoft has posted all of the content from their Microsoft Ignite 2019 Sessions, including videos, slides, demos, and other content! You can access them by visiting https://myignite.techcommunity.microsoft.com/sessions.

I strongly recommend the OPS[10|20|30|40] track if you are at all interested in streamlining your organization’s operations. All 5 presenters (David Blank-Edeman: OPS10, Jason Hand: OPS20, Jeremiah Dooley: OPS30, and Neil Peterson: OPS40) were all super knowledgable and were great to chat to after the sessions too. Their sessions were not Azure-specific, but rather focused on operations in general. All 4 sessions were hugely beneficial to me and I hope they are for you too.

If you are in any kind of position that has any sway over the IT or IS arm of your company, you should definitely check out the Microsoft Ignite 2019 sessions content as I am confident there is something valuable in there for everyone.

Cloudflare – Error 520: What is wrong and how to fix it?

We recently ran into an issue setting up a new DNS entry on Cloudflare, using the orange-cloud (reverse proxying) feature, but we were receiving Error 520 and were curious what was wrong and how to fix it.  The error page itself doesn’t give a lot of information and since it’s a custom error they’ve created, it wasn’t easy to find out or even intuit much information about what it might mean.

To give some backstory, we are using a SaaS provider of a service for our employees that we want to protect behind our own domain. For example, instead of using ourcompany.saascompany.com, we wanted to use something like saasservicename.ourcompany.com. The provider supported this and so we set up the record within Cloudflare but as soon as we tried to visit the page, we received Cloudflare’s infamous 520 error: “Web server is returning an unknown error”.

After trying to troubleshoot the problem through Cloudflare, we turned off the orange-cloud and figured out that the SaaS provider hadn’t installed our TLS certificate correctly and so when Cloudflare was attempting to retrieve our instance from their server, they were receiving the NET::ERR_CERT_COMMON_NAME_INVALID. In response to that, they were throwing their own custom error 520 (it is not an official error code).

As soon as the vendor fixed the certificate issue, the 520 went away and we were able to re-enable orange-cloud, confirm that the site was up and working, and continue on with life confident that an attacker would not be able to determine who is providing the SaaS service for us.

Posts navigation