MNTSQ社の開発環境のご紹介

MNTSQ社でソフトウェアエンジニアをやっております西村と申します。
弊noteへのご来訪まことにありがとうございます。
本日は弊社の開発環境をご紹介いたします。

開発言語

弊社では基盤部分をRuby on Railsで開発しております。一部、OCR処理は都合でJavaを利用したり、機械学習はPythonが得意ですのでPythonを利用しております。

レビュー環境

リリースブランチや開発ブランチへの直接プッシュは禁止しております。GitHubでブランチを保護する方法につきましては、以下の記事などをご参考ください。

[GitHub] ブランチの保護設定を活用しよう 【レビューが通るまでマージさせんぞ】 | Developers.IO

リリースブランチや開発ブランチに変更を加えるには、Pull Requestを介して行います。Pull Requestのレビューは必須となっており、少なくとも一名がapproveしない限り開発ブランチにはマージいただけません。

弊社ではRubyのlinterとしてRuboCopを利用しております。もちろんオレカッコイーなコードスタイルは許可されておらず、そのようなコードスタイルはRuboCopが自動で整形いたします。そのため弊社ではRubyのコードスタイル論争は発生いたしませんので、集中して業務に取り組んでいただけます。

また、自動で整形されますので、Pull Requestのレビューで「変数展開が無いのでシングルクォートにしてください」「インデントがタブになっているので半角スペースにしていただけると」「一行だけなのでif文は後ろに書いてもらえますでしょうか」「なんで未使用変数消さないんですかー？」などなど、どこかで聞いた事があるような些末なレビューで時間を費やすことはございません。

ネストが深すぎるなどの問題が発生した場合は、さすがにRuboCopも直せませんが、Pull Requestはマージできないようブロックされる仕様となっております。機械学習部分はPythonを利用しておりますが、Pythonのコードスタイル適用にはblackというlinterを利用しております。

rubocop-hq/rubocop: A Ruby static code analyzer and formatter, based on the community Ruby style guide.
psf/black: The uncompromising Python code formatter

RuboCopについては下記の記事などが参考になるかと存じます。

RuboCop is 何？ - Qiita

RuboCopやBlackをpush時に自動で実行するためにGitHub Actionsを利用しております。GitHubの各リポジトリのActionsタブから多数のActionsがご利用いただけます。

Actions | GitHub

設定方法については以下の記事などご参考ください。

【GitHub Actions】 RailsアプリをRuboCop/ESLintチェック＋Slack通知＋キャッシュする - Qiita

参考までに、弊社でのlinterの活躍ぶりを少しご紹介いたしましょう。

弊社ではデグレが発生しないように、RSpecでテストを記述しております。すべてのAPIのエンドポイントについてRSpecでテストを記述する必要がございます。

rspec/rspec-rails: RSpec for Rails 5+

RSpecにつきましては、以下の記事などが参考になるかと存じます。

使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

弊社では自動テストも実施しております。Pull RequestではCircleCIが自動でテストいたします。CircleCIでのテストをパスしない限り、マージいただけないようになっております。なお、サバンナへの出張はございませんので、ご安心ください。

最先端の CI/CD プラットフォーム | CircleCI - CircleCI

また、あるPull Requestで書かれたテストが別のPull Requestでパスしないといった事もございますため、最新の開発ブランチがマージされていないとPull Requestはマージいただけません。GitHubとCircleCIとの連携方法については、下記の記事など参考になるかと存じます。

GitHub+CircleCI入門 - Qiita

課題管理

課題管理にはBacklog、Redmine、Trello、Asana、ZenHubなどツールはさまざまございますが、弊社ではGitHubのIssueを利用しております。

進捗管理にはGitHubプロジェクト使っております。カンバンはプロジェクトの進捗管理の鉄板でございます。

タスクの重要度はラベルで管理しております。レベル1から3のラベルを利用しております。弊社はスタートアップ企業で開発が必要な事項が非常に多いので、基本的には期限が迫っているものがレベル3となる事が多くなっております。

障害検知

特にひねりはございませんが、弊社では問題が発生した際に、主にIncoming Webhookを利用してSlackの通知チャンネルに通知されるようになっております。Ruby、Pythonもそうですし、インフラ面ではMackerelやAWS、PagerDutyからの通知もSlackに集約されております。

Dockerコンテナがストップした、Railsのプロセスが応答しなくなったなど、より緊急性の高いものについては、いち早く検知するためにPagerDutyから弊社役員に電話にて通知されるように工夫しております。PagerDutyに関しては、以下の記事などをご参考ください。

PagerDutyを使ってみた – サーバーワークスエンジニアブログ

弊社では障害対応も可能な限り速やかに行える体制を整えております。障害対応の手順についてもドキュメント化されております。Slackからエラーが通知されると即座に障害対応が開始されます。まずGitHubでエラー内容についてのIssueがたてられ、お客様への影響と障害の範囲を絞り込むところまでの調査が最優先で行われます。内容がはっきりした後は、優先順位を決めて緩急つけて対応が進められるような体制となっております。

大きな障害に発展しないよう、定期的にヒヤリハットや障害を振り返る場を設けております。10のヒヤリハットは1の小さな障害につながり、100の小さな障害は1の大きな障害につながります。問題が小さな段階できちんと芽を摘んでおくことが肝要です。

デプロイまでの流れ

弊社ではgit-flowとほぼ同様のごく一般的なマージフローを採用しております。

featureブランチは開発ブランチからブランチを切って、レビューが完了すると開発ブランチにマージいたします。

リリースタイミングになると、開発ブランチからリリースブランチにマージいたします。

hotfixが必要になった場合は、まずリリースブランチからhotfixブランチを切って対応し、リリースブランチへマージします。事後でリリースブランチから開発ブランチへのマージを行っております。ここはgit-flowと異なっているかも知れません。

git-flowについては下記の記事などが分かりやすいかも知れません。

Git-flowって何？ - Qiita

弊社の環境で少し特殊な点といたしまして、お客様ごとのリリースブランチが存在いたします。各リリースブランチには、各お客様向けの環境をデプロイする時にマージいたします。

AWS環境では常識的な事項として、SSHでrootやec2-userといった特権ユーザーを利用しておりません。基本的にユーザーごとのアカウントを発行しておりますし、アカウントの使い回しなどはしておりません。

弊社では基本的にヒューマンオペレーションでの問題が発生しないよう、リリースブランチへのマージと共に自動で各環境へのデプロイが開始されます。まだ力及ばず一部のバッチ処理などは手動となっておりますが、これらも基本的にはペアオペにて対応し、また手順書も事前に準備するよう徹底しております。ログは残しておりますため、万が一の時はログをさかのぼって確認することが可能となっております。

構成はTerraformで管理しておりますし、OS部分はDockerコンテナを利用しており、極力「俺のマシンでは起こらない」問題は発生しないように努めております。Dockerについてはmacですごく遅い問題はございますが。

あとがき

最後までお読みいただきありがとうございました。
いかがでしたでしょうか。
よろしければ、スキやTwitterなどでの共有をよろしくお願いいたします。

ごく一般的な開発環境ですので、どなた様でもジョインいただける環境となっております。
よろしければ下記からご応募ください。