Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 months ago.
Improve this question
I'm starting to use Laravel 4 seriously in my projects. I understand that this framework offers many advantages when developing RESTful applications. But I understand that there is no consensus about how do deployment / publishing and app using Laravel. I am still using FTP to transfer files to my Production host. But my question is, Is there any standard way to do the same but from Laravel? I am faithful believing that with a little ingenuity one can create something like php artisan publish [Production server name and SSH credentials] as parameters.
I have read something interesting from Anahkiasen/rocketeer and Christopher Pitt, both great sources but there is a consensus or standard way to publish applications using laravel?
This is not really a Laravel problem/question, you have to ask on a dev-ops forum what they would do to deploy a PHP application like yours.
Your Laravel application is basically PHP application, some packages are provided by Composer, so it's more a Composer application than a Laravel one, but you might have some Laravel needs, like executing php artisan migrate, or any other artisan command to post-deploy your application, or not, so, it's more a requirement of your application than Laravel, right?
I developed a package to do my deployments, Deeployer. The intent of this package is, everytime I push my application to the production (or staging) branch, Github will fire a hook that tells my server to do whatever it needs to deploy my application to my own VPS. In a basic deployment it will:
1) git pull the repository
2) Execute composer update to update my vendor folder
3) Execute bower update to download whatever js or css I've installed
4) Execute php artisan migrate to upgrade my database schema
5) Execute chmod and chown to fix whatever permission mess those commands might have made to my directories while downloading files
See? Those are things that are very particular to my deployment structure, that's why I don't really think you are going to find consensus about a deployment app. When Anahkiasen first build Rocketeer, someone shout: "Why are you doing this if we already have Capistrano?".
Yesterday I bumped into this one: http://www.deployhq.com/packages, used by Ben Corlet from Cartalyst and other nice guys.
There's also Rocketeer: http://rocketeer.autopergamene.eu/.
Don't forget that Laravel itself has it's own SSH Remote component (I used it on Deeployer and Rocketeer uses it too), that might help you do whatever you need to deploy your app.
So, you better think what are your deployment needs and find your way, using a package, app or just Laravel.
There are a lot of deployment tool, like Capistrano. I recommend you to take a look at Deployer: it's has simple api, bundled with recipes for popular frameworks and apps, and can do 100% parallel task execution. Also it requires only for PHP.
deployer.org
github.com/deployphp/deployer
How to deploy Laravel
Here is an example of simple task:
task('my_task', function () {
// Your tasks code...
});
Also it has a good quality code:
You may want to check out Rocketeer:
http://rocketeer.autopergamene.eu/
If you are asking for a standard, I don't think there is one. But an alternative from FTP, well, have you considered using git as a way to deploy your site to production?
Here is how you do it:
http://danbarber.me/using-git-for-deployment/ (Link is broken)
https://www.digitalocean.com/community/tutorials/how-to-set-up-automatic-deployment-with-git-with-a-vps
Basically the summary is that you have a bare git repository, your own local repository and your production repository.. now by configuring the correct hooks, when you push to the bare git repository, a hook in it will tell the production repository to pull the most recent changes you commited down to the production. And in addition, setting up the correct credentials in your config depending on the environment.. you can create a new folder ex. app/config/production and app/config/stage so that you can easily run the application even while switching on both servers..
I'm not so sure about a standard way either. You do have Forge and Envoyer that work with Laravel, so that is something to look into.
Here is a way to deploy Laravel using Rocketeer and Git. It is very easy to setup and allows you to use multiple servers (think staging, production, etc.)
http://dericcain.com/blog/deploying-laravel-5-with-rocketeer
Related
I regularly use Laravel to build applications. Recently, I have started using Lumen to build microservices.
One thing I notice with Lumen, is that I often only need to create 2-3 files, and edit a further 2-3 (providers, configs and routes). In total, I am editing or creating 5-6 files.
It feels to me that my git repositories for these microservices would be way cleaner if they only included the changed files, and then I merged with the Lumen framework during the CI build/deploy.
Does anyone have any experience with doing this? What are the pros/cons?
I build many API services with Lumen, and I always have the entire project on git repo, and when I make changes locally, I pushed it to GitHub and from the server i just take a pull. I wouldn't say there are necessarily pros or cons, just different ways of doing things
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Head coder:
You should now be ready to install Laravel Homestead.
Me:
oh awesome. I've always wanted to learn Laravel framework.
Head coder:
We are not going to use the laravel framework, but we do take advantage of their development stack.
What does this mean?
A framework is a set of functions that help you code because you can call them to accomplish your task. A development stack is a series of technologies(which might use frameworks) usually in a level heirarchy that call each other to accomplish all the tasks an application might need.
E.G.
LAMP -> Linux Apache MySQL PHP stack
Note all 4 of these are technologies. Starting from the OS linux, the web server Apache, the database server MySQL and the server side programming language PHP
CodeIgniter or Laravel i.e. PHP frameworks
Frameworks are extensions of languages that are really good at doing certain things. For example both CodeIgniter and Laravel are good for programming web servers and make it easier to do so in PHP.
Another example of a framework could be the bootstrap framework which allows you to do HTML easier or jQuery.
Now, to Laravel and Homestead
The Laravel Homestead is a relatively new concept. Laravel is PHP based and previously you had to set up your own LAMP or WAMP(Windows) stack to work with it. Now, what they have done is set up a custom stack, tailored for Laravel and PHP development.
They've used Vagrant, which is used to help you test your code on a virtual Machine, essentially installing an entire stack ready for development on a platter. With Laravel's VM (Homestead) you get a bunch of stuff ready including MySQL and PostGRE (databases), Redis and Memcached (Caching), Nginx (a web server like Apache) etc.
So now you have something nice to program Laravel on right out of the box. But, you need not necessarily use Laravel. Its also ideal for building any PHP app or using other PHP frameworks like Codeigniter.
What I understand by dev stack is the set of technologies you use for your project, while the framework provides solutions for a specific set of problems, say building CRUD web apps, at the cost of following its guidelines, most of the time becoming your project.
Following that statement, the stack may be: "Laravel, node, gulp, mysql, composer, etc"
While the framework is without a doubt Laravel itself, which attempts to solve problems pertaining to CRUD MVC web apps.
I think your head programmer meant you will be using the built in PHP, Apache, MySql and perhaps composer. Maybe the point is that you can all work in an environment that holds the same known configurations and tools (since its conveniently configured for PHP development).
It seems the standard way to deploy with Rocketeer is to do a pull deploy, that is, it will do a git clone from the server you are deploying to. What I want to do is push a set of files after having done a build on a CI server to the server being deployed to.
The reason I want to do this is that usually my projects have lots of extra stuff not required for production. I usually like to construct a build folder and run a build script that packages a final product. I want to use Rocketeer to push the results to staging/production servers. It was suggested in this article it can be done: Deploying PHP Applications with Rocketeer and Docker
However, after reading the rocketeer documentation there is nothing that speaks to that strategy and its seems a bit against the grain to try. I'm open to ideas given my problem.
As the author of the article, I owe you a clarification. I mentioned those two types of deployment paradigms in a general sense just to introduce the different concepts. As I am aware of, Rocketeer supports only "pull" deployments. Sorry for the confusion!
For deploying the generated files to your server from a CI, I think the most straightforward way is to usea tool like scp, rsync or just download it from S3 if you're storing your built package in a bucket.
Why does the default laravel4 have the composer.lock file included in the .gitignore repo?
It seems to contradict composers recommendations to commit this file into VCS. I was wondering if there was something I didn't know that justified this?
According to the author of Laravel here https://github.com/laravel/framework/issues/1412:
It is recommended for your own apps, not for frameworks.
It's not clear from the question if you meant the framework or the app. Instead of asking for a clarification, I decided to write this instead for future confused users.
The problem is, it's ignored not only in the framework but in the app too. The app is what you get when you install Laravel as a project (i.e. not for the purposes of developing it and sending pull requests but for using it in a project of yours).
In contrast, the Symfony project makes a distinction here and doesn't include the lock file in the .gitignore of the the Symfony Standard Edition distribution (the app) unlike the Symfony framework.
There are already at least two issues and one pull request regarding composer.lock: issue 1696, issue 2293 and PR 2591.
this is a question on PHP mainly. I was wondering: How do you make sure that all necessary libaries are packaged with your application when you do a deployment to (production) servers?
A more concrete example: I have an app running on Zend Framework and each time I roll the application to a server the deployment process creates a fresh "installation" on that system. Therefore, I need to bundle Zend Framework together with my application and then copy the files to the right places together (it is done automatically). Currently, I am using a svn:externals definition to get the files out of Zend's SVN system during deployment, however, I don't want to rely on that SVN and I also don't want to put traffic on external SVNs with each deployment.
In the Java world, I am used to Maven which handles such stuff using central artifact repositries. I know that there is a Maven4PHP version, however, I am more looking for a PHP-based solution. Additionally, I don't believe that PEAR is a good way to go as it doesn't really fulfill my requirement of bundling the applicaiton (incl. libs) into a single deployable.
Is there some tool available already that I am not aware? Or do you have any great technique that I should know?
Thanks much for your help!
Michael
There's a build system called Phing which is written in PHP and based on Apache Ant.
I personally can very well live with externals.
I think the vendor branching would solve the problem from your example quite straightforward, but if you also don't like large repositories I'd recommended to keep watching on the modern toys like composer and what it solve(and maybe phark, I never heard before :) )
It isn't production ready yet but you might want to keep an eye on the Phark project. It is a port of Bundler to PHP.
While looking through the Simplify your external dependency management slides I came across a tool called pantr which can be used as a PEAR installer. pantr as PEAR installer which allows you to specify your dependencies in a project specific file.
The article Version Control != Dependency Management has some information about using the new PEAR installer called Pyrus