チャット経由でデプロイする - Qiita
最近開発で利用している、デプロイをチャット経由で行うフローについて説明します。 要点 開発者はmasterブランチで開発する 開発者はデプロイしたいときにBotにお願いする Botはmasterブランチからproductionブランチに対してPull Requestをつくる 開発者はPull Requestを確認してmergeする CIはproductionブランチが変更されるとサーバにデプロイする ChatOps masterブランチからproductionブランチにPull Requestを出す作業は面倒なので、チャット経由で行っています。Heroku上で動かしたRubotyにruboty-githubとruboty-aliasというプラグインを入れて、「デプロイしたい」と発言するとPull Requestを作成するように設定しています。チャット経由で物事を行うようにすると、周知や教育
チャットを業務で運用する際の心がけ
エンジニアの職場でチャット（IRC, HipChat, Slack etc.）はごく自然な連絡ツールになっているだろうと想像しますが、僕のように非エンジニア社会で業務にチャットを取り入れようとするとそれなりの抵抗を受けます。 抵抗を示す人がチャットに慣れていない、あまり経験がないという場合もあれば、「どうせこんな感じでしょ」という少ない経験がそのすべてであると思い込んでしまうという人類全般に見られるあるある現象による場合もあるでしょうが、たしかにチャットを使えばすべて上手くいくなどということもなく、その意味でそうした思い込みも一概に間違っているとは言えず、他のさまざまなツールと同様にチャットもまた副作用的な問題を少なからず抱えているとは言えるわけですが、そのような事々もいくつかの点に注意を払っておけば大した問題ではなくなる、というのが僕の考えです。 もしエンジニアの職場でチャットが上手く使
ChatOpsでOSのセキュリティアップデートを自動化出来るようにした - Glide Note
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
