個人のアプリ開発は楽しいです。けど時々寂しいです。 例えば深夜にアイコン作ってる時とか。 「いつもはデザイナーさんに助けられてるけど自分でやらないとなぁ…」とか考えて、無性に寂しくなったりします。ちょっと前からこの寂しさを何とかしたいなぁと思っていました。 で、今は Slackにhubotを住ませて1人じゃない感を演出することである程度解決しているので、どんな雰囲気で開発しているかまとめておこうと思います。 先に言っておくと、あくまで自分はこうやってるよという話なので 趣味がかなり入っています。以後その点だけ注意をお願いします。 統一された世界観を作る プロジェクトごとにSlackのチャネルを作ってそこに全て集約しています。GitHubのアクティビティ通知、CI結果通知、メール問い合わせ通知などですね。 ここで自分が大事にしてるのは、 統一された世界観を作るというところです。 例えば この
この記事は Slack Advent Calendar 2014 - Qiita の 11 日目の記事です。 Slack のようなチャットツールを導入したら Bot を運用するのが人間の性なので、皆さんのチャンネルでも Bot がワイワイ活気付いてる姿が見られるかと思います。 Slack Advent Calendar 2014 - Qiita を眺めていても、Bot の話がいくつかあるようですね。僕が属している会社の Slack チームでも、jewelpet という役に立たない Bot がいます。 今日は Slack で動いている役に立たない Bot の機能紹介と、それを運用して得た役に立たない知見を紹介します。 機能紹介 社内向けなので身内ネタも多い。 jpi hubot image me のエイリアスです。hear を使って jpi という文字列に反応するようにしています。jewel
2014-10-24 relux の Loco Partners さん主催で行われた Slack x Hubot 勉強会で発表した資料です。 Kaizen Platform での Hubot 活用事例 という表題ですが、終盤は会社の活用事例ではなく、個人の趣味の発表です。 スライド内の参照先 roadworker ChatOpsでOSのセキュリティアップデートを自動化出来るようにした - Glide Note hubot-cloudfront Hubot を使って CloudFront の Distribution 一覧・Invalidation 作成を行う hubot-cloudfront hubot-jira-lotto Hubot JIRA おみくじで担当者の選定をランダムに行う hubot-irkit スライド内の動画 Raspberry PI と Hubot で観葉植物の水やりを
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
2017年に新たに書き直したのでこちらも参考にしてください [[2017年版]HubotをSlackで利用 ローカル環境構築、デバッグ、およびHerokuへのデプロイ方法] (http://qiita.com/kon_yu/items/57fb169cb871a009393b) ブログより転載 http://konyu.hatenablog.com/entry/2014/05/13/214812 hubotとは GitHub社が開発しMITライセンスで公開しているNode.jsでbotを作り動かすためのフレームワークです。 Hubotの大きな特徴に，様々なチャットツールに対応している点があります。たとえば，先ほど取り上げたikachanは，IRC用のbotを作るためのフレームワークであり，Twitterのbotを作る目的には使えません。一方でtwittbotはTwitter専用であり，IR
近年、ソフトウェア開発を取り巻く環境が急激に変化してきています。ネットワークの整備や、コミュニケーションツールの進化に伴い、リモートワークやインターネット上での協業も盛んに行われるようになってきました。チームメンバー全員の住んでいる国が違う、といったこともあるかもしれません。 しかし物理的に離れた環境で働くと、今まで対面で行っていたコミュニケーションを別の手段で代替しなければなりません。SkypeやGoogleハングアウトなどのビデオ通話、HipChatやSlackなどのチャットアプリを利用することで仕事上必要なコミュニケーションは取れるようになりますが、ソフトウェア開発に関わる状況確認は別のツールを使う必要があります。 特にオペレーションは、いつ、誰が、どのような対応をしたか把握していたいですよね。 このような課題を解決する一つのスタイルとして、「ChatOps」があります。ChatOp
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（前編）～DevOps Day Tokyo 2013 世界中でDevOpsのイベントとして行われている「DevOps Days」の東京版「DevOps Day Tokyo 2013」が9月28日に開催、海外から来日した多くのゲストスピーカーによるセッションが行われました。 GitHubのJohn Britton氏は「Ops for Everyone」（みんなの運用）という題で、GitHub社内で開発から運用までをデベロッパー自身が行うためのツール、BoxenとHubotの紹介と社内の利用例を解説しています。 Ops for Everyone John Britton氏。 GitHubでエンジニアと教育の橋渡しをしています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
