少年，是時候換種更優雅的方式部署你的php代碼了

讓咱們來回憶下上次你是怎麼發佈你的代碼的：

1. 先把線上的代碼用ftp備份下來

2. 上傳修改了的文件

3. 測試一下功能是否正常

4. 網站500了，趕忙用備份替換回去

5. 替換錯了/替換漏了

6. 一臺服務器發佈成功

7. 登陸每一臺執行一遍發佈操做

8. 加班搞定

9. 老闆發飆

...

尤爲如今的互聯網行業，講究快速迭代，小步快跑。像bug修復或者小功能的修改幾乎天天都發版本，大功能的版本迭代每週也差很少會有一次。相信很多同行們像我上面說的這樣發佈本身的代碼吧。或者可能先進一點，直接去服務器上執行一條相似git pull的命令拖下倉庫中的代碼，可是若是你的代碼運行在集羣中呢？每臺機器登陸一次執行一次git pull嗎？若是發現代碼有問題須要回滾呢？

若是你還在像我上面說的這種方式部署本身的代碼的話，那麼我但願你能耐心看完這篇文章，今後擺脫代碼部署之痛。

 

其實繞了這麼一圈今天是想向你們介紹一下用php寫的代碼發佈工具：deployer。

deployer具備如下吸引人的特性：

- 快速      採用了好比並發發布、ssh通道複用、緩存可用狀況下使用緩存等技術加速代碼部署

- 原子部署   在新發布的版本內執行全部定義的操做，諸以下載依賴、設置文件訪問權限等都不會直接影響線上，只有所有成功後，最後一步設置軟鏈纔會真正替換線上代碼

- 快速回滾   因爲採用了原子部署，因此回滾也只是從新設置一下軟鏈指向

- 併發部署   集羣環境下，併發在全部機器上執行相同的部署流程

- 一致性     集羣環境下，只有全部機器都執行成功纔算成功，一臺失敗則所有失敗

- 內置多個框架發佈模板   好比Laravel、Yii、Symfony、CodeIgniter、Zend Framework等

- 易擴展     很容易能夠依據本身的項目用Common模板編寫發佈流程

安裝： 

composer global require deployer/deployer

安裝完成後，切換到本身的項目目錄，執行dep init，按照本身項目使用的框架選擇生成的部署模板：

➜  tb dep init
Please 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

若是你的框架未使用上面列出的任何一個框架，則選擇0，而後回車，就會生成通用的發佈模板。

執行完這一步應該會在你的項目根目錄生成一個deploy.php文件，你所須要的作的一切就是編輯這個腳本，填寫一些本身的服務器和項目配置，而後定製一些task。

下面我將用一個具體的配置文件來介紹deployer的使用，配置文件以下：

<?php
namespace Deployer;

use Symfony\Component\Console\Input\InputOption;

require 'recipe/common.php';

option('tag', null, InputOption::VALUE_OPTIONAL, '發佈的tag');

// 全局配置文件   
set('ssh_type', 'native');    // 登陸遠程主機使用的方式，有三種：phpseclib（默認方式）、native、ext-ssh2
set('ssh_multiplexing', true);  // 是否開啓ssh通道複用技術（開啓能夠下降服務器和本地負載，並提高速度）
set('keep_releases', 10); //    報錯10個以前版本，設置爲-1表示一直保存歷史版本
set('repository', 'git@xxxxxxx.com:loc/loc-api.git');    // 代碼倉庫的地址，只支持git
set('branch', 'master');    // 發佈代碼時候默認使用的分支
set('shared_files', []);    // 共享文件列表   這裏面列出的文件會被移動到項目根目錄的shared目錄下，並作軟鏈
set('shared_dirs', []);     // 共享目錄    同上
set('writable_mode', 'chmod');  // 採用哪一種方式控制可寫權限，有4中：chown、chgrp、chmod、acl（默認方式）
set('writable_chmod_mode', '0755'); // 當使用chmod控制可寫權限的時候，賦予的可寫權限值
set('writable_dirs', []);   // 可寫目錄   規定那些目錄是須要能夠被web server寫入的
set('clear_path', []);  // 設置在代碼發佈的時候須要被刪除的目錄
set('http_user', 'nginx');  // web server的用戶，通常不用設置，deployer會自動判斷
set('release_name', function () {   // 設置發佈版名稱，這裏優先使用tag做爲名稱，不傳的話會使用日期+時間表示發佈時間
    if (input()->hasOption('tag')) {
        return input()->getOption('tag');
    }
    return date('Ymd-H:i');
});

// 能夠設置多個服務器，發佈的時候根據設置會同步發往多個服務器
// 針對每一個服務器能夠單獨設置參數，設置的參數會覆蓋全局的參數
server('prod_1', 'xxx.xxx.xxx.xxx')
    ->user('root')
    ->password('xxxxx')
    ->set('deploy_path', '/var/www/tb')   // 代碼部署目錄，注意：你的webserver，好比nginx，設置的root目錄應該是/var/www/tb/current，
                                          // 由於current是一個指向當前線上實際使用的版本的軟鏈
    ->stage('prod');  // 標識該服務器類型，用於服務器分組

server('prod_2', 'xxx.xxx.xxx.xxx')
    ->user('root')
    ->password('xxxxx')
    ->set('deploy_path', '/var/www/tb')
    ->set('branch', 'master')   // 指定發往這個服務器的分支，會覆蓋全局設置的branch參數
    ->set('extra_stuff', '...') // 隨意指定其餘什麼參數
    ->stage('prod');
    
