CIサービス「Wercker」を活用し、開発を効率化

私は新卒でSIerに入社し、主にJavaアプリケーションの開発や、Solarisのサーバー構築・管理をしていました。そちらで4年勤めた後に転職し、ITコンサルタントとして開発支援業務を行ってきました。

そして３社目であるマツリカに、2016年の3月に入社しました。弊社は2015年に創業した新しい会社で、私が正社員の第一号でした。

今は自社サービスである「Senses」というSFA（Sales Force Automation：営業支援システム）を、13名ほどのチームで運営しています。そのうち、開発メンバーは6〜7名です。

私はSensesのアプリケーションの開発も行いますが、AWSを活用したインフラ面が主な担当になります。

Sensesの開発では、当初から「Wercker（ワーカー）」というツールを活用して、CI（継続的インテグレーション）の環境を構築し、効率的な開発を進めています。

「ステップ」の組み合わせで、自由にCI環境を構築できる

Werckerの導入時には、以前に使ったことのあるJenkinsやTravisCIなども合わせて検討しました。しかし、Werckerを試しに使ってみたところ、手軽に導入できて使いやすかったため、そのまま使い続けています。

当時はソースコードの管理にBitBucketを使っていたので、そこと連携ができるというのも決め手でした。今はGitHubに移行しているのですが、CIフローの定義ファイルはそのまま流用でき、遷移先のリポジトリにあわせて登録しなおすことで、比較的簡単に移行できました。

▼BitBucketやGitHubなど、連携先を選択できる

Werckerには「ボックス」という実行環境と、その上で実行される「ステップ」という仕組みがあります。リポジトリに置いたYAMLファイルに、使うボックスを指定し、コミットやマージのタイミングでどのステップを実行するかという設定を書いていきます。

バックエンド側では、RailsアプリケーションのAPI部分に対して、RoboCopによるコードの静的解析やRSpecによるテストの実行を行った後、AWSへのデプロイまでを自動化しています。

▼ステップを設定することで、デプロイまでのプロセスを自動化

フロント側では、AngularJSに対してGruntタスクを実行し、JSHintによる静的解析、ビルド、S3へのファイル転送を行っています。これらのCIの結果は、プルリクエスト上に表示されるため、おかしな点があればすぐに把握できる点も助かります。

▼ステップを実行することで、CIの結果を確認

自動デプロイからSlackへの通知まで。OSSも活用

ボックスもステップも、自作した定義や実装をWerckerのディレクトリーに登録しておくことで使えるようになります。自分で作るだけでなく、Werckerから公式に公開されているものもあるので、それを利用することもできます。

弊社ではボックスは自社で定義したものを使っていて、そこに、公開されている様々なステップを組み合わせて実行しています。

ステップは公式のものだけではなく、オープンソースで公開されているものが多数あります。それらを組み合わせることで、例えば、ビルドしたアプリケーションをAWSインスタンスにデプロイしたり、S3へのファイル転送といった処理も、アクセスキーやデプロイ先を指定するだけで実現できます。

弊社ではインフラにAWSのOpsWorksを使っているので、step-aws-opsworks-deployというステップを使用して、自動デプロイをしています。また、定義ファイルのYAMLにafter-stepsという設定を書くことで、OpsWorksへのデプロイ後に実行するステップを指定できます。

そのafter-stepsの処理で、step-pretty-slack-notifyというステップを使い、デプロイ結果をSlackに通知します。このステップはWantedlyさんが作って公開しているようですね。他にもWerckerの公式から出ているstep-s3syncというステップで、S3にファイルを転送しています。

小規模な開発チームに最適。今後はDockerの活用も

Werckerは今でも無料プランで使っています。無料プランでは、一度でふたつのCIを同時に回すことができます。それ以上になると待機状態になり、前のCIが終わり次第実行されていくような仕組みです。

今では5つほどのリポジトリを登録し、CIを回しています。ただ、ひとつのビルドは最大で25分までという制限があるため、注意が必要です。

自前で環境を構築・管理する必要がなく、サービスもこれまでのところ安定して稼働しているので、Werckerにはほとんど欠点を感じていないですね。たまにビルドが途中で止まってAbortが必要だったり、キャッシュが悪さをすることもありますが、稀です。

弊社のように10人に満たないような小規模なチームで、外部サービスに抵抗がなければ活用できると思います。今後もWerckerを活用して、現在手が回っていないE2Eテスト環境の整備などを行っていきたいと考えています。

また、Werckerは去年の中頃から、Dockerに対応したボックスの提供を開始したり、CLIツールの提供も開始されたりとアップデートされています。それらを活用することで、さらに開発効率を上げられそうなので、今後試していきたいと思います。（了）