4/28(金) にDevOps推進協議会 で講演したときの資料です。
一休での開発における改善の取組み /devops-at-ikyu
4/28(金) にDevOps推進協議会 で講演したときの資料です。
『AWAにおけるDevOps』
はじめに AWAでサーバサイドエンジニアをやっている山下といいます。初めてエンジニアブログを書かせていただきます。よろしくお願いします。 簡単に自己紹介をさせていただくと、2011年にSIerからサイバーエージェントに中途入社し、いくつかのコミュニティ系サービスの立ち上げ・運用、インフィード広告配信APIの作成などを経て、2015年4月からAWAチームに参加しました。 今回は、(今さら？な) DevOpsについてです。といってもスムーズな連携をするには といった話ではなく、現在のチームに参加してからというもの、「エンジニア間の役割が変わってきていて、DevOpsって現状にあってないんじゃないか」と感じており、それについてご紹介させていただきます。 AWAとは 定額制音楽配信サービスです。 スマートフォン、PCでアプリを提供しており、他のデバイスにも順次対応をすすめています。2015年のベス
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
JAWS DAYS 2014、Immutable Infrastructure について - naoyaのはてなダイアリー
何もかも投げ棄てて Dark Souls II をやりたい気持ち抑えながら JAWS DAYS 2014 で Immutable Infrastructure について話してきました。以下、資料です。(Embed できないのでリンクです) https://speakerdeck.com/naoya/immutable-infrastructure-number-jawsdays Immutable Infrastructure トラックのトップバッターだったので、そもそも Immutable Infrastructure とは何か、どのような背景でこのような概念が提唱されるに至ったのか、そして現在は。またこれから何が変わるのかみたいな、大枠の話にフォーカスして話しました。会場は Immutable Infrastructure トラックは立ち見が出てるくらい盛況で、やはりこの分野に注目が集
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログ環境とDevOps ~一休.comでの事例~
クックパッドはなぜ開発しやすいのか // Speaker Deck
Webアプリのデプロイ今昔物語