転職先が決まり最終出社日を終え、絶賛ふわふわ時間（有給消化）な今日この頃。
いわゆる退職エントリーみたいなものを書くようなガラではないけれど、 自分なりにやってきたことをまとめたいと思う。
△ Mojolicious::Lite化とTwitterBootstrap、AngularJSの導入による管理画面の近代化
ガラケーの時代からのサービスということで、管理機能の多くがレガシーなPerlのCGIで作成されていた。
これがものによって書き方もバラバラで非常にメンテナンス性が悪いということで、 Mojolicious::Liteを使ったものに徐々に置き換えていった。
で、CGIからスムーズに移行できたし、個別にはコードの見通しが良くなったんだけど・・・
僕の見込みが甘かったところで、作るべき画面が増えてくるとオレオレフレームワーク化してって新たな負債と化していってしまったようにも思う。
始めからLiteじゃない方で、拡張を見越して作っていくのが正解だった。
見栄えに関してはTwitterBootstrapを導入した。
統一感あるUIというのは操作ミスを減らす上でも有効で、 実際に使用するスタッフにも概ね好評だった。
一方でAngularJSとは必ずしも相性が良いとはいえない部分もあり、 今からだったらもっと別の選択肢もあったかなと思うところ。
個人的にはGoogle推しなんでMaterial Design Liteを使いたいけど、世間的には評判どうなんだろ？
流行りものということもあってAngularJSにも手を出してみたのだが、 データバインディングは管理機能をサクッと作る上では非常に有効だった。
（本格的にSPAみたいにして作ろうとおもうと大変なんだろうけど、部品を部分的にAjax化するために使う分には良かった。）
ただ、フロントいじりが本業ではないメンバーにとってはどうもとっつきにくいらしく、 今ひとつ普及できていないというのが本音のところ。
こちらも負債化していっている感じは否めない。
これが主戦場たるコンテンツの側であれば「新しい技術にも適応していきましょう」といえるところだけど、 誰かが専業で常に工数をかけられるわけでもない部分については、 どこまで「新しい技術」を取り入れるのが適切なのかちゃんと考えなくちゃいけない。
（個人的にはそういう社内ツールに専業でだれかつけても良いとは思ってるけど）
○ SVNからGit（GitLab）への移行
昔ながらのSVNによるバージョン管理を行っていたのだが、 いろいろと「開発しにくさ」があったため、サーバ移設を切っ掛けにGitへと移行することにした。
このへんを参考に↓
諸々の都合で「エイヤッ」と一気に切り替えることが出来なかったのだが、 cronで定期的にSVN側の最新を取り込むような形とすることでぬるっと導入。
開発メンバーがGit慣れしておらず不安もあったが、思いの外混乱も無く移行できた。
当初は分かりやすさを重視してメンバー個人ごとにブランチを切るという運用を行っていたが、 慣れてきたことのでissueベースでブランチを切る形にもっていけそう。
実際にリリースするブランチへマージする際は必ず他のメンバーに依頼することを義務付けたことにより、 半ば強制的にでも他人の書いたコードを読むタイミングができたのは良かったと思う。
また、ウェブのフロントエンドがあることによって、チャットでのコミュニケーションの際に問題箇所を共有しやすくなった。
タイミングが良かったのが、GitLabにDockerのRegistryのフロントエンド機能が組み込まれたこと。
後述するようにDockerを使った運用へと切り替えたのだが、 GitLab-Ciも併せて導入したことで、コードからイメージまで同じシステム上で一貫して管理できるのはわかりやすくて良い。
○ Docker化による環境間の差異の改善
過去の色々の経緯により、各環境ごとに改善しがたいレベルで差異があるという問題があった。
コードはサーバによってベタに書き換えられてる部分はあるし、 ランタイムやモジュールのバージョンも揃ってない。
下手すると環境変数やユーザアカウントも違うし、パスも違ったりする。
しかもどれが「正解」か分からない。
そんな状況を改善する方法として、Docker化を行うことにした。
正直なところを言えばいささか勇み足だった感じもあって、 いざ本番導入となるとデプロイやネットワークまわりで引っ掛かりどころもあったし、 メンバーの習熟度が十分かといわれるとちょっと不安もある。
とはいえ実運用上の操作は全てCIとRundeckのタスクとして押し込めることにより、 なんとか安定運用できている。
デプロイは当時は色々煩雑だったのでAnsibleを使用する形で妥協したのだが、 今だったら本体に組み込まれたSwarmを使う形が良いのかもしれない。
○ Rundeckによるcronの置き換え
運用期間が長いサービスということもあって、バッチ処理まわりにも課題があった。
順序依存の処理はcronの実行タイミング頼りで後追いするのが大変だったし、 エラーも埋もれて発見までに時間がかかる。
メンテナンス明けなどのタスクの手動実行も手探りな感じで、 今にして思えばかなりひどい運用になっていたように思う。
そんなわけで何がしかのスケジューラを導入しようとして検討したところ、 他にもイケてる感じのプロダクトはあったものの個別に課題があり、 結果としてRundeckを選択した。（この辺の話もいつか書きたいかも）
課題だった順序依存の処理はひとまとまりのジョブとしてくくることができてわかりやすくなった。
ログについては一覧表示や絞込表示が可能だし、メール等による通知もできる。
（チャットツールとの接続までいけなかったのはちょっと心残り）
また、これは導入後に思いつきで入れたのだが、 サーバ上での定形のコマンド実行やバッチ処理をジョブとしてスケジュールを設定せずにおいておくことで、 本番サーバにsshでログインせずにデプロイ等の通常運用する状態にできたのは大きな収穫だったと思う。
○ Re:Dash導入によるデータ可視化の効率UP
Rebuildで存在を知り、半ば置き土産のような形で導入してきたツール。
↑の記事でも述べているように、スタッフの要望に迅速に対応できるし、運用面でもメリットは大きいと思う。
あと、隠れたメリットとして、スタッフからの割に合わない要望を「いやぁ、ツールが対応してなくて」で切り抜けられるのが良い。
× テスト文化の定着はできなかった
一般論として「コードのテストは記述していった方が良い」という価値観自体は共有できてはいたが、 それをいざ実際の業務の中に組み込もうと思うと、
- 基礎となる部分がそもそもテストしにくい構造となっている
- 企画がリリース直前までゆらぎやすい
等々の課題があり、ついぞ定着させることができなかった。
- 作者: tokuhirom
- 発売日: 2012/11/09
- メディア: Kindle版
- クリック: 114回
- この商品を含むブログを見る
かくいう僕も偉そうなことは言えなくて、社内ツールだしと横着したところもあるし、 そこまで力を入れていたわけでもない。
この辺はCIに組み込んで自動化して「追加の手間」にならないようにしていくような努力をしていかなければいけなかったんだろうなと反省するところ。
× コードレビューの実施
テストと同様に、やったら良いなと思いつつも、日々の業務の中でまとまった時間を確保しにくく有耶無耶になってしまった。
- 作者: 織田巖
- 出版社/メーカー: ソフトリサーチセンター
- 発売日: 2006/07
- メディア: 単行本
- 購入: 4人 クリック: 125回
- この商品を含むブログ (4件) を見る
リリーススケジュールがまばらでメンバーが揃う時間を取りにくいとか 人数的にどうしても専門みたいな状態になって他人の担当箇所が良くわからないとか色々問題はあったんだけど、 やっぱりこういうのはある程度立場ある人がトップダウンでやらないといけないんだろうなと思う。
この辺はGitlabのマージリクエストを使う形に変えたことで半強制的に他人のコードを読むことになったので、 多少は改善されていくのではないかと思うけど。
△ ChatOpsの導入
半ば遊びみたいな感じだったけど、Hubotを用いたChatOpsには色々と可能性を感じた。
お決まりのメール通知は埋もれてしまいがちだし、 たとえ便利な画面を作ったって見るべき人が見なければ意味がない。
チャットツールを中心と捉えてそこにあらゆる情報を集めるというのは考えてみればしごく当然なことのように思う。
もし次の職場で機会があれば、このへんに力を入れてみたい。
良くも悪くもあまり人から管理されない文化だったので、振り返ると結構好き勝手やらせてもらえたなという印象。
不満だったこともそれなりにあるけど、ある程度時間に余裕があって勉強できる環境だったので、技術的にはかなり得るものが大きい４年半だったと思う。
ふと思い立って久しぶりに転職会議の前々職のページを眺めていたんだけど、口コミ削除の仕様が色々変わったみたいですな。
昔は削除時に一応「削除して良かですか」メールが来たんだけど、今は特にそういうのも無くスルッと削除されるみたい。
その代わり「19件の投稿が権利者(例：企業など)の申し立てにより全文削除されています。」と表示されて、削除されたコメントも３年以内のなら見られるみたい。
ただ、削除済みコメントはどう見ても１９件以上あって、（多分わざとそうしてるんだとは思うけど）カンスト低いなーと思うところ。
https://jobtalk.jp/company/494
それでも中立性という意味では多少は改善されたと見るべきか。
