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