traQを直すまで

はじめに

どうも皆さん、ご無沙汰しております。22Bのノクナートンです。どうやら、このブログ記事が、新歓ブログリレー期間中７本目の記事になるらしいです。文字数にすると18000字あまりになるらしくて、もしこれを卒業まで続けたら文庫本一冊くらいにはなりそうな勢いです。まあ、新歓ブログリレーではない記事も二本ほど出しているので、新歓ブログリレーとして出したのはたったの五本程度ということになります。

さて、なんでこんな誰も興味なない話をつらつらと書いて文字数をかさ増ししているかと言いますと、昨日までこの記事を出さなきゃいけないことをすっかり忘れていたわけです。昨日、いきなり明日にブログ記事書いてね、ってBOTから通知が来て、やっべーって汗ダラダラ流していたわけです。それが昨日の出来事です。
じゃあなんでこの文章を今日の、しかも午後に書いているのかというと、昨日は忘れてた、やっべーとだけ言って、そのままゲームしていたらいつの間にか１２時を回っていたわけです。そんな不可解な現象起こり得るのか？と不思議に思う方々もいらっしゃるでしょうが、私の観測する限り、traP内ではよく起こっているような気がします。
そんなtraP内での時空間の歪みに巻き込まれてしまい、気が付いたらいつの間にか当日の１５時です。授業中にパソコンカタカタさせて、授業に一切関係のないこのブログを慌てて書いています。

まあ要するに何が言いたいのかというと、今日のブログ記事なんか内容薄くなりそうだけど許してくださいということです。大体昨日の俺が悪いので、今の俺は悪くないです。

本題

さて、実は未だにこの記事が何の記事なのか説明していないことに気がついたので、簡単に説明させていただくと、traQ(を含むtraPで作られているサービス)がどのように改善されていくかを簡単に説明していこうという記事です。
この記事を読んで、普段SysAd班の人間がどんなことやってるのか雰囲気だけでも掴んでいただけると嬉しいです。

本当は、実際に何かの不具合を実際に修正する流れを通して見せられれば良かったのですが、先ほども言った通りそんな時間は何者かの指示で記録から抹消されてしまったのでいろんなところから良さげなものを引っ張ってくる方式にしようと思います。

1. 不具合を見つける

当然、不具合を知らなければ直すことなど出来っこないので、不具合を知る必要があります。

自分が普段traQなどのサービスを触ってみて、ここが不便だな、とかここおかしくない？みたいな部分を見つけることもありますし、他人の愚痴や何気ない投稿で気づくこともあります。
また、#tram/SysAd/feedbackというチャンネルには部員がサービスのバグや不満点を自由に書き込むことができ、ここの投稿で知ることも多いです。

2. Issueを建てる

さて、ここで知った問題点などで、直すべきである、または直すかどうかの議論が必要である、と判断したものはGitHub(簡単に言うとプログラムを管理するサイト)上でIssueというものを建てます。こうすることにより、「今こんな問題点があるよ」というのが開発メンバーで共有されます。

ここで直すかどうかやどのように直すかの議論が必要なものは議論が行われます。

3. 直す

Issueをたてて、どういうふうに直すか決まったら、実際にプログラムを書き換えていきます。
どこで問題が起こっているかを頑張って見つけ出し、よくわかんない動作をするプログラム(大体の場合自分が悪い)に悩まされながらもどうにかこうにかちゃんと動くようにします。

ここでの作業はできるだけ「綺麗に」書くとかブランチを分けるとかいろいろ気をつけることはありますが、時間がないので割愛します。以下の工程でも同様です。

4. Pull requestを出す

自分の中で、よーし直ったぞとなったら、GitHub上でPull request(以後プルリクと略します)をだします。これは要するに「今のプログラムよりこっちの方が良いからこっちに変えない?」という提案を出すっていう意味だと思ってください。これをすることで、自分がどんなプログラムを書いたかが開発メンバーに伝わります。

5. レビューを受ける

プルリクを出して、他のメンパーに確認してーと伝えると、誰かが暇な時に自分が書いたプログラムを確認してくれます。ここで確認者は、ちゃんと想定通り動くか、新しいバグができてないか、読みやすいプログラムが書けているかといったことをチェックします。

ここで、確認者様のお眼鏡に敵わないとここおかしいよとか、ここ直してとか突っ込みが飛んできます。相手の方に理があると思ったら、4に戻り、頑張って修正します。そして、「これで文句ねーだろ！！」と修正したことを伝えます。

6. マージする

こういったやり取りを何度も繰り返して、ついに確認者も文句のつけようがなくなったら「今のプログラムをこっちに書き換えていいよ」という承認をしてくれます。この承認がついたらうっきうきしながら書き換えます。この作業をマージといいます。これを行うことで不具合は直されたとみなされます。一番楽しい作業ですね。

7. リリースする

さて、マージしたことで不具合の修正は終わりましたが、実はユーザーが使っているものはまだ直っていません。いくつか不具合の修正が完了したらそのプログラムをユーザーが使っているサービスに適応させます。これをリリースとかデプロイとか言います。本当は違うものを指しますがまあそんなに深く気にしなくても大丈夫です。
とにかく、これをすることでユーザーは不具合の修正されたサービスが使えるようになります。
これで一区切りで、ここまでの流れを繰り返すことで継続的な機能改善を実現しています。

#team/SysAd/announceでリリースの報告も行なっていますのでtraPに入部された方は興味があったら見てみてください。

おわりに

ここまで読んでいただいてありがとうございます。SysAd班員が普段どんな感じのことしてるのかなんとなーくでも理解していただけると嬉しいです。
traPのSysAd班では実際に100人単位のユーザーに触っていただけるサービスの作成、運用に係わることができます。興味のある方の入班をお待ちしております。