Checklist: 8 Things to Do When Launching Laravel Project LIVE

After having launched a couple dozens of projects with Laravel, I decided to create a checklist for the launches. The problem is quite often something is forgotten or overlooked - either from our team side, or from the client. So this checklist should prevent it and possibly would help you in your launches too. Disclaimer 1: not every step here is required for every project, please choose the items for your project(s) in particular. Disclaimer 2: some of these tips can be useful to other web-projects, not only Laravel. So, what do we need to take care of on the day of the OFFICIAL launch?

1. Manual testing on testing/staging environment

You do have testing environment, right? Some people call it testing, others call it staging, but the point is the same - some remote server to test the project for both developers and clients. To make staging environment work conveniently, you might take care of so-called “database seeds” - the main data which comes as the first filling the database for the project launch. Deal with the client, what that data should be, and try to keep it as close as possible to future live database. Now, there’s a couple important points here - first, staging server has to be as much similar as live server. Same operating system, web-server configuration etc. Then you minimize the chance of something going wrong after you move to live server (also called “production”). Quite an often mistake is for developers to test locally with Windows operating system and Apache web-server (or something like XAMPP), whereas staging/production servers are Linux-based with Nginx server. Another important note is that the client needs to be heavily involved in this testing. By this point you should be performing not only technical testing (a.k.a “if nothing breaks, we’re cool”), but also business logic - something might be missing or overlooked. After this part client needs to sign-off (in whatever form you agreed) the launch and then you go live.

2. Manual testing on live server

This is the phase that often goes wrong - you've tested it all locally and on testing server, but when you move and go live on SomeFancyAddress.com - something is broken. And it’s not about functionality all the time - it may be a domain redirect, SSL certificate (you do use SSL, right? It’s easy and free now), different/invalid settings or missing configuration files. Now, there are two ways to perform this “live” testing.

If your launch can be "silent" - you can actually go live and just not tell anyone. Tell the client not to launch any marketing, write any blog posts or tweets, spend a day on actually testing it all.
Or you can "fake" the domain and assign server IP address in your hosts file, therefore having this as live.

When testing on live, pay special attention to any 3rd party integrations - like email/SMS sending, payment vendors etc. They have quite a big risk of not working with live configuration, which is different from stating environment variables - usually all of those 3rd parties have some kind of a “sandbox” but please please make sure your live environment works as well. Another notice: make sure that live-version visitors don't see what they shouldn't see: like "Whoops" errors (build all 404 and other error pages templates in Blade), Laravel Debugbar, JavaScript console.log() statements etc. For that it's usually enough to have APP_ENV variable as "production" in your .env configuration file, but it can depend on the project.

3. Quick and clear deployment procedure

You need to know how to proceed with any code changes you need after the launch. Chances are, you would need to fix something as quickly as possible, so you need a procedure for quick deployment. Things like:

Who has access to the repository/server?
What is the process of working with repository: branching? Merging?
What is the process of documenting the committed code? Commit messages are enough?
Is there a Deploy Now button, or is it just "git pull + composer install", or is it a shared-hosting with FTP?

This is where I will stop and will take a little offtopic.

For the sake of successful project, do not use shared-hosting environments for Laravel projects.

Gone are the times when dedicated servers cost a fortune, and also there are things like Digital Ocean / Linode / Amazon AWS that take most of the pain away in terms of set up. I’ve written in the past how to work with shared-hosting and Laravel, and it is possible, but then you basically lose most of the advantages of modern PHP frameworks like Laravel - by not having SSH access you cannot launch Terminal commands like “git pull”, “composer install”, “artisan migrate” etc. Therefore you need to do it all manually every time - both when deploying the project for the first time, and for every future release. And you know this process is not only pain in the neck, but also quite ricky to forget something, have unstable FTP connection etc. In our experience, we did accept clients with shared-hosting before, with their argument of “we have a hosting company and don’t want to move anywhere”. But after the clients saw the deployment process slowness and hell (which they paid additional for), Digital Ocean was introduced pretty quickly. Win-win.

Also I recommend to make your life easier and use tools like Laravel Forge and Envoyer for deployment and server management. Totally worth it, especially when you are in charge of multiple projects - you can basically forget SSH and Terminal. Another point - for every deployment you should ensure either zero downtime (this is where Envoyer comes into place), or a proper “Deployment is in progress” page - the one that is shown on “artisan down” command. And yes, make sure you run “artisan down” when deploying. You might even go one step further and introduce some notification to your visitors - like deployment will happen at such hour soon. Finally, a few random deployment tips:

