It's time to deploy your php code in a more elegant way.

It's time to deploy your php code in a more elegant way.

Let's recall how you released your code last time:

1. Back up the online code using ftp

2. Upload the modified File

3. test whether the function is normal.

4. The website is 500. Replace it with backup.

5. Incorrect replacement/missing replacement

6. A server is successfully published.

7. log on to each server and perform the publish operation once.

8. work overtime

9. The boss is furious

...

Especially in the Internet industry, fast iteration and small steps are required. Versions such as bug fixes or minor feature modifications are released almost every day, and major feature version iterations are performed almost once a week. I believe many colleagues will release their own code as I mentioned above. Alternatively, you can directly execute a command similar to git pull on the server to drag down the code in the repository. But what if your code runs in the cluster? Can I log on to each machine and execute git pull once? What should I do if I find a problem with the code?

If you are still deploying your own code in the way I mentioned above, I hope you can read this article and get rid of the pain points of code deployment.

 

Today I want to introduce the code release tool written in php: deployer.

Deployer has the following attractive features:

-Rapid adoption of technologies such as concurrent release, ssh channel multiplexing, and cache availability to accelerate code deployment

-All defined operations, such as downloading dependencies and setting file access permissions, are performed by the atom deployed in the new version. This does not directly affect online operations, the last step is to set the soft link to replace the online code.

-Fast rollback because atomic deployment is used, rollback only re-sets the soft link

-In the cluster environment with concurrent deployment, execute the same deployment process on all machines concurrently.

-In a consistent cluster environment, only when all the machines are successfully executed is considered successful, and if one fails, all fail.

-Multiple built-in Framework release templates, such as Laravel, Yii, Symfony, CodeIgniter, and Zend Framework

-Easy Scalability: You can easily compile the publishing process using the Common template for your project.

Installation:

composer global require deployer/deployer

After the installation is complete, switch to your project directory, execute dep init, and select the generated deployment template based on the framework used by your project:

➜  tb dep initPlease select your project type (defaults to common):  [0] Common  [1] Laravel  [2] Symfony  [3] Yii  [4] Zend Framework  [5] CakePHP  [6] CodeIgniter  [7] Drupal > 0

If your framework does not use any of the frameworks listed above, select 0 and press enter to generate a general release template.

After this step is completed, a deploy is generated in the root directory of your project. PHP file. All you need to do is edit this script, fill in some of your own server and project configurations, and then customize some tasks.

Next I will use a specific configuration file to introduce the use of deployer. The configuration file is as follows:

 

