事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
Github社製のBotフレームワークであり、同社の運用の中心的なツールとして使われている「Hubot」をインストールし、独自のスクリプト作成、Herokuへのデプロイまでしてみます。 Hubotとは？ GitHub社が作成したオープンソースのBotフレームワークで、Botとは、自動的に実行、応答するようなプログラムのことを指します。HubotはNode.js、CoffeeScriptで作成されており、 HerokuなどのPaaSへのデプロイも容易 となっています。 Botなので、定期的、または自動的にプログラムを実行したり、問い合わせに応えるような機能を提供します。Hubotに最初から組み込まれているスクリプトでは画像の投稿や、地図の表示、計算などが行えるのですが、自身でスクリプトを追加することも可能です。 例えばGitHub社では、チャットアプリとHubotを繋げ、チャットルームにHu
Hubotを中心としたGitHub社内のワークフローはChatOpsと呼びことになったようだ。 Hubotというチャットルームのボットを利用して、Webサービスの運用にまつわるあれこれ（デプロイ、テスト、負荷グラフ表示、エラーログ監視などなど）を行うGitHubの開発・運用スタイルはもはや有名ですが、GitHubのJesse Newland氏のスライドを見ると、昨年末くらいからこのワークフローをChatOpsと呼ぶようになっているようです。 ChatOps at GitHub // Speaker Deck Puppet at GitHub / ChatOps // Speaker Deck ChatOpsについては、日本語では以下のサイトに簡単にまとまっていました。 GitHubの中の人が使っているHubot、そしてChatOpsってなんだ？～QCon Tokyo 2013レポート |
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
