UUUMエンジニアブログ

UUUMのエンジニアによる技術ブログです

UUUMにおけるSymfony2開発環境

PHP Symfony

どうも、エンジニアのやまぐちです。

先日Symfony2 Meetup #8で人生初のLTをした UUUMにおけるSymfony2開発環境 について書かせていただこうと思います。

CREASについて

まずはじめにUUUMの開発でメイン事業にあたるCREASについて説明したいと思います。

f:id:tky_ymgc:20160208143336p:plain

CREASとは次世代YouTuberへのサポート・育成を目的としているWebアプリケーションです。
サービス内容としては企業からのタイアップオファーや動画作成に関する支援、音源や画像などの素材やYouTubeのノウハウの提供、 トップクリエイターによる勉強会やユーザ同士の交流会を定期的に開催するなど多岐にわたります。

このようなサービスを提供するシステムがCREASであり、我々エンジニアが日々開発に励んでいます。

旧CREASの開発環境

CREASは昨年12月にSymfony2で動作する新システムへと移行されました。
理由としては旧CREASにいくつか問題を抱えており、以下の様な環境で開発をしていました。

  • Drupal7 (CMS)
  • SCP or Filezilla (手動デプロイ)
  • GitHub (ソースコード管理)

ではなにが問題だったのか…

テストを書いていない

プログラムのテストをまったくしていなかったので、コードを変更して正常に動くかわからない状態になっていた。
そのため機能の追加や修正の要望に対して調査に時間がかかり素早く対応できない。

コーディング規則がない

開発当初に明確なコーディング規則などを設けていなかったため、開発したエンジニアがそれぞれ自由に書いていた。
そのため可読性が悪く理解するまでの時間がかかってしまうこと、仕様追加やバグの調査・修正が困難となった。

デプロイが手動

本番へのデプロイ作業がサーバ2台に手動で行うので人的ミスが起きてしまう可能性が常にあった。(実際に調べてみると2台のサーバで差異が生じていた)
また、GitHub側で管理しているファイルと本番側のファイルに大量の差異が生まれ、どちらが正しいファイルなのかわからないこともあった。

UUUMのSymfony2開発環境

そのためSymfony2での開発では上記の問題を踏まえて環境を改善しました。

環境整備

UUUMでは開発者の環境を合わせるためmakeコマンドでシェルスクリプトを走らせ自動的に整えます。

コーディング規約

コーディング規約については PSR-2 に準拠していますが、導入の目的は複数メンバがコードを読む際に認識のズレをなくすためです。
Gitのコミットフックに設定しているので、コミットをすると PHP CS Fixtur が実行されPSR-2のチェックが走ります。
また、このコミットフックを各個人で設定するのは面倒ですが、UUUMではmakeコマンドで設定されるため手間がかかりません。
これにより統一された綺麗なコードが担保できる様になりました。

コードレビュー

GitHubでプルリクエストを発行し他の開発者にレビューをしてもらいます。
このプルリクエストには他の開発者が仕様を理解するために、概要や技術的変更点、影響範囲など細かく内容を書くことが義務付けられています。
そのため自分以外の人がわからないようなコードは管理されなくなりました。

テスト方針

UUUMでは追加するプログラムに対して必ずテストを書くようにしています。
そのためテストをしていないプログラムがマージされることはないので、修正や変更が容易になりました。

Symfony2でのテスト

Symfony2でのテストはPHPのテスティングフレームワークであるPHPUnitを利用しています。
PHPUnitの利用メリットは比較的簡単に記述ができること、手動では面倒なテスト手順を自動化してコマンドで何度でもテストが実行できる点です。
また、作成したテストコードは先ほど説明したとおり動作保証、仕様書代わりとなるのでプログラムの品質維持・向上にもつながります。

テストデータ

PHPUnitのテストデータはどうやっているのかというと、UUUMでは DoctrineFixturesBundle と AliceBundle を導入しています。
テストファイルに直接記述しても良いですが、DoctrineFixturesBundleを導入することでデータをDBに投入できるようになります。
また、DoctrineFixturesBundleを単体で使用するよりも、AliceBundleを導入することによりyml形式でfixtureを記述できるのでテストデータの見通しを良くすることができます。

テストデータを投入するタイミングは共通テストクラスを継承し、その中でfixtureを読み込む、テスト実行前に処理を呼び出すという流れです。
これによりPHPUnitでのテストがよりスムーズに行うことができるようになりました。

テストの段階

テストの段階には2つあります。
一つはローカル環境でのテストで、リモートブランチにpushする前にローカル環境でテストをして動作確認をします。
もう一つはリモートブランチ側でのテストで、GitHubのリモートブランチにpushをすると自動でテストが走ります。
ここでテストが通らないmasterブランチへはmergeは禁止されているので再度テストの修正が求められます。
また、masterブランチへのpushではテストが成功するとStaging環境に自動デプロイされる仕組みとなっています。

自動化

テストの自動化は以下の3つを使用して構築されています。

  • Slack (通知)
  • GitHub (プルリク)
  • CircleCI (ビルド&テスト&デプロイ)

自動化の流れ

  1. GitHubへpush
  2. GitHubがSlackとCircleCIにpushを通知
  3. 通知を受けたCircleCIがビルドを開始
  4. CircleCIがビルド完了をSlackに通知
  5. 結果をSlackから確認

自動化の流れですが、リモートブランチへpushした段階で始まります。
pushを受け取ったGitHubはSlackとCircleCIにpushがあったことを通知します。
次に通知を受け取ったCircleCIはビルドを開始しこの中でテストが実行されます。
ビルドが完了するとSlackに通知が飛び、結果を確認することができるという仕組みなっています。
このように自動化したことでチーム内で今何が起こっているのかを共有できるので開発が効率的になりました。

デプロイ

構成管理ツールには Fabric を使用しています。
デプロイにFablicを使う理由としては他の構成管理ツールと違って覚えることが少なく、シェルスクリプトとしてまとめたコマンドをFablic側のメソッドに囲むだけで使用ができます。
このツールによりサーバへのデプロイ作業を自動化できるようにしています。

まとめ

上記のように以前とは全く違う開発環境になりましたが、実際に開発が進んでいくと効率が格段に上がったと感じました。
そして何よりコードを楽しく書くことができるという気持ち的な問題も大きいと思います。

最後に

UUUMではエンジニアを絶賛募集中です。
我こそはという方、是非履歴書をUUUMまでお送りください。
※毎月29日は肉が食べ放題です

www.wantedly.com