<? Phpnamespace Deployer; use Symfony \ Component \ Console \ Input \ InputOption; require 'recipe/common. php '; option ('tag', null, InputOption: VALUE_OPTIONAL, 'published tag'); // set ('ssh _ type ', 'native '); // you can log on to a remote host in three ways: phpseclib (default), native, ext-ssh2set ('ssh _ multiplexing', true ); // whether to enable ssh channel multiplexing (enabling can reduce the server load and local load, and increase the speed) set ('Keep _ Releases', 10); // returns the error of 10 previous versions, if it is set to-1, the previous version set ('reposition', 'git @ xxxxxxx.com: Loc/loc-api.git '); // address of the code repository, only gitset ('branch', 'master') is supported '); // The default branch set ('shared _ files', []) used when code is published; // The files listed in the shared file list will be moved to the shared directory of the root directory of the project, and the soft chain set ('shared _ dirs', []) will be implemented; // The shared directory is the same as set ('writable _ mode', 'chmod'). // you can control the write permission in four ways: chown, chgrp, chmod, acl (default) set ('writable _ chmod_mode ', '123'); // when you use chmod to control write permissions, set ('writable _ dirs', []); // The writable directory specifies that these directories are set ('clear _ path ', []); // Set the directory to be deleted when the code is released ('HTTP _ user', 'nginx'); // web server user, generally, you do not need to set this parameter. deployer automatically determines set ('release _ name', function () {// sets the release name. tag is used as the name first, if this parameter is not specified, the date + time is used to indicate the release time. if (input ()-> hasOption ('tag') {return input ()-> getOption ('tag ');} return date ('ymd-H: I ') ;}); // you can set multiple servers, when publishing, parameters are synchronously sent to multiple servers according to the settings. // you can set parameters for each server separately. The set parameters will overwrite the global parameter server ('prod _ 1', 'xxx. xxx. xxx. xxx ')-> user ('root')-> password ('xxxxx')-> Set ('ploy _ path', '/var/www/tb') // code deployment directory. Note: Your webserver, such as nginx, the Set root directory should be/var/www/tb/current, // because current is a soft link pointing to the version actually used online-> stage ('prod '); // identifies the server type, used for server group server ('prod _ 2', 'xxx. xxx. xxx. xxx ')-> user ('root')-> password ('xxxxx')-> set ('ploy _ path','/var/www/tb ') -> set ('branch', 'master') // specify the branch sent to this server. The branch parameter set globally is overwritten.-> set ('extra _ stuff ', '... ') // specify other parameters at Will-> stage ('prod'); server ('Beta ', 'xxx. xxx. xxx. xxx ')-> user ('root')-> password ('xxxxx')-> set ('ploy _ path','/var/www/test ') -> set ('branch', 'beta ') // use the beta branch in the test environment-> stage ('beta '); // The task ('success ', function () {Deployer: setDefault ('terminate _ message',' <info> is successfully published! </Info> ') ;})-> once ()-> setPrivate (); // Add a once call. Then, the task is executed locally instead of on the remote server, run desc only once ('Restart php-fpm'); // you can add a description to the task, the description task ('php-fpm: restart', function () {run ('systemctl restart php-fpm.service ') is displayed when you execute the dep list '); // The run function defines the operations executed on the server. It is usually a shell command that can return values and print the returned command.}) // if you are smart, you can use the run function to create tasks for batch server management, such as Reload all nginx configuration files in batches and execute scripts on the server in batches ', 'php-fpm: restart'); // hook function, indicating to execute the php-fpm restart task desc ('release Project') after the soft link task is set '); task ('ploy', [// you can set a composite task. The second parameter is all the subtasks included in the composite task. 'ploy: prepare' will be executed in sequence ', // prepare before release. Check whether some Required Directories exist. If no directory exists, 'ploy: lock' is automatically created. // The lock file is generated, avoid executing two release processes on one server at the same time, resulting in State disorder 'ploy: release', // create a code storage directory 'ploy: update_code', // update the code, it is usually git. You can also rewrite this task and use the upload method to upload 'ploy: share' in sftp mode. // process shared files or directories 'ploy: writable ', // set the directory write permission 'ploy: vendor', // install the dependency 'ploy: clear_paths 'based on the composer configuration, // perform the delete operation 'ploy: symlink ', // set the symbol to connect to the latest updated code. The code that is accessed online now is the released code 'ploy: unlock', // Delete the lock file, so that the 'cleanup' will be released next time. // according to the keep_releases parameter, clear the old version and release the server disk space 'success' // The task is successfully executed, as defined above, generally used for prompting]); after ('ploy: failed', 'ploy: unlock'); // If the publishing fails, delete the lock file so that you can try again next time.

 

The above is a relatively complete automated deployment script configuration, do you feel very simple? Because most of the configuration work has already been done for you when you execute dep init!

One thing you need to do next is to add the ssh-key of the server you want to deploy to the authentication library of your git account. You can also create an account, only the git pull and git clone permissions of the repository are available, and the minimum permission principle is maintained. It should be noted that after the key is added, the first time you execute git clone on the server, you may need to enter yes, so the most secure way is, execute git clone on each server to be deployed and drag the repository code to another directory.

After completing the above tasks, all the preparations will be completed. Then you can perform the deployment test.

First, check whether the configuration is correct:

 

Dep config: dump beta // print the configuration of the beta environment dep config: dump prod // print the configuration of the production environment

If the printed configuration is correct, run the release task:

Dep deploy beta // release the current beta branch to the beta environment dep -- tag = v1.1 deploy prod // release the code of the v1.1 tag to the production environment, you can add the-p option, concurrently sent to all servers

A successful deployment should have the following output:

 

Tb git :( master) prepare dep -- tag = v1.1 deploy prod_1 Executing task deploy: prepare Executing task deploy: lock Executing task deploy: release Executing task deploy: update_code Executing task deploy: shared Executing task deploy: writable Executing task deploy: vendpoints Executing task deploy: clear_paths Executing task deploy: symlink Executing task php-fpm: restart Executing task deploy: unlock Executing task cl Eanup Executing task success released successfully!

View which version is used in the current production environment

Dep current prod // v1.1 should be output here

Check which version is used in the current production environment:

 

Dep current prod // v1.1 should be output here

If a problem is found after publishing to the production environment, you only need to execute the following command to roll back:

Dep rollback prod // actually only modifies the soft link pointing, so the execution can be completed quickly and basically cannot fail.

Using dep current prod again, we should be able to see that the previous version is rolled back.

For example, if a problem occurs before execution and the execution is interrupted, the following message may be displayed: Deploy locked. Therefore, you only need to execute the command:

 

Dep deploy: unlock prod // Delete the lock file

If the online disk space is too tight (usually not), run the following command to delete earlier versions:

dep cleanup

 

Here you should have mastered all about deployer. Although the first configuration does take some time, it may take half an hour or half a day. However, it is the next release process that is more elegant, fast, secure, and easy to roll back. Is there a little excitement?

If you have any problems during installation and use, add the group: 632109190 for discussion. Anyone interested in php, java, and O & M can add them. I am waiting for you here :)