Migrated from GitLab wiki
@@ -0,0 +1,32 @@
|
|||||||
|
# Composer
|
||||||
|
To update composer on production, always follow the following commands
|
||||||
|
|
||||||
|
Download the composer version you required, in following command it is going to download 2.4.1 version.
|
||||||
|
|
||||||
|
`wget https://getcomposer.org/download/2.4.1/composer.phar`
|
||||||
|
|
||||||
|
Make the download file executable using following command.
|
||||||
|
|
||||||
|
`chmod +x composer.phar`
|
||||||
|
|
||||||
|
Move the file to the right place
|
||||||
|
|
||||||
|
`mv composer.phar /usr/local/bin/composer`
|
||||||
|
|
||||||
|
# Step to push code and install packages
|
||||||
|
|
||||||
|
First, a more general note: you shouldn't be requiring individual packages on the server. That's a recipe for breaking things. You should only ever do "**composer require**" or "**composer update**" in a development environment. Composer will then figure out the right set of package versions, and record them in composer.lock. On the production server, you should only ever be running "**composer install**", which simply installs the packages/versions specified in composer.lock.
|
||||||
|
|
||||||
|
The typical "release code to production" process should really only ever be:
|
||||||
|
|
||||||
|
1. git pull
|
||||||
|
2. composer install
|
||||||
|
3. run any data base migrations.
|
||||||
|
|
||||||
|
**Following are best steps to push code on live**
|
||||||
|
|
||||||
|
1. Upgrade composer to the current version on your dev machine and on the server.
|
||||||
|
2. Get all the dependencies sorted out and working on your local machine.
|
||||||
|
3. Commit composer.json and composer.lock
|
||||||
|
4. Check out the code on the server.
|
||||||
|
5. Do "composer install" on the server.
|
||||||
Reference in New Issue
Block a user