インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
Martin Fowler's Bliki in Japanese - 意味的衝突
@@ -0,0 +1,70 @@ +http://martinfowler.com/bliki/SemanticConflict.html + +私が同僚と[[FeatureBranch]](訳注：機能ブランチ)について話しているのを聴いた人は、我々があのパターンの大ファンではないということを知っている。 +我々の反論の重要な点は、ブランチ作成は簡単だが、マージは大変だという見解にある。 +時折耳にする議論としては、モダンな[[VersionControlTools]]があれば、 +マージは十分に簡単になるので、機能ブランチには行う価値があるというものがある。 + +確かに、モダンなツールは、私が若い頃よりもマージに関してずっといい仕事をしてくれる。その威力のいい例の一つが、リネームしてもマージしてくれるというものである。 +私が{{code('lorem.rb')}}の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
