5 ms·

How painless is deploying a Lumen/Laravel application? I used to use PHP back in 2006 and I remember deploying was as easy as pushing a .php file via FTP. Has

How painless is deploying a Lumen/Laravel application? I used to use PHP back in 2006 and I remember deploying was as easy as pushing a .php file via FTP. Has the experience remained the same? PHP was incredibly simple to deploy.

mmmm 12y ago
Yes, and even more so with https://envoyer.io/ https://envoyer.io/ - according to the website a Laravel product.
- deleted 12y ago
  [deleted]
- jonkiddy 12y ago
  How is this different from Laravel Forge? https://forge.laravel.com/ https://forge.laravel.com/
  - mmmm 12y ago
    Taylor Otwell have replied to a similar question here before: https://laracasts.com/discuss/channels/general-discussion/envoyerio-forge https://laracasts.com/discuss/channels/general-discussion/en... > They really aren't similar at all. Forge manages sub-domains, Nginx, Cron jobs, SSL certificates, queue daemons, recipes, etc. Envoyer does none of those things. Envoyer is solely focused on deploying PHP applications to multiple servers with zero downtime.
  - rawfan 12y ago
    Forge does server provisioning and Envoyer does deployment of PHP web applications. So not quite the same at all.
ing33k 12y ago
you can still do that.
cweagans 12y ago
Nobody uses FTP for deployment anymore, but the idea is still the same: just get the file to the server.
- darkstar999 12y ago
  You mean that you think it's not hip to use FTP? Because people definitely still do this.
  - cweagans 12y ago
    No, I mean that using FTP is the wrong/insecure/slow way to do it. SFTP at a minimum, please.
    - beausy 12y ago
      Do you always twist your words or just sometimes
- Dasuchin 12y ago
  I wish I could say that's true, but it's not.
alanstorm 12y ago
> Has the experience remained the same? Yes and no. The PHP language and run-time continue to value backwards compatibility and, ultimately, a PHP application is still just a collection of PHP files sitting on a web server somewhere. If you want to work like it's 2006 you can. However -- Modern PHP (Laravel included) bring a few winkles to the table and most deployments will have extra complications for folks expecting to just "FTP a file" (also, I hope you meant SFTP a file (-:) For example, Laravel (similar to rails) has migrations for creating and updating your database schema. You don't need to use migrations, but if you do your deployment becomes a bit more complicated. Also -- although PHP namespaces have come a long way, they're still not up-to-par with (or, in PHP group-speak "have different goals than") ruby or python's module system. The Composer packaging system has stepped in to fill this gap, but this means a modern PHP deployment needs to 1. Generate composer autoload cache files 2. Fetch, download and install any updated composer packages (i.e. third party libraries) Again, there's nothing stopping you from working locally and SFTPing or rsyncing all your local files (composer packages/autoload files included) to the server, but most teams develop a more formal deployment process than that. How you host your PHP application is going to effect how you deploy. There's still many, many PHP hosting companies offering `mod_php` based hosting, but there's also a large number of projects who use a Fast-CGI/FPM approach (either with Apache or nginx). The difference in process models brings a different in the unix permissions model, and that often means there's extra steps needed to ensure file based cache system can write to their storage engines. And speaking of caching, 20% of any "serious" PHP developer's time is spent sorting out the various framework level caching systems, as well as PHP based opt-code caching. I mention this here mainly to point out that some sort of cache refresh and/or warming is common in signifigant/long-standing PHP systems. Deployment's still easier in PHP than in other frameworks, but if you're expect a wild west "just edit files on the server and you're good to go", expect push-back from your modern, professional, PHP developers :)

mmmm 12y ago

Yes, and even more so with https://envoyer.io/ https://envoyer.io/ - according to the website a Laravel product.

deleted 12y ago
[deleted]
jonkiddy 12y ago
How is this different from Laravel Forge? https://forge.laravel.com/ https://forge.laravel.com/
- mmmm 12y ago
  Taylor Otwell have replied to a similar question here before: https://laracasts.com/discuss/channels/general-discussion/envoyerio-forge https://laracasts.com/discuss/channels/general-discussion/en... > They really aren't similar at all. Forge manages sub-domains, Nginx, Cron jobs, SSL certificates, queue daemons, recipes, etc. Envoyer does none of those things. Envoyer is solely focused on deploying PHP applications to multiple servers with zero downtime.
- rawfan 12y ago
  Forge does server provisioning and Envoyer does deployment of PHP web applications. So not quite the same at all.

ing33k 12y ago

you can still do that.

cweagans 12y ago

Nobody uses FTP for deployment anymore, but the idea is still the same: just get the file to the server.

darkstar999 12y ago
You mean that you think it's not hip to use FTP? Because people definitely still do this.
- cweagans 12y ago
  No, I mean that using FTP is the wrong/insecure/slow way to do it. SFTP at a minimum, please.
  - beausy 12y ago
    Do you always twist your words or just sometimes
Dasuchin 12y ago
I wish I could say that's true, but it's not.

alanstorm 12y ago

> Has the experience remained the same? Yes and no. The PHP language and run-time continue to value backwards compatibility and, ultimately, a PHP application is still just a collection of PHP files sitting on a web server somewhere. If you want to work like it's 2006 you can. However -- Modern PHP (Laravel included) bring a few winkles to the table and most deployments will have extra complications for folks expecting to just "FTP a file" (also, I hope you meant SFTP a file (-:) For example, Laravel (similar to rails) has migrations for creating and updating your database schema. You don't need to use migrations, but if you do your deployment becomes a bit more complicated. Also -- although PHP namespaces have come a long way, they're still not up-to-par with (or, in PHP group-speak "have different goals than") ruby or python's module system. The Composer packaging system has stepped in to fill this gap, but this means a modern PHP deployment needs to 1. Generate composer autoload cache files 2. Fetch, download and install any updated composer packages (i.e. third party libraries) Again, there's nothing stopping you from working locally and SFTPing or rsyncing all your local files (composer packages/autoload files included) to the server, but most teams develop a more formal deployment process than that. How you host your PHP application is going to effect how you deploy. There's still many, many PHP hosting companies offering `mod_php` based hosting, but there's also a large number of projects who use a Fast-CGI/FPM approach (either with Apache or nginx). The difference in process models brings a different in the unix permissions model, and that often means there's extra steps needed to ensure file based cache system can write to their storage engines. And speaking of caching, 20% of any "serious" PHP developer's time is spent sorting out the various framework level caching systems, as well as PHP based opt-code caching. I mention this here mainly to point out that some sort of cache refresh and/or warming is common in signifigant/long-standing PHP systems. Deployment's still easier in PHP than in other frameworks, but if you're expect a wild west "just edit files on the server and you're good to go", expect push-back from your modern, professional, PHP developers :)