讓我們來回憶下上次你是怎么發布你的代碼的：
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、運維感興趣的同學都可以加進來，我在這等你們 :)