この記事は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に参加する上での不安や躊躇いを払拭する意味で有意義だったと感じます。
おわりに
二日目の高橋さんのエントリにもあったように
自分たちの体験こそが知見ノウハウであり、お客様のビジネスをよりよくするための糧になると私は考えています。(個人の見解です) ということだと思っています。
また、こちらの前半部分については個人的にとても同意できます。
「OSSはコストで採用するのではない。自立>社員の成長>事業の成長につながるものだ。」
— Toshihiko Nozaki (@bukaz54) 2016年12月15日
わかる。「責任取りたくないから ORACLE」ってシステムが近所にいくつかあるけど、そういうベンダーが作ったシステムは DB 以外もメタクソ。エンドユーザが苦労している。 #elasticon
OSSを選択・OSSに参加するかどうかは個人個人考え方は違うでしょうが、他の組織の開発にも気軽に参加出来る時代なので、いろいろ見て回っていきたいです。