PHP Conference Japan 2014 https://joind.in/12041
![Webアプリのデプロイ今昔物語](https://cdn-ak-scissors.b.st-hatena.com/image/square/6339d05ec5eb9eafee57cd41b6a1da919ba35d25/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fd39113e033510132ef480af01cce597a%2Fslide_0.jpg%3F3700836)
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
Up until lately I was happy using Capistrano for my deployments. But then I noticed the following: Capistrano was utilizing 70 % of a physical CPU core when deploying on the go. I'm on a dual core system so this impacts my Mac Book Pros overall performance, battery life and it kept me waiting for a long long time. My iPhone was at edge speed so I figured Capistrano spent most of the time waiting f
GitHubは普通の会社とどう違うのか? リリースマネージャーがいない(いる必要がない) 週次のデプロイセットもありません(この週にこれだけの機能をまとめてリリースとかがない) 開発者とデザイナーは、早く提供できるように自分たちでデプロイする(できる)作った人達が自ら確認できて、サクッとデプロイできるのであれば、さっさと作って、ささと出してしまった方が良いに決まっています。これを実現させるために様々な工夫がされているようです。 GitHubの基本的なワークフロー The basic workflow goes like this: Push changes to a branch Wait for the build to pass on our CI server Tell Hubot to deploy it Verify that the changes work and fix a
Twitterは、同社の何千台ものサーバに対してバイナリをデプロイする場合に、ピア・ツー・ピアシステムのBitTorrentを利用したツール「Murder」を用いていると、7月1日の記事「Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)~Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」」で紹介しました。 FacebookでもBitTorrentによる大規模なデプロイが高速に行われていることは、7月16日の記事「Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側」で紹介しました。 どうやら大規模システムにおけるデプロイではBitTorrentの利用が進んでいるようです。 7月15日付けのTwitter Engineering Blogに、Twitterのエンジニア、Larry Gadea氏による「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く