Windows Azure Web SiteでのGitサポートがpullではなくpushになっている理由について少し考えてみた

Azure Web SiteのGitサポートでサイトへのコンテンツの送り方がAzureがpullするのではなくて、Azureにpushだとわかった時にはちょっと残念だったんですよ。

残念だった理由は世界標準のGitHubにあるコンテンツをAzureがpullして来ちゃうと超クールじゃないっすかーって感じだったんですけど、ちょっと考えてみれば一般的にはこれだとよろしくないのかもねと。

そもそも全員がGitHubやオンラインのgitリポジトリ使っているわけではないし、GitHubを使っているにしてもやその使い方に依存してしまうよね。

そこで、一般的な継続的なインテグレーション(CI)やそれを進めた継続的デリバリーのシナリオを考えると以下の図のようになると思うんだ。

プログラマとかデザイナーがピアレビュー等終わったソースコードやコンテンツを、リリース用のリポジトリにpushして、CIもしくはビルドツールがリリース用のリポジトリにあるHEADをローカルにfetchして、ビルド、テスト、計測を全部通った段階で、Azure Web Siteのリポジトリにpushしてデリバリー完了という手順ですね。テストやビルドが通らなければそこで止めないといけないし。個人のBlogサイトでも無い限り、そりゃテストいるよね、統計的なデータの計測もいるよね、それら通ってないもののデリバリーとか無理っすよね話ですな。

ということで、ちょっと考えれば当たり前のことなんだけどAzure We Siteのgitサポートは自分がpullするんじゃなくて、push待ちの方が合理的なんだと言うことです。

 

「Windows Azure Web SiteでのGitサポートがpullではなくpushになっている理由について少し考えてみた」への1件のフィードバック

  1. ピンバック: .NET Clips

コメントを残す