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.
Related
Bit of a strange set up but have come across a project where Composer has been used in a local environment to get a project started. The original developer did not have ssh access to the production server therefore he used Composer locally and uploaded the 'vendor' directory from his desktop to the server using FTP.
I now need to add the PHPMailer package so have done the following locally on my Mac:
cd Desktop/
composer require phpmailer/phpmailer
This has created the following structure on my desktop:
Desktop/composer.json
Desktop/composer.lock
Desktop/vendor/autoload.php
Desktop/vendor/composer/*
Desktop/vendor/phpmailer/*
Which of these do I need to upload through FTP? I realise vendor/phpmailer/* is the package I want, so will need uploading.
What about the others? I already have an autoloader configured so guessing vendor/autoload.php is not required here?
composer.json I could add the package to what's already there, e.g.
"require": {
*other packages here*
"phpmailer/phpmailer": "^5.2"
}
But I wasn't sure if that's necessary because I'm not going to be using ssh/Composer on the server to run any updates?
The usual workflow would be:
Checkout the current version from the version control.
Add dependencies via command line composer require new/package.
This will download the new package and update the autoloading.
Test the result locally or on a test website environment.
If happy with the result, upload the whole folder to the production server.
There may be several exceptions from this general workflow:
ad 1: If there is no version control, you'd probably better of starting a local git repo right now, and download the current production state into it as the first commit. Not having version control will make things harder, especially going back to known working versions. And because the files on the production server are probably unmanaged, you'd also check in the vendor folder into your newly created version control just to avoid canceling any changes that had been made to these files.
ad 2: Manually editing the composer.json file sometimes is a faster way to get what you want if you know what you are doing, but you'd have to correctly edit the JSON. For me it usually is too much hassle if I already have a command line ready. The command will also select a matching version that fits into the already installed dependencies. Manual editing may lead to version conflicts that you'd have to untangle. Remember to only install dependencies that work with the PHP version in production. You probably should run composer config platform.php X.Y.Z in order to add the production version of PHP into the composer.json file, which prevents Composer from installing dependency versions based on your development PHP. Adding the -g switch will add this setting to your global (user) setting instead, which will affect all composer operations you start, also for other projects.
ad 3: Manual editing will require you to run composer update on the command line, so there's probably no reason to not do composer require instead.
ad 4: How this could be done is entirely dependent on what environment you have to work with.
ad 5: At this stage you have assembled all files necessary to create a working website. Uploading them to production will always result in a working website unless the upload fails somehow. You could also use some "upload first to temporary folder, then move on the server" approach if you fear FTP would be unreliable. Some people take a different approach: They have a git repository on the production server and they simply push the version that should go live onto that remote repo. Some post-push scripts will run composer install then. This automated approach will also work (but not using FTP), but has the higher risk of something failing during deployment, and probably has no easy way back to the previous situation.
So in the end I'd say that uploading the whole folder structure via FTP (well, that protocol is insecure itself, better replace it with FTPS (FTP with SSL), SFTP or SCP) is better compared to running Composer on the production server.
Your specific question regarding which folders to upload: All of them. Especially upload the whole vendor folder. It contains the current autoloader and all dependency packages the software needs. If you worked correctly, you downloaded the existing composer.json and composer.lock file together with everything else and added the new dependency to it. This has changed both these files, added the new package to the vendor folder and the classes to the autoloader.
Don't fiddle with uploading only parts of the vendor folder, or manually editing a component of the autoloading. You will only create surprises for the developer coming after you if you do some aspect incorrectly, and it also takes more time. Composer is a very good tool to manage dependencies - use it!
You could copy the composer.json from the server to your local server, add the requirements and run composer update.
After that you can copy all files (composer.json, composer.lock and vendor folder to your server)...
Or you can copy local vendor/phpmailer into servers vendor folder, search for the entry of phpmailer in vendor/composer/autoload_psr4.php and add it to your servers vendor/composer/autoload_psr4.php.
Using this method also add phpmailers dependencies the same way.
composer depends phpmailer/phpmailer
I am working on Laravel webapp right now and kept vendor directory out of git (version control) so far and every time for fresh install I used to have composer install command added to automated script and everything was fine.
Now just 2 days back I added added laravelcollective (https://laravelcollective.com/) to my project for helping me with forms and html in blade templates. Now somehow one of the dependency requires me to generate GIT private token to install it and that is pain as it would hurt my automation. I can still hack it by calling the url and scrapping html to read token and stuff like that but I don't like it. And then I thought is it good idea to keep vendor directory out of SVN/GIT? Isn't source code for a product contain all dependencies within itself? I am not talking about stuffing JRE in the installer but when it comes to libraries of a product in native language.
I would like to hear more about it on industry standards or best practices on this.
P.S:
This question is much generic and not just limited to laravel or even php for the matter.
Now somehow one of the dependency requires me to generate GIT private token to install it and that is pain as it would hurt my automation.
You're just running into Github's rate limits for package downloads for anonymous users. No reason you can't automate this. Generate a Github token (you only need to do it once - they get very high rate limits for authenticated requests), then have your automation use that token like so:
composer config -g github-oauth.github.com <oauthtoken>
https://getcomposer.org/doc/articles/troubleshooting.md#api-rate-limit-and-oauth-tokens
Well, for production environment you usually run a build process first in your CI software. If 'composer install' fails during the build – application won't be deployed to production environment, so you are safe.
Yes, most (99%+) people keep 'vendor' folder out of the repo because it's a third-party code, it's not yours. You may not even have rights to host it in your repo.
If you want to be sure that your production version will have all the dependencies in order, the way you had them during CI, and will always release – you could build Docker images and ship them to production. Then, everything comes prepackaged.
I'm getting my feet wet with dependencies. I recently wrote a small application in PHP and used Composer to get some dependencies (mainly Slim, twig, hassankhan/config and illuminate/database). So I have the project in my local computer and basically have:
public folder
app folder
vendor folder
composer.phar
composer.json
composer.lock
It's now time to upload to my web server (I work with a GoDaddy hosting account with Linux CPanel). The question is, what should I do? Do I upload the whole thing, with the vendor folder and composer files? Or am I supposed to use Composer in a different way when uploading to my hosting? Never done this before so any guidance will be deeply appreciated.
Thanks!
You are not required to use Composer in any particular way. I recommend using it in the way that works best for you. That will depend on the type of development and release process you use. It sounds like you are using a fairly short and simple process where you develop for a while, decide the code is ready, and upload it to your production server. With this process, you could simply upload everything, vendor directory and all - just as you state. This could lead to unused files/directories not being removed but that is a general problem with this type process anyway (you can work around it by first deleting everything, breaking your site temporarily).
Composer helps you (among other things) "lock" all of the required libraries at some specific version. This is very useful when used with version control, tagged releases, and multiple environments (such as your development environment, a QA/Testing environment, and a Production environment). This helps ensure that each environment uses the exact same versions of the required vendor libraries.
If you were to try to use composer directly on your hosted server (i.e composer update), you would have to make sure that the php cli is available and that all other prerequisites for composer (including composer itself) were available. This is usually hard to count on for generic hosting providers so, you really are better off not trying to execute composer there.
As your project matures and uptime is important, you will want your development and deployment processes to mature as well. That's when you will realize many of the benefits of Composer.
A composer install normally takes a few minutes. And on a production environment it's feels too slow.
Is it possible to make a composer install to a temp directory and then switch it? If that is possible the downtime should be about zero.
Or are there any other way to do a composer install faster?
I created a composer plugin to download packages in parallel.
https://packagist.org/packages/hirak/prestissimo
$ composer global require hirak/prestissimo
Please try it. In my environment, composer install become 10 times faster.
You can sometimes speed up composer install significantly by using the --prefer-dist flag, which just happens to be recommended for production use:
--prefer-dist: Reverse of --prefer-source, composer will install from dist if possible. This can speed up installs substantially on build servers and other use cases where you typically do not run updates of the vendors.
composer install docs here: http://getcomposer.org/doc/03-cli.md#install
Edited To Clarify Sometimes
I say it sometimes speeds up composer install because there are plenty of factors that go into it feeling slow, not the least of which are network performance and the current Github status. A slow install can be really frustrating, but it's not always b/c of Composer.
You are asking two different and unrelated things.
Yes, it is a solution to build the next version of your site in a separate directory then put it in place after you moved the old version out of the way. It is, actually, the best solution.
This is how the deployment scripts I build work:
prepare the next version of the site in a separate directory (let's say /var/www/new); the following list of items and their order is not static, some projects need a different flow:
get the last version of the code from the repo;
remove the files that are not needed on the live site (.gitignore, IDE project files, placeholders etc);
run composer install;
copy/generate the configuration files containing the settings for the live servers (the ones stored in the repository contain dummy values);
change the user and permissions of all files; make some directories writable by the web server;
create symlinks, directories etc; for example, the directory that contains the user uploaded files is somewhere outside the server directory and a symlink to it is created during deploy to make its content available through the web server;
move the live code out of the way; I use mv to move the entire directory (/var/www/html to /var/www/old, for example);
move the prepared new version to the proper place (mv /var/www/new /var/www/html);
move the previous version into the archive (after I remove the content of vendor and other files that do not change or are external).
The advantages:
the downtime is zero (microseconds, probably, between steps #2 and #3);
a failed build doesn't affect the live site (if handled properly);
reverting to the previous version (if needed) can be done easily.
Regarding the other question, the only way I know to speed composer up is to avoid running it using a PHP that loads the xdebug extension. The xdebug extension shouldn't be loaded on the production server anyway.
I'd like to know if I can install or use the Laravel PHP framework on any web server without using Composer (PHP package/dependency manager) every time?
I would like to be able to drop my app on to any web server (like a shared server without access to the command line).
If I run composer install the first time (locally), then all the dependencies should be present, correct?
Then, I should be able to drop it onto any server with all of the files (including the vendor directory)?
If you really wanted to, you could do all the work that Composer does manually, but you definitely should not. Installing Composer is easy, it's just a matter of getting the composer.phar file and running commands on it.
You do not need to run Composer on your server as well as locally, once you run composer install or composer update your project will have all its dependencies available and you can just upload it straight to your server.
You cannot install laravel local without composer in your project.
On this site you can download everything what you can download also with the composer build tool. But you do not need a composer installation. Of course laravel is also present there: https://php-download.com/package/laravel/laravel
If you have shared server and you are not able to install composer and run cmd to install a new package or update an existing package.
You can one thing by installing composer on your local machine and install(ex composer require package/name) or update(ex composer update package/name) all the packages, then upload your vendor directory on the server with your code. it will work for you same as in your local environment.
NOTE: I strongly recommend that you should use the Laravel with the composer, it is an important part of laravel and you can try to convince your client to provide a server that supports laravel. Please check the link below and you can find the server requirements. https://laravel.com/docs/5.5#installation
If you don't want to use composer on server then you will have to run composer install/update and download all the libraries locally and then manually upload all those files on the server i.e. Vendor Directory.
In-Case of shared hosting where you can't connect to server with shh there you might have to do that but it will take lot of time to upload all the files on server so I would recommend that you should composer and then download the libraries through composer install/update.
Yes, you can install all project dependencies via composer in your localhost first, and then transfer all the files via FTP to your actual website.
Just download the zip file from github and upload to your htdoc and voilà it will work for you