GithubやBitbucketのプライベートリポジトリでCI/CD

GithubやBitbucketで管理している プライベートリポジトリに対して、 CI（継続的インテグレーション） とCD（継続的デリバリー）を実現する。 ここでは、werckerを使って、 テストとデプロイを自動化する方法をメモしておく。 werckerは、GithubとBitbucketどちらのプライベートリポジトリにも対応しており、 今のところ無料で利用できる。

デプロイ先はherokuとした。 herokuは、基本的に無料で、手軽にPaaS環境を利用できる。 ただし、無料枠での利用においては、 30分間アクセスがないとスリープ状態になったり、 稼働時間を月1,000時間に制限されたりするので注意する。

想定するアプリケーションは、Python3とFlask（Python向けウェブアプリケーションフレームワーク）で実装されたウェブサービスとする。

まず、リポジトリに3つの設定ファイル（wercker.yml、Procfile、runtime.txt）を追加する。 wercker.ymlは、werckerで利用する設定ファイルで、 大きく分けてbuildとdeployという2つのセクションから構成される。 buildセクションには、依存ライブラリのインストールと、ユニットテストの実行について記述する。 一方、deployセクションには、 herokuへのデプロイ時に参照するSSHキーペアの名前（key-name: HEROKU）を指定する。 HEROKUという名のSSHキーペアの作成手順は、後述する。 また、最新版のheroku CLIを利用するために、 install-toolbelt: true と記述しておく。 Procfileには、アプリケーション名: コマンドの記法で、起動コマンドを記述する。 さらに、runtime.txtでPythonのバージョンを指定する。 特に指定がなかった場合には、Python 2系がインストールされるので注意する。

# wercker.yml
box: python
services:
build:
    steps:
        - script:
            name: install dependencies
            code: |
                pip3 install -r requirements.txt                

        - script:
            name: test
            code: |
                python3 -m unittest discover -v && flake8 .                
deploy:
    steps:
        - heroku-deploy:
            install-toolbelt: true
            key-name: HEROKU

# Procfile
web: python -m web.main

# runtime.txt
python-3.6.1

続いて、werckerのウェブUIで、wercker・リポジトリ間の紐づけと、CIにおけるパイプラインを設定する。 werckerのユーザ登録後、アプリケーションをdashboardから追加し、リポジトリと紐付ける。 アプリケーションの追加後、Workflowsタブを選択し、Add new pipelineからdeployを追加する。 さらに、masterブランチへのPUSHのタイミングで、 buildとdeployが連続して動作するように、ウェブUI上でbuildの直後にdeployをつなげる。 また、deployの実行中にherokuへログインするために、 EnvironmentタブのGenerate SSH Keysボタンから、SSHキーペアを生成し、 環境変数（HEROKU_PRIVATEとHEROKU_PUBLIC）として格納する。 加えて、Environmentタブから、 herokuのアプリケーション名を指示する環境変数 （変数名はHEROKU_APP_NAME、値はherokuのアプリケーション名）を登録する。

最後に、herokuのウェブUIから、werkcerで生成したSSH公開鍵をherokuへ登録する。 masterへPUSHしたときに、buildからdeployまで正常に動作すれば完了。 他の参考ページを見てみるとherokuのAPI KEYが必要だと書かれているが、 今回のアプリケーションでは、 werkcerのEnvironmentタブや、WorkflowsタブのPipeline environment variablesを見てみても、 そのような記述はなかった。 ただ、API KEYを使って何か設定した記憶があるので、おそらく必要なんだろうと思う。 が、どこで設定したのか覚えていない。。。