本来は公式のチュートリアルに従うのが良いと思いますが，既存のコードにとりあえずTravisのマークを載せたいという方には参考になるかと思います。

Travis CIで何ができるのか

端的にはGithub等でコードを管理する際に自動でテストを走らせる事ができるツールです。

↓よく見るこれです。

公式の説明はこちら。

自分の行ったプログラムの変更がシステムに影響を及ぼさないか自動でチェックしてくれます。

今の所，チェックなんてローカルでやるし具体的な共有相手みたいなのも想定していないのでせいぜい環境を移行した時にどう動くかの簡易チェック的なものでしか運用しない予定です。でもOSSの人たちはみなやっているようなので今はフリだけでもできるようにしておこうというやつです。

本記事では最小限Travis CIでbuildを通すやり方のみ記載します。賢明な皆さんは是非きちんとしたサイトや資料を元に一から勉強して~~私に教えて~~ください。

下準備：TravisCIへの登録とリポジトリのアクティベーション

Githubのアカウントを持った状態で以下のTravis.comのページに飛びます。

travis-ci.com

ここからGithubアカウントとの連携をぽちぽちと進めて登録は終了です。

その後右上のメニューからSettingを選んで以下の画像のように適用するリポジトリを選びます。

f:id:ossyaritoori:20190208143844p:plain — Travis CIのSetting画面

これで下準備は完了です。

.travis.ymlの作成

.travis.ymlというファイルを作成することで自動テストを実行することが出来ます。

例えばPython3.5のパッケージで何某かを実行させたい場合は以下のように書きます。

language: python
python:
  - "3.5"

install:
  - python setup.py install
  #- pip install yaml
    
script:
  - python test.py

最初の行，language:pythonとあるのはどの言語でテストするかを示します。
python: 以下ではテストするバージョンを選択できます。
install:以降はどのモジュールが必要になるか記述します。setup.pyがある場合はそれを元にインストールすればいいですが，普通にpipから始まるコマンドも書けます。
script:以降では実際実行するコマンド群を表しています。この結果帰ってくる値が0であればテスト成功と判定されます。普通にディレクトリ移動などのシェル操作も出来ます。

結局やってることはリモートで仮想環境を立てて，該当する言語の環境を用意し，テストを実行・判定するという流れのようです。先程のWebページからどのように処理が進んでいるか確認できます。

f:id:ossyaritoori:20190208190539p:plain

こんな感じ。

ハマったこと

いろいろくだらないミス等をたくさんしましたが，一番時間を取られたのは，

GUIを表示するタイプ（cv2.imshowとか）のプログラムはテストを通すのが難しい

ということです。（ X server うんたらとかいうErrorが出る）

dvfbというのを使ってGUIの設定などできるようですが，今の理解度ではGUIの有無をSwitchできるように調整する方が早かったです。

テストが通ったら

以下の画面の箇所をクリックするとこの画像のURLを入手できます。

f:id:ossyaritoori:20190208191607p:plain

これをマークダウンでREADMEに貼り付ければ自分のパッケージに反映されます

余談：リポジトリの構造について

継続的インテグレーションとありますが結局ちゃんとしたリポジトリの構造から用意するのが良いです。

リポジトリの構造については様々な意見を聞きますが以下の記事の通りにするのが妥当そうです。

qiita.com

しかし開発とかいろいろやってると変なフォルダたくさん作っちゃったりしてややこしくなるんですよね。意図的に機能ごとにブランチを切る開発スタイルに自然と移行したいものです。

setup.pyについて

さっきの記事にもありましたが，setup.pyを置いておくといろいろ捗る傾向にあります。

qiita.com

説明は今回は省くとしてこんな感じに書いたりします。（ちょっと元ファイルから変えてる）

from setuptools import setup, find_packages
import sys

sys.path.append('./sample')

setup(
    name = 'HOGE',
    version = '0.1',
    description='This is test codes for travis ci',
    install_requires=['numpy','opencv-contrib-python==3.4.0.12','docopt','matplotlib'],
    packages = find_packages(exclude=('sample', 'markers','trial')),
    license = 'MIT',
    author='Ossyaritoori',
)

あとがき

この手のインテグレーションの話を見るとやはりはじめが肝心です。きちんとした手法で最初から管理している場合はこんなことには悩みませんが，我流でいろいろコーディングしている所にこういうツールを導入するのは非常にコストが重いように思われます。

エンジニア個人としてはどこかのタイミングで導入に踏み切ってリポジトリ単位で慣れていくというのが良いように思いますが，組織としてこういうのを導入して管理するのは結構難しそうです。大変なことをする割に単体では実務自体にはつながらないのが辛い所ですよね。「N日人かけて自動でテストできるようにしました。」『それで次の機能はいつ作るの？』「…」

次のプロジェクトからはきちんと構造考えて作る…！