Do not deploy to live on Friday or at the end of the day
When deploying, be prepared to have at least an hour of time on-duty (not only for development team, but also customer support), if something goes wrong.

4. Error reporting procedure and tools

What happens when someone hits some bug on the website? It might be not you or your client, it might be a random visitor. You might not even notice the bug. But they will. And your client will suffer from that. Of course, you can and should monitor laravel.log file which collects all the errors. But it's not that convenient - the file (or files, if you split them by date) gets bigger and bigger. What I recommend is to use an external tool to notify you about any production bugs, and then automatically sync them to your project management software like Trello. Within our team we use Bugsnag and we're really happy with it, but there are other alternatives. And before you say that paying 29 USD/month is expensive, when you can do the monitoring yourself for free, wait until you have a dozen of projects to monitor - this is where power of such tools come alive.

5. Automated tests (for bigger projects)

This one is pretty controversial - some people love tests, others don't understand their value and think it's a waste of time. So read it with caution - here's my personal opinion: I am a fan of using something only when it makes sense from business perspective and effectiveness. So automatic tests (with PHPUnit or others) make sense only if they actually bring value. Testing just for sake of having tests written - is indeed a waste of time. You should write tests only if you have specific scenarios written of what you're testing, what should be the outcomes/failures etc. In other words, it's not about writing tests - it's about designing their structure in a proper way, then I'm a fan of tests. And usually that happens for bigger projects with actually difficult cases and scenarios. Where it takes more time to test something manually instead of trusting the machine to run the test. Another point is so-called "smoke testing" - this is what I would recommend for ANY project. The goal here is to test the simplest things - whether the pages are loading ok with 200 status code and without any errors. So what we often do is build a set of such "smoke test" with a list of URLs, trying to go to them and check is the result is OK. Basically, same thing a developer would do, just without a human time spent.

6. Google Analytics, SEO and texts

This one is not Laravel-specific but often totally forgotten. Make sure you launch the project with Analytics (or if you have other analytics code like Piwik) code on live version of the website. But not testing. Otherwise your client will lose the essential statistics, cause usually the launch moment is the one to judge the first results - and you can improve on something only if you can measure it. Also, SEO stuff - titles, H1s, ALT tags, Sitemap etc. It also has to be there from the beginning. Finally, client needs to sign-off all the texts - there shouldn’t be any “Lorem ipsum” copy, nor placeholder images. You might hide some blocks if needed, but the release should be clean not only from development perspective, but also “presentable”.

7. Backups

Backing up your code and your database used to be a pretty manual and difficult process, depending on the operating system and other stuff. Not anymore - there is a brilliant Laravel package called laravel-backup which is so simple to use that there’s no reason not to. Even if your client doesn’t specifically pay for it, for the sake of a good night sleep, perform backups - especially of the database. Codebase is usually store within a repository (although it’s not advisable to use it as a primary backup), but database is crucial to back up often - it depends on your project and data amount, it might be daily, hourly etc. Also this package allows you to store backup on external drives like Dropbox or Amazon S3, and it’s also easy to configure. Actually, it’s a “set it and forget it” type of work. But please make sure that those backups are actually worth something, try to perform recovery at least once to be sure that it’s working. Also - tell your client about that backups, in theory they should provide their Dropbox/S3/etc account, cause technically it’s their data, not yours. Same with the ownership of the repository - by default, it should be either transferred to client's GitHub/BitBucket account, or belong to the client in the first place.

8. Documentation

Imagine that after a month you hire an additional developer to come on board and help you speed up the process. How do they get up to speed with the project? In terms of technical documentation, usually a good Readme.md file in the main directory is enough. There you should write out the installation process - what commands they need to run to set up the project in local environment. Speaking of environments, it’s a good practice to provide .env.example file in the repository - then developers know what variables they need to set in their final .env file. Also, if you’re creating some kind of an API (or the whole project is back-end API), documentation is crucial. What parameters are accepted and required/optional, what are the return formats, different error codes/messages. Again - a new colleague developer should not be guessing all of that. As well as any vendor that would potentially use that API in the future. You can use automatic documentation builder like Documentarian. Finally, if the client asks for a non-technical documentation - like video training or a description how to change the texts or other information on the website, it depends how you agreed with the client in terms of payment. It should be an additional paid work, but it’s up to you to sort it out with the client. Your goal here is to avoid midnight phone calls with “How do I do X?!”

I guess these are all major steps for the launch of Laravel project. If that all goes ok, you can turn on the marketing engine, shout to all your friends on social media and grab a beer. You deserve it, nice work! nice-work