GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば 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 と連携するこ
Windows と Deploy と PowerShell - tech.guitarrapc.cóm
私が PowerShell をやる理由、好きな理由、今自分が 果たす必要があること。それは Windows におけるデプロイであり、私が PowerShell に興味を持っているすべてです。 Linux 大好きです。Deploy や Automation のトレンドは Linux 界隈を見ると楽しいです。 Windows 超好きです。C# 大好きです。クラウド最高です。なので 謎社 の サーバーは Amazon Web Service 上の Windows Server 2012 です。*1 そんなWindows におけるデプロイに PowerShell をどう使って楽にするのかを毎日考えています。 でも、Windows で デプロイ？ どうやるの？ といわれると実例も乏しく手法も普及していない残念な現実。なので、今回はそれを考えて見ます。 目次 目次 Windows での Deploy
1日に175回もGitHubはデプロイしているだとぉ…！？ | Act as Professional
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
いまからPerl/Ruby/Node.jsやるならRackhubを使わない手はない - Cside::Tech
自作Webアプリケーションのデプロイ先として Rackhub というのが新たな定番になると思っているので、このたび Kyoto.pm *1 で布教してきました。スライド： http://speakerdeck.com/u/cside_/p/vpsdotcloudrackhubRackhub： http://rackhub.net/Rackhubとは一言でいうと「環境構築済みのVPS」です。その何が新しいのか、何が嬉しいのか、など詳しいことは資料の方へ盛り込んだので、ぜひお読みいただければと思います。 ここからは参加しての個人的な感想になります。皆それぞれに問題意識を持っていて、それを解決するためにがっつり一人の時間を取るようにしているのだなぁと改めて感じました。僕は週5フルタイムでバイトしていたときは業務終了後や週末はぶっちゃけ結構だらけてしまっていたけど、今日紹介されてたライブラリやサー
5分で分かるデプロイ自動化への道
12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは本番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする本番環境に配置する際に、アプリケーションの各所を書き換えなけれ
Ruby を利用した大規模ウェブサービスの開発・運用 - RubyKaigi 2011 発表資料 - クックパッド開発者ブログ
技術部開発基盤グループの id:secondlife こと @hotchpotch こと舘野です。 先日の RubyKaigi 2011 で、「Ruby を利用した大規模ウェブサービスの開発・運用」という内容で発表させていただきました。 前半はクックパッドのサーバアーキテクチャ、各種サーバのアプリがどんな風に動いているのかの紹介を、後半では「開発」→「デプロイ」→「フィードバック」→「開発」…という、サービス開発で行われているサイクルを30人以上エンジニアが居るクックパッドでどう高速に回し続けているかのお話しです。 Ruby を利用した大規模ウェブサービスの開発・運用 [slideshare id=8630511&w=425&h=355&sc=no] View more presentations from hotchpotch 当日のRubyKaigi 2011 での発表の動画は、以下を
TwitterがBitTorrentで高速にデプロイしている仕組みについて
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氏による「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
