Every two weeks I send out a newsletter containing lots of interesting stuff for the modern PHP developer. You can expect quick tips, links to interesting tutorials, opinions and packages. Want to learn the cool stuff? Then sign up now!

A checklist for all projects that are going live

Apart from our open source work, we do client work at Spatie as well. Over the years we’ve learned that one of the most critical moments of a project is when it is going live. No matter how you confident you are about the correctness of the code base there are so many big and little things that could go wrong when moving to production.

To make sure a new project is launched correctly we’ve created a list with important items to check off. We’ve shared our checklist on GitHub. Some items are specific to our workflow, bust most things are applicable to any project. There are also tasks on the list that we take care off well before launching but verify again just to make sure that everything is in order. In this post I want to highlight a few items.

  • Use the Chrome DevTools and throttle your CPU and network with 10x CPU slowdown and set the network to “Good 3G”. At our office we use modern Apple hardware and a fast internet connection. Mobile users probably have a much slower internet connection and slower CPU.
  • Check all pages for n+1 problems. Because we use powerful hardware we’re probably not noticing any n+1 problems while developing a project. We use Barry vd. Heuvel’s laravel-debugbar. That awesome package can report all queries that were executed when rendering a page.
  • Add redirects from old to new pages if necessary. Redesign an existing site will often results in a changed site structure. We don’t leave people (and search engines) in the cold and provide redirects from the old urls to the new ones. To manage such redirects in a Laravel app we use our home grown laravel-missing-pages-redirector package.
  • Verify that all http status codes are ok. Links to missing pages are really not classy. That’s why we unleash our crawler on the new site to make sure that links on all pages return a good response code.

The checklist contains many more items. Take a look at the entire list on GitHub: https://github.com/spatie/checklist-going-live

Do you think we’ve missed an important check? Submit a PR.

Freek Van der Herten is a partner and developer at Spatie, an Antwerp based company that specializes in creating web apps with Laravel. After hours he writes about modern PHP and Laravel on this blog. When not coding he’s probably rehearsing with his kraut rock band.
  • zakius

    This list is surprisingly short.
    Especially I miss “backup your staging server that is currently 1:1 the same environment as current production, throw updates to staging, if anything breaks fix whatever happened, restore backup and update again”
    or something like that
    I’m disgusted by how many people think that testing environment can vary strongly from production with no risk or issues

    • How a testing/staging environment should be handled depends on the size of your team and the project itself.

      There is value in seeing that how you do things isn’t necessarily applicable to others.

      If you think we miss some basic items, you’re free to submit a PR to the repo. Or even better, share your own checklist so other can learn from that.

      • zakius

        My perfect (and impossible) personal rule is to have production, staging, testing and local exactly the same in terms of OS, hardware and installed software (with precision to the build), but I’m aware it’s extremely strict, and actually locally I use only virtual machine being software wise as close to production as possible, it saves me fixing weird stuff on testing on staging. Of course I can’t force this rule on anyone, but having at least staging being exact clone of production is the minimum I see as responsible, this way chance of something suddenly breaking on production is reduced drastically.
        I don’t have full checklist yet as I’m just starting working on my own projects seriously and earlier I just did whatever I was told to, but that was enough of experience to know that some things break if you change even minor version of software used

  • M.Elwan

    I was really missing the first point I don’t now how actually and the package needs a look as all of spaties packages actually. I just hoped if this article had more items in the list. thanks Freek