SlackのIncoming/OutgoingなWebhookでChatOpsと言い張るなにかを作った話(計画編)

たまにはエンジニアらしい事したい!

みなさんこんにちは。

ここ最近、「君からビールを取ると泡しか残らない」とシャッチョサンから言われたんですけども、これは褒め言葉として受け取っておけばいいんでしょうかね?

(゜Д゜)

まあ、普段ビールばっか飲んでいるところしか見せられていないので、たまにはエンジニアらしいことをアレしておこうかなとか思ったりする今日この頃です。

……誰向けのアピールだよって話ですが。

_ノ乙(、ン、)_

ChatOpsにチャレンジ!

じゃあ……ってことで、いつぞやにどこかで話題になってたような気がしないわけでもないかもしれない「ChatOps」ってやつを自社に導入してみることにしませぅ。

まずは計画を立てよう!

漠然と「ChatOps導入するぞ!」っていっても、誰も使わないか誰かの手間を増やすだけのダメダメシステムが出来上がるのが関の山。

なので、ちょっと何をアレするか考えて見ましょう(´・ω・)(・ω・`)ネー

……と、考えて見たところ、社内WebシステムのデプロイをChatOpsで自動化したりしたらいいんじゃね?……って天の声が聞こえてきましたよ。

今までどうだったっけ?

っていうのもですね、今までのデプロイってこんな感じのフローだったんですよね。

  1. Featureブランチを作る
  2. 手元のPCでゴリゴリ開発
  3. テストサーバにPhpStormから転送(ここは自動)
  4. よさげならGitHubにCommit&Push
  5. PR作る
  6. masterブランチにマージする
  7. リリース資材をまとめる
  8. SFTPあたりで本番サーバに転送
  9. SSHでログイン
  10. 転送した資材を展開
  11. 展開した資材を適切な場所に配置
  12. 必要に応じてパーミッションとか調整
  13. ゴミを削除

……うん。文章にするとすげぇ手間(;´Д`)

何が問題なんだっけ?

このフローの何が問題なのか……ってのも考えてみましょうか。

ざっと思いつく範囲だと

  • 手順が複雑
  • サーバへのアクセス権が必要
  • 「リリース資材を作る」という苦行が必要
  • 「分かってる」人しかできない/やりにくい

って感じでしょうかね。

なんていうか、1〜6までは結構スマートなのに、それ以降がものすごくイケてないって感じがします。

どうするか?

要はイケてないところをスマートにすればOKって話なので、「こんな感じにしたいなー」ってのを整理しておきましょう。

イケてないのはリリース周り。ナウい言い方をすれば、デプロイ周りですね。ここをいい感じにしてみましょう。

  1. Featureブランチを作る
  2. 手元のPCでゴリゴリ開発
  3. テストサーバにPhpStormから転送(ここは自動)
  4. よさげならGitHubにCommit&Push
  5. PR作る
  6. masterブランチにマージする
  7. 未知なる力に目覚め、紋章が刻まれし左手に封印された漆黒の龍(ドラゴン)が放つ紅の裁きが大地を焦がす(デプロイ完了)

なんということでしょう……。あれだけ煩雑なデプロイ作業が、こんなにもシンプルに……。

いいですねいいですね。これでいきましょう( ̄ー ̄)

まずは下ごしらえから

とりあえず、自動化するためにはやることをシンプルにしておかないといけません。

もちろん複雑なプロセスを自動化するのも悪くはないですが、それがちゃんと動いているかをテストしたりとかメンドイですしね。KISSの原則ですよ。ええ。

コマンド一発で手動デプローィ

まず、コマンド一発で手動デプロイできるようにしましょう。これは結構簡単な話。

私たちはソースコードをGitHub.comのプライベートリポジトリにホスティングしているので……。

masterブランチ1)じゃなくてもいいんだけど、今回はそういう取り決めを常にリリース可能な状態にしておいて、git pullで最新ソースゲットできるようにしておけばよさげ。

ってことで、まずはリポジトリからgit cloneしてまいりませぅ……って流れになるわけですが、プライベートリポジトリなので、匿名で取ってくることができません!

そんなときは慌てず騒がず、「Deploy keys」を使いましょう。

細かい手順は上記サイトを参照されたし。

簡単に流れを書いておくと……

  1. デプロイの時に使う予定のユーザでSSHなキーペアを作成2)パスワードなしで
  2. GitHubの管理画面から公開鍵を登録
  3. そのキーを使ってgit clone

って感じですね。

ここまでやったら、完成したも同然。ここを自動化すれば終わりですから( ̄ー ̄)

どのタイミングでデプロイする?

よくある構成だと、GitHubにPushしたらCI走ってOKならデプロイ……って感じにするんでしょうけども……。

当社はCIなんて使ってない3)主としてボクのやる気の問題によりし、Pushしたタイミングとデプロイしたいタイミングが違うケースも多々ある……と。

ので、別なきっかけでデプロイプロセスをキックしたいというニーズが。

じゃあってことで、会社で使ってるSlackを使いましょう。適当なチャンネルを作って、そこで魔法の言葉を唱えるとデプロイが始まる……的な。

長くなったので今回はここまで!

ってことで、後はこれを実際に作るだけなわけですが……。

余談が多すぎたせいか、長くなりすぎてしまったのでここまでにしておきましょう!

注訳はこちら   [ + ]

1. じゃなくてもいいんだけど、今回はそういう取り決め
2. パスワードなしで
3. 主としてボクのやる気の問題により
Yuta Hayakawa

Yuta Hayakawaマネージャー

投稿者プロフィール

普段は東京本社で社内システム開発を中心とした本社業務を担当しています。

最近、マネージャー(部長相当)職になりまして、不慣れなアレでアレしている毎日です。

音楽とコンピュータ関連、ゴルハム&ジャンハム関係、ゲーム関係が興味あるポイント。

この著者の最新の記事

関連記事

コメントは利用できません。

募集中!(o゜▽゜)o

エンジャパン
求む、社長!
follow us in feedly

コッチもヨロシク!





最近のネタ!

  1. 2019-1-23

    2019年1月度・第30回 福岡社員総会&懇親会

    今年初の社員総会! 2019年、明けましておめでとうございます。 前回の福岡社員総会をレポートさ…
  2. 2019-1-22

    第17回社員総会&懇親会@Osaka 〜年明け一発目!〜

    2019年1月11日(金)、大阪社員総会&懇親会が開催されました! その様子をお届けします! 社員…
  3. 2019-1-21

    GitHub の Pull Request はマージ方法が 3 パターンあるって知ってました?

    こんにちは、江嵜です。 GitHub の Pull Request つかってますか? みなさん、…
  4. 2019-1-14

    目を酷使するお仕事だから…個人的に使い続けている、目をいたわるアイテム BEST 3

    目を労わってますか? こんにちは、江嵜です。 みなさん、目を労わってますか? 昔は「テレビ見す…
  5. 2019-1-11

    2018年12月度社員総会&懇親会@Tokyo ~たくさんのポーズいただきました!~

    第4期が始まりました! 2018年12月21日(金)に東京オフィスの「12月度 社員総会&…
ページ上部へ戻る