Wondering if anyone has any best practices for running a laravel 5 code set across multiple dev environments...
I was developing something on my Imac, pushed up to github, pulled down from my macbook and now running into all sorts of issues just to get it up and running.
remade my .env file
ran composer update to pull down dependencies
Now I am getting some: PDOException in Connector.php line 47 - error.
Dont know what is going on but would like to know if there is a best practice that maybe i am missing something?
Thanks in advance
Citti
IMHO there is no problem with your workflow. Clone repository, recreate .env file and, finally, run a composer install or a composer update to re-install all vendor files locally.
But, when I encounter a problem after configuring a new environment, the most common causes are:
wrong .env parameters
forget to checkout correct git branch (normally git will clone in master branch, so do a git checkout my-awesome-dev-branch before testing)
check if your config/database.php uses your .env parameters correctly
wrong apache configuration (like don't enabling mod_rewrite and FollowSymLinks)
wrong nginx configuration (like don't enabling pretty urls)
forget to install php5-mcrypt and enable it with php5enmod mcrypt
forget to restart webserver when changing things
Related
I have a problem with symfony configuration. I installed symfony and configure everything as in tutorials, but i can't start server in my project file, because i've got that kind of error :
'symfony' is not recognized as an internal or external command,
operable program or batch file.
I tried to reinstall whole packet and I'm still geting same result. What I need to reconfigure or change?
You must install the Symfony CLI (the symfony binary) separately from the libraries/bundles/packages.
See the Symfony CLI installation instructions for more information.
This is typically done first, so your answer makes it unclear how you may have "installed symfony". If you indeed installed the CLI, you may have to take additional steps to make it globally available depending on your platform.
I've got a Laravel project and simple pipeline in Jenkins which build Docker image from Dockerfile, pull code in it and execute composer install. Everything working fine so far, but installing composer packages takes a lot of time (like 6-7 minutes). I've tried to persist vendor directory somewhere, create symlink to it or something but nothing worked so far. I wonder if there is some better more official way to handle that? Anyone has some idea or experience in it? Or maybe some different CI tool?
Ok, I ended up with two solutions:
I mounted composer cache directory to some directory in host to speed up composer packages installing:
dockerfile {
filename 'Dockerfile'
args '-v $HOME/composer_cache:/.composer/cache'
}
There is (not so obvious, because Jenkins panel is little messy) option to disable workspace clean up before/after code checkout. One can delete those steps in pipeline configuration under "Branch Sources" section (with red X above those "Behaviours").
I've been running a project written in Laravel which has been fun to use.
The setup I use is the vagrant box Homestead configuration so I do the majority of my work on my local machine and push up to the development server once its ready to go. During the installation I had to push up the logs & vendor folder for it to work properly but now I'm at a stage where every commit I do via the command line includes storage/logs/laravel.log which when I then pull down it asks me to stash/commit on the server because they're different.
I've added it to the .gitignore file in the root directory of the project and it looks like this:
/node_modules
/public/storage
/.idea
Homestead.json
Homestead.yaml
/storage/logs/
/vendor/
Vendor doesn't cause me any problems unless I make changes to it so its not much of a bother, its just the logs which will not stop going up. If I use a GUI tool, I can manually tell it not to go up but I want to get it to the point that I can use the terminal to push it up and not worry about logs need stashing on the server.
I believe this is the same for the .env so I imagine a solution will work for both. I have also noticed that PHPStorm have said they're ignored but tracked with git if that helps.
If you take a look at the Laravel repo on GitHub, you'll find the following .gitignore file in the storage directory:
https://github.com/laravel/laravel/blob/master/storage/logs/.gitignore
This comes with the default installation to mark the logs directory as ignored. If you've deleted this by mistake, you should be able to reinstate it and resolve the issue you're having.
Just as importantly though, your workflow isn't following best practice. With respect to "Vendor doesn't cause me and problems unless i make changes to it" - you should never make changes to your vendor directory. This folder is home to third-party packages and plugins, modifying them directly causes multiple issues, chief amongst them:
You can no longer update a modified package without breaking your application.
Other developers won't be able to replicate your installation easily.
In fact, the vendor directory shouldn't be versioned at all. The best way to handle the files within it is using a package manager, like Composer, to do it all for you. This means you can easily switch between different versions of your packages and, by versioning only the composer files, other developers can run composer install or composer update to synchronise their development environment to yours quickly and accurately.
I am new to composer and would like to know how do you guys deploy a project to the production server using composer?
In deploying, would composer also push the dependency packages needed to the server?
Would/ Can composer build the application with minification process?
I think the current best practice is to not run Composer on the target production server. The regular process of deploying a web application usually requires several independent steps, and Composer is only suitable for some of them, regardless of what people make it do additionally.
You mention minification, and I would add the process of pulling in JavaScript dependencies in general. This is no domain for Composer. It has been done in the past to offer Composer packages that contain Jquery, but this requires additional work to put Jquery in the right directory afterwards, adding the need to run post install scripts or add installers that need configuration. I guess the right way to do it would be to use Bower for this.
So the deployment would be at least a three step process.
Use composer to install PHP dependencies.
use bower to install JavaScript dependencies.
Use rsync, SFTP, SCP or FTP(S) to move all the files to the server.
Any optimization steps would be done prior to moving the files onto the server inside the deployment script.
And if anything fails during the collection of dependencies, be it an unsuspected downtime of Github, or your deployment server running out of disk space, you don't end up with a halfway deployed new website version. You can stop the deployment script before syncing if anything is missing or gone wrong.
yes, composer install get all dependencies in your test server, check it, if everything work ok, then sync all the files to your production server, which can save you from the unexpected problem running composer install on your production server.
other way is to sign all the files from your test server after composer install, then use composer install to get all dependencies in your production server, sign the files, now you must check two signs separately generated in test and production server, if it match, congratulations, the deploy is ok.
I need to install and configure an existing Laravel 4 project.
I tried to do, but when I ran composer update or composer install a lot of issues appear.
I have the database too (with data) so I ran the migration but doesn't work because the console show me an issue about the "table doesn't exist".
Can anyone tell me the complete process to configure the App?.
I mean, what its first, second and so and so because maybe in some step I made a mistake
To install and configure an existing project, you'd typically
Check out its source code
Run composer install
Run php artisan migrate
Check the README for specific instructions on installing 3rd party assets, or any additional steps you'd need to take
If the above creates errors, its either because of something in your environment (installing over an old project?) or some problem with the way the Laravel developer created their project.
To install and configure an existing project, you'd typically check those things first :
You should goto app/config/database.php check file and verify username and password.
After check in Project Folder vendor folder and composer.json file exist then remove it (that remove old configuration now we going to fresh configuration).
Then after back to command prompt and fire command composer update and that download some dependent file download.
Now Run php artisan serve
that tricks work for me last time when I migrate another host.
Carlos, when using an existing DB you'll need to check the migrations table to see which migrations have run successfully. Typically when taking over a laravel project setting up a new db and running the migrations against it is a good idea because you never know what hacks were made to the database outside the migration system. One small change can throw the entire system into a useless state because it's looking for a table or column that doesn't exist or has been modified. If you run the migrations against a bare db you can also figure out which tables were manually created (which could very well be your issue) outside the system and add them in as necessary. Cobbling things together after a previous developer is tedious, hopefully there is decent documentation.
Note that if you are using Git with .gitignore, don't forget to copy .env variables in new location too.