server('beta', 'xxx.xxx.xxx.xxx')
    ->user('root')
    ->password('xxxxx')
    ->set('deploy_path', '/var/www/test')
    ->set('branch', 'beta')   // 測試環境使用beta分支
    ->stage('beta');    // 放在beta分組


// 配置的任務
task('success', function () {
    Deployer::setDefault('terminate_message', '<info>發佈成功!</info>');
})->once()->setPrivate();   // 增長once調用那麼這個任務將會在本地執行，而非遠端服務器，而且只執行一次

desc('重啓php-fpm');    // 能夠給任務增長一個描述，在執行dep list的時候將能看到這個描述
task('php-fpm:restart', function () {
    run('systemctl restart php-fpm.service');  // run函數定義在服務器執行的操做，一般是一個shell命令，能夠有返回值，返回命令打印
});     // 聰明如你必定發現了，能夠用run函數製做一些批量管理服務器的任務，好比批量重載全部的nginx配置文件、批量執行服務器上的腳本等

after('deploy:symlink', 'php-fpm:restart'); // 鉤子函數，表示執行完設置軟鏈任務以後執行php-fpm重啓任務

desc('發佈項目');
task('deploy', [    // 能夠設置複合任務，第二個參數是這個複合任務包括的全部子任務，將會依次執行
    'deploy:prepare',   // 發佈前準備，檢查一些須要的目錄是否存在，不存在將會自動建立
    'deploy:lock',  // 生成鎖文件，避免同時在一臺服務器上執行兩個發佈流程，形成狀態混亂
    'deploy:release',   // 建立代碼存放目錄
    'deploy:update_code',   // 更新代碼，一般是git，你也能夠重寫這個task，使用upload方法，採用sftp方式上傳
    'deploy:shared',    // 處理共享文件或目錄
    'deploy:writable',  // 設置目錄可寫權限
    'deploy:vendors',   // 根據composer配置，安裝依賴
    'deploy:clear_paths',   // 根據設置的clear_path參數，執行刪除操做
    'deploy:symlink',   // 設置符號鏈接到最新更新的代碼，線上此時訪問的就是本次發佈的代碼了
    'deploy:unlock',     // 刪除鎖文件，以便下次發佈
    'cleanup',  // 根據keep_releases參數，清楚過老的版本，釋放服務器磁盤空間
    'success'   // 執行成功任務，上面本身定義的，通常用來作提示
]);


after('deploy:failed', 'deploy:unlock');    // 若是發佈失敗，則刪除鎖文件，以便下次重試

上面就是一個比較完整的自動化部署腳本配置了，是否是感受到很簡單？ 由於大部分配置工做在你執行dep init的時候就已經幫你作了！

在接下來還須要作的一件事情就是把你要部署的服務器的ssh-key加入到你的git賬號的認證庫裏面，你也能夠建立一個帳戶，只擁有倉庫的git pull和git clone權限，保持最小權限原則。須要注意的是，加完key以後，首次在服務器上執行git clone可能會須要讓你輸入yes，因此最穩妥的辦法是，去每臺要部署的服務器上去執行一遍git clone，把倉庫代碼拖一份到其餘目錄。

作完上面的事情以後，全部的準備工做就算完成了。接下來就能夠進行部署測試了。

首先檢查下配置有沒問題：

dep config:dump beta    // 打印beta環境的配置
dep config:dump prod    // 打印生產環境的配置

打印出來的配置沒有問題的話，接着執行發佈任務：

dep deploy beta // 發佈當前beta分支到beta環境
dep --tag=v1.1 deploy prod // 發佈v1.1這個tag的代碼到生產環境，能夠增長-p選項，併發發往全部服務器

一次成功的部署應該會有相似以下輸出：

➜  tb git:(master) ✗ 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:vendors
✔ Executing task deploy:clear_paths
✔ Executing task deploy:symlink
✔ Executing task php-fpm:restart
✔ Executing task deploy:unlock
✔ Executing task cleanup
✔ Executing task success
發佈成功！

查看當前生產環境使用的哪一個版本

dep current prod  //這裏應該會輸出v1.1

查看當前生產環境使用的哪一個版本：

dep current prod  //這裏應該會輸出v1.1

若是發佈到線上以前以後發現有問題，須要回滾，只須要執行：

dep rollback prod   // 實際上只是修改軟鏈指向，因此很快就能執行完成且基本不可能失敗

再次用dep current prod應該就能夠看到回滾到以前版本了

再好比以前執行出了問題，被中斷，再次執行可能會提示：Deploy locked，那麼只用執行：

dep deploy:unlock prod // 刪除鎖文件

若是線上磁盤空間吃緊了的話（通常不會），能夠執行以下命令刪除掉太早之前的版本：

dep cleanup

到了這裏關於deployer全部你應該都掌握了。雖然第一次配置的確須要花點時間，可能半個小時也可能半天。  不過換來的倒是接下來更優雅、快速、安全、易回滾的發佈流程，這麼想一下是否是還有點小激動呢？

若是在安裝使用過程當中有什麼問題的話能夠加羣：632109190進行討論。對php、java、運維感興趣的同窗均可以加進來，我在這等大家 :)