Mattermostの開発に参加してみた記録
この記事はFujitsu extended Advent Calendar 2016 16 日目の記事です。
※この記事に描かれていることは個人の見解であり、所属する組織の公式見解ではありません。`
個人的な活動の経験から得た知見の共有を目的としています。
はじめに
SI 企業で働く傍ら社外のプログラミング関係の勉強会にも参加しており、その中で語られる OSS 的な開発プロセスがどんなものであるか、実際に参加して体験してみたいと常々思っていました。
今年の夏ごろからMattermostという Slack クローンの OSS チャットツールの開発に参加し始めているので、Mattermost 開発の進め方などを紹介したいと思います。
他の組織の開発を体験することで、日頃の開発の改善点が見つかるのでは無いかというのが参加のモチベーションです。
Mattermost を選んだ理由としては、今年の初め頃から日常的に Mattermost を利用しており、Eat Your Own Dogfood の精神で「より良くしたい」という意識を持ちやすいことです。
また、Mattermost はサーバーサイドの Go 言語、フロントエンドの React.js を始めとし、Dockerfile や iOS,Android アプリ(最近 react-native で書き直し中)、Electron 製のデスクトップアプリなど、新し目の技術を取り入れているため、普段は使わない技術に触れられるところが魅力でした。
開発に参加してると言っても、枝葉の Issue 対応ぐらいしかしていないので、もちろん Mattermost チームを代表しての記事ではありません。
誤っている部分がありましたら、報告いただけると幸いです。
チャットツール
Mattermost
Matermost は Palo Alto にあるMattermost, Inc.が開発しているオープンソースのチャットツールです。
公式サイトにもあるようにOpen source, self-hosted Slack-alternativeを謳っています。。
名前の由来はachieve what matters most(最も重要なことを達成する)だそうです。
機能的には Slack に追従することを目的としつつ、オンプレミスで動作可能であることやオープンな場で開発されていることを強みとしています。
また、Slack にはない多言語対応や、Enterprise 版では AD/LDAP 認証を利用できるなど独自の機能も追加しています。
Pricing – Mattermost
隔月の定期リリースを行っており、次回の v3.6 のリリースは 2017/1/16 に予定されています。
その他のチャットツール
Mattermost 以外にも Chat ツールはプロプライエタリ・OSS 含め様々あります。
| 名前 | 公式サイト | Github | スター数 | 言語 |
|---|---|---|---|---|
| Slack | Slack: Be less busy | SaaS のみ | - | PHP |
| HipChat | HipChat - Atlassian | SaaS のみ | - | ? |
| Mattermost | Mattermost | github |  |
go,js |
| RocketChat | Rocket.Chat | github |  |
js,coffee |
| Zulip | Zulip | github |  |
python,js |
| Actor Messanger | Actor Messenger | github |  |
java,scala,swift |
| Let's Chat | Let's Chat | github |  |
js |
| Kandan | KandanApp | github |  |
js,coffee,ruby |
参考：Kickball/awesome-selfhosted
基本無料かつサーバーのお守りの必要のない SaaS である Slack がチャットツールの定番かと思いますが、やはり組織内で利用するには外部サービスということで利用に慎重になってしまう部分があったため、何も心配せず使える OSS を選択していました。
私は OSS としては Kandan, Let's Chat, Mattermost しか使ったことがないですが、Rocket.chat と Zulip も開発が活発なため、OSS のチャットツールを検討する場合は候補となるかと思います。
Kandan は機能的に物足りなく、Let's Chat は快適に利用できてはいましたが最近ほとんどメンテナンスされていないため、Mattermost へ乗り換え、今でもコミュニケーションツールとして利用しています。
Mattermost 開発ツール
Mattermost チームは多くのサービスを使って開発されており、そのほとんどが誰でも閲覧できるところに公開されています。（各サービスのアカウントを作成する必要はありますが）
Mattermost
Mattermost 開発におけるコミュニケーションの多くは Mattermost 上で行われています。
バグのトリアージから Pull Request や Githu Issue への更新の通知、ユーザーフォーラムの質問への回答依頼など、Mattermost 本体に関わることから、ドキュメンテーション、ローカライズなどなど開発に関することが日頃から議論されています。
ほぼすべて英語です。
「どこどこのチャンネルに属さなくてはいけない」という指定は無いと思いますが、開発に参加する場合はContributorsと、開発対象のチャンネル(Documentation、i18n - localizationなど)の動向はチェックしておいても良いかと思います。
開発チャットとして使われている Mattermost は最新のコードから作成された環境のため、新機能をいち早く試すことができます。
最近では Slack にあるような、投稿に対する Reaction の機能などが追加されています。
最初にログインした時にデフォルトで参加することになるチャンネルであるReceptionの参加者数は 1184 名(2016/12/12 時点)となっています。
Github
Github ではソースコード、Issue、Pull Request などが管理されています。
最近追加された Github の新機能であるProjectsや Reviewers 指定なども積極的に採用しています。
また、Mattermost 本体のソースコードだけでなく、Mattermost の organization ではドキュメント(Sphinx 製)やDockerfile、デスクトップ・Android・iOSアプリなどのソースコードも公開されています。
最近ではReact Native によるスマホアプリの開発も始まっているようです。
JIRA Cloud
JIRA でも Issue の管理が行われています。
Github の Issue 管理と被る部分もありそうですが、おそらく JIRA がメインの Issue Tracker で使用されており、Github は Github に慣れている人への Issue 報告の場や Help Wanted Issue 置き場として利用しているように思います。
Jenkins
CI サーバーとして Jenkins を利用しています。
PullRequest が作成されると、テストとチェックスタイルが実行され、CI の結果は PullRequest へ通知されます。
Mattermost Peer-to-Peer Forum
ユーザーによる Peer-to-Peer のフォーラムも用意されています。
回答の必要があるトピックについては、定期的に開発者チャットの方でキャッチアップされているのため、回答がつかないということはあまり無いようです。
Mattermost Translation Server
翻訳作業用の Pootle サーバーです。
翻訳については、別エントリに詳しく書いています。
Mattermost の Localization フロー - Qiita
Code Contribution
コードを送る際に必要なプロセスは、公式のDevelopment Processにまとめてあるので、詳細についてはこちらを参照ください。
もちろん上記のドキュメントについてもオープンソースとして公開されており、PullRequest も受け付けています。https://github.com/mattermost/docs
ここでは、メインリポジトリであるmattermost/platformへのコントリビューションのざっくりとした流れを紹介します。
（Github での PullRequest の作り方などの基本的なことには触れません）
チケット選択
まず、対応するチケットを下記から選びます。
-
Help Wanted Issues - Github
- 2016/12/8〜2017/1/8 まで、4 つプルリクを送るとT シャツ(デザイン違うかも)が貰えるMattermost Holiday Hackfestが開催中
- 2016 年 10 月のHacktoberfest以降、Github に Help Wanted Issue が作成されるようになった
-
Accepted Pull Request - JIRA
- Good First Contribution - JIRAというのもあります。が、最近あまり追加はされてないようです。
CLA
対応するチケットが決まったらMattermost Contributor Agreementを結んでおきます。
これをやらずに PullRequest を送ると、Mattermost チームの方から Pull Request のコメントとして上記 CLA を結ぶよう言われます。
Developer Machine Setup
修正したソースコードの動作を確認するために、ローカルで Mattermost を起動するための環境を作ります。
Developer Machine Setupを参考に。(Docker や Go 環境が必要です)
コーディング
Mattermost は Github Flow を採用していると思われます。
PullRequest 用の作業をする際は、master から開発用ブランチを作成し、開発が終わったら master に対して PullRequest を作成します。
ブランチ名は JIRA チケットならplt-394のように JIRA のチケット番号を使用します。
JIRA チケットがなく、Github Issue のみある場合はgh-555のように Issue 番号を使用しています。
実際のコードの修正部分ですが、リポジトリ内のファイル構造の概要はRepository Structureに書かれています。
個人的な感想としては、サーバーサイドの Go の部分はディレクトリ構造から責務が理解しやすいですが、フロントエンドの React Component 入れ子を読み解くのが難儀でした。
動作確認は、先のDeveloper Machine Setupを済ませた環境であれば、ルートディレクトリでmake runを実行することで、http://localhost:8065に Mattermost が立ち上がるので、そちらで実機確認が出来ます。
また、Pull Request を作成する前にmake test、make check-styleでエラーがないか確認しておきます。(私の MacBookAir 2011 モデルでテスト完了まで 10 分程度かかるのが難点・・)
Pull Request のテンプレートは下記のようになっているので指示通りに書き直します。
Please make sure you've read the [pull request](http://docs.mattermost.com/developer/contribution-guide.html#preparing-a-pull-request) section of our [code contribution guidelines](http://docs.mattermost.com/developer/contribution-guide.html).
When filling in a section please remove the help text and the above text.
#### Summary
[A brief description of what this pull request does.]
#### Ticket Link
[Please link the GitHub issue or Jira ticket this PR addresses.]
#### Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]
- [ ] Added or updated unit tests (required for all new features)
- [ ] Added API documentation (required for all new APIs)
- [ ] All new/modified APIs include changes to the drivers
- [ ] Has enterprise changes (please link)
- [ ] Has UI changes
- [ ] Includes text changes and localization file ([.../i18n/en.json](https://github.com/mattermost/platform/blob/master/i18n/en.json) and [.../webapp/i18n/en.json](https://github.com/mattermost/platform/tree/master/webapp/i18n/en.json)) updates
- [ ] Touches critical sections of the codebase (auth, upgrade, etc.)
この辺りの詳細についてはWorkflowに記述があります。
レビュー
Pull Request を作成後、merge されるためには PM によるレビューと二人以上のの Developer によるレビューを通す必要があります。
PullRequest のレビューステータスは Github 上のラベル1: PM Review、2: PM Reviewなどで表現されています。
また、Setup Test Serverのラベルが貼られると、自動で Pull Request のコードを含んだ Mattermost を立ち上げ、その環境の URL を Pull Request にコメントしてくれる機能があるようです。
これらラベルの操作はコアチームしか操作できません。
レビュー完了までに Conflict が発生すると rebase を求められるので、対応します。
私はこちらのエントリを参考にしながら対応しています。
上記が Code Contribution の流れです。
所感
今回、大きめと思われるオープンソースへのコントリビューションを体験してみましたが、基本的には一般的に良いと言われているプラクティスをしっかり遂行しているという感じで、大きな驚きはありませんでした。
ツールを選べば社内でも遂行できますし、実際に社内でも Web ベースのレビューツールやチャット、Jenkins を利用した CI なども行っていたこともあるため、キーワードだけ見れば同じ開発スタイルを遂行できると思います。
ただ、開発に参加するときは事務作業など考えず、コードだけをに集中できるため気が楽でした。社内との一番の違いはそこかと思います。
また、Mattermost チームはコントリビューターに対してとても親切だと感じました。PullRequest に対する対応も(リリース前後でなければ)基本的には早いですし、「Issue 対応したいんだけど、どこから手をつけたらいい？」というような初歩的な質問にも丁寧に回答してくれます。
きちんと組織立った OSS である Mattermost に参加できたことは、OSS に参加する上での不安や躊躇いを払拭する意味で有意義だったと感じます。
おわりに
二日目の高橋さんのエントリにもあったように
自分たちの体験こそが知見ノウハウであり、お客様のビジネスをよりよくするための糧になると私は考えています。（個人の見解です）
ということだと思っています。
また、こちらの前半部分については個人的にとても同意できます。
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">「OSSはコストで採用するのではない。自立>社員の成長>事業の成長につながるものだ。」
わかる。「責任取りたくないから ORACLE」ってシステムが近所にいくつかあるけど、そういうベンダーが作ったシステムは DB 以外もメタクソ。エンドユーザが苦労している。 <a href="https://twitter.com/hashtag/elasticon?src=hash">#elasticon</a></p>— Toshihiko Nozaki (@bukaz54) <a href="https://twitter.com/bukaz54/status/809266226337746944">2016年12月15日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
OSS を選択・OSS に参加するかどうかは個人個人考え方は違うでしょうが、他の組織の開発にも気軽に参加出来る時代なので、いろいろ見て回っていきたいです。
Discussion