ソース管理 (Azure を使用したReal-World Cloud Apps の構築)

  • [アーティクル]

作成者 : Rick Anderson、 Tom Dykstra

修正プロジェクトのダウンロード または 電子書籍のダウンロード

Azure 電子書籍 を使用した Real World Cloud Apps の構築 は、Scott Guthrie によって開発されたプレゼンテーションに基づいています。 クラウド向けの Web アプリの開発を成功させるために役立つ 13 のパターンとプラクティスについて説明します。 電子書籍の詳細については、 最初の章を参照してください。

ソース管理は、チーム環境だけでなく、すべてのクラウド開発プロジェクトに不可欠です。 元に戻す関数や自動バックアップを使用せずにソース コードやWordドキュメントを編集することは考えられません。また、ソース管理では、問題が発生したときにさらに時間を節約できるプロジェクト レベルでこれらの関数が提供されます。 クラウド ソース管理サービスでは、複雑なセットアップについて心配する必要がなくなり、最大 5 人のユーザー Azure Reposソース管理を無料で使用できます。

この章の最初の部分では、留意すべき 3 つの主要なベスト プラクティスについて説明します。

この章の残りの部分では、Visual Studio、Azure、Azure Reposでのこれらのパターンの実装例をいくつか示します。

オートメーション スクリプトをソース コードとして扱う

クラウド プロジェクトに取り組んでいるときは、頻繁に変更を行い、顧客から報告された問題に迅速に対応できるようにする必要があります。 迅速に対応するには、「すべてを自動化する」の章で説明されているように、 自動化 スクリプトを使用する必要があります。 環境の作成、デプロイ、スケーリングなどに使用するすべてのスクリプトは、アプリケーションのソース コードと同期している必要があります。

スクリプトをコードと同期するには、ソース管理システムに保存します。 その後、変更をロールバックしたり、開発コードとは異なる運用コードを簡単に修正したりする必要がある場合は、変更された設定や必要なバージョンのコピーを持つチーム メンバーを追跡するために時間を無駄にする必要はありません。 必要なスクリプトは、必要なコード ベースと同期しており、すべてのチーム メンバーが同じスクリプトを使用していることを確認できます。 その後、運用環境に対するホットフィックスのテストとデプロイを自動化する必要がある場合でも、更新する必要があるコードに適したスクリプトが用意されています。

シークレットにチェックしない

通常、ソース コード リポジトリは、パスワードなどの機密データに対して適切にセキュリティで保護された場所であるため、多くのユーザーがアクセスできます。 スクリプトがパスワードなどのシークレットに依存している場合は、ソース コードに保存されないようにこれらの設定をパラメーター化し、シークレットを別の場所に保存します。

たとえば、Azure では、発行プロファイルの作成を自動化するために、発行設定を含むファイルをダウンロードできます。 これらのファイルには、Azure サービスの管理が許可されているユーザー名とパスワードが含まれます。 このメソッドを使用して発行プロファイルを作成し、これらのファイルをソース管理にチェックした場合、リポジトリにアクセスできるユーザーは誰でもそれらのユーザー名とパスワードを確認できます。 パスワードは暗号化されており、既定ではソース管理に含まれていない .pubxml.user ファイル内にあるため、発行プロファイル自体に安全に保存できます。

DevOps ワークフローを容易にするためにソース ブランチを構築する

リポジトリにブランチを実装する方法は、新機能の開発と運用環境での問題の修正の両方の機能に影響します。 中規模のチームの多くが使用するパターンを次に示します。

ソース ブランチの構造

メイン ブランチは、常に運用環境のコードと一致します。 メインの下の分岐は、開発ライフ サイクルのさまざまな段階に対応します。 開発ブランチでは、新機能を実装します。 小規模なチームの場合は、メインと開発を行うだけですが、多くの場合、開発とメインの間にステージング ブランチがあることをお勧めします。 更新プログラムを運用環境に移行する前に、最終的な統合テストにステージングを使用できます。

大きなチームの場合、新機能ごとに別々のブランチが存在する場合があります。小規模なチームの場合は、すべてのユーザーが開発ブランチにチェックインする場合があります。

機能ごとにブランチがある場合、機能 A の準備ができたら、ソース コードの変更を開発ブランチにマージし、他の機能ブランチにマージします。 このソース コードのマージ プロセスは時間がかかる場合があり、機能を分離したまま作業を回避するために、一部のチームは 機能トグル ( 機能フラグとも呼ばれます) と呼ばれる代替機能を実装します。 つまり、すべての機能のすべてのコードは同じブランチにありますが、コードでスイッチを使用して各機能を有効または無効にします。 たとえば、フィーチャー A が Fix It アプリ タスクの新しいフィールドであり、Feature B によってキャッシュ機能が追加されたとします。 両方の機能のコードは開発ブランチに含めることができますが、アプリは変数が true に設定されている場合にのみ新しいフィールドを表示し、別の変数が true に設定されている場合にのみキャッシュを使用します。 機能 A を昇格する準備ができていないが、機能 B の準備ができた場合は、機能 A スイッチをオフにし、機能 B をオンにして、すべてのコードを運用環境に昇格させることができます。 その後、フィーチャー A を終了し、後で昇格させることができます。すべてソース コードをマージする必要はありません。

機能にブランチやトグルを使用するかどうかに関係なく、このような分岐構造を使用すると、アジャイルで反復可能な方法でコードを開発から運用環境にフローできます。

この構造により、顧客からのフィードバックに迅速に対応することもできます。 運用環境を迅速に修正する必要がある場合は、アジャイルな方法で効率的に行うこともできます。 メインまたはステージングからブランチを作成し、準備ができたら、ブランチをメインにマージし、開発ブランチと機能ブランチにマージできます。

修正プログラム ブランチ

このような分岐構造を運用ブランチと開発ブランチの分離と共に使用しないと、運用上の問題により、運用環境の修正プログラムと共に新しい機能コードを昇格する必要があるという立場に置かれる可能性があります。 新しい機能コードが完全にテストされておらず、運用の準備ができていない可能性があり、準備ができていない変更をバックアップするために多くの作業を行う必要がある場合があります。 または、変更をテストして展開する準備を整えるために、修正を遅らせる必要がある場合があります。

次に、これら 3 つのパターンを Visual Studio、Azure、Azure Reposで実装する方法の例を示します。 これらは、詳細な手順ではなく、例です。必要なすべてのコンテキストを提供する詳細な手順については、章の最後にある 「リソース 」セクションを参照してください。

Visual Studio でソース管理にスクリプトを追加する

Visual Studio のソース管理にスクリプトを追加するには、Visual Studio ソリューション フォルダーにスクリプトを含めます (プロジェクトがソース管理にある場合)。 これを行う 1 つの方法を次に示します。

ソリューション フォルダー ( .sln ファイルがあるのと同じフォルダー) にスクリプトのフォルダーを作成します。

Automation フォルダー

スクリプト ファイルを フォルダーにコピーします。

Automation フォルダーの内容

Visual Studio で、ソリューション フォルダーをプロジェクトに追加します。

[新しいソリューション フォルダー] メニューの選択

次に、スクリプト ファイルをソリューション フォルダーに追加します。

[既存の項目の追加] メニューの選択

[既存項目の追加] ダイアログ ボックス

スクリプト ファイルがプロジェクトに含まれるようになり、ソース管理は対応するソース コードの変更と共にバージョンの変更を追跡しています。

Azure に機密データを格納する

Azure Web サイトでアプリケーションを実行する場合、ソース管理に資格情報を格納しないようにする 1 つの方法は、代わりに Azure に格納することです。

たとえば、Fix It アプリケーションは、運用環境でパスワードを持つ 2 つの接続文字列と、Azure ストレージ アカウントへのアクセスを許可するキーを持つ 2 つの接続文字列をWeb.config ファイルに格納します。

<connectionStrings>
  <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItMembership.mdf;Initial Catalog=MyFixItMembership;Integrated Security=True" providerName="System.Data.SqlClient" />
  <add name="appdb" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItTasks.mdf;Initial Catalog=aspnet-MyFixItTasks;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>
<appSettings>
  <add key="webpages:Version" value="3.0.0.0" />
  <add key="webpages:Enabled" value="false" />
  <add key="ClientValidationEnabled" value="true" />
  <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  <add key="StorageAccountName" value="fixitdemostorage" />
  <add key="StorageAccountAccessKey" value="[accesskeyvalue]" />
</appSettings>

これらの設定の実際の運用値を Web.config ファイルに配置した場合、またはデプロイ時に挿入する Web.config 変換を構成するようにWeb.Release.configファイルに配置した場合は、ソース リポジトリに格納されます。 実稼働発行プロファイルにデータベース接続文字列を入力すると、パスワードは .pubxml ファイルに格納されます。 ( .pubxml ファイルをソース管理から除外できますが、他のすべての展開設定を共有する利点は失われます)。

Azure では、Web.config ファイルの appSettings セクションと接続文字列セクションの代替手段が提供されます。 Azure 管理ポータルの Web サイトの [ 構成 ] タブの関連部分を次に示します。

ポータルでの appSettings と connectionStrings

この Web サイトにプロジェクトをデプロイし、アプリケーションを実行すると、Azure に格納されている値はすべて、Web.config ファイル内の値をオーバーライドします。

これらの値は、管理ポータルまたはスクリプトを使用して Azure で設定できます。 「すべて自動化」の章で確認した環境作成自動化スクリプトは、Azure SQL Database を作成し、ストレージとSQL Database接続文字列を取得し、これらのシークレットを Web サイトの設定に格納します。

# Configure app settings for storage account and New Relic
$appSettings = @{ `
    "StorageAccountName" = $storageAccountName; `
    "StorageAccountAccessKey" = $storage.AccessKey; `
    "COR_ENABLE_PROFILING" = "1"; `
    "COR_PROFILER" = "{71DA0A04-7777-4EC6-9643-7D28B46A8A41}"; `
    "COR_PROFILER_PATH" = "C:\Home\site\wwwroot\newrelic\NewRelic.Profiler.dll"; `
    "NEWRELIC_HOME" = "C:\Home\site\wwwroot\newrelic" `
}

# Configure connection strings for appdb and ASP.NET member db
$connectionStrings = ( `
    @{Name = $sqlAppDatabaseName; Type = "SQLAzure"; ConnectionString = $sql.AppDatabase.ConnectionString}, `
    @{Name = "DefaultConnection"; Type = "SQLAzure"; ConnectionString = $sql.MemberDatabase.ConnectionString}
)

実際の値がソース リポジトリに永続化されないように、スクリプトがパラメーター化されていることに注意してください。

開発環境でローカルに実行すると、アプリはローカル Web.config ファイルを読み取り、接続文字列は Web プロジェクトの App_Data フォルダーにある LocalDB SQL Server データベースを指します。 Azure でアプリを実行し、アプリがWeb.config ファイルからこれらの値を読み取ろうとすると、元に戻って使用されるのは Web サイトに格納されている値であり、実際には Web.config ファイルに格納されている値ではありません。

Visual Studio と Azure DevOps で Git を使用する

任意のソース管理環境を使用して、前に示した DevOps 分岐構造を実装できます。 分散チームの場合、 分散バージョン管理システム (DVCS) が最適に機能する場合があります。他のチームの場合は、 集中型システム の方が適切に機能する可能性があります。

Git は、一般的な分散バージョン管理システムです。 ソース管理に Git を使用すると、リポジトリの完全なコピーと、ローカル コンピューター上のすべての履歴が含まれます。 多くの人は、ネットワークに接続していないときに作業を続ける方が簡単なので、コミットとロールバックの実行、ブランチの作成と切り替えなどを続けることができます。 ネットワークに接続している場合でも、すべてがローカルの場合にブランチを作成し、ブランチを切り替える方が簡単かつ迅速です。 また、他の開発者に影響を与えることなく、ローカルコミットとロールバックを実行することもできます。 また、コミットをサーバーに送信する前にバッチ処理することもできます。

Azure Reposでは、Git とTeam Foundation バージョン管理の両方が提供されます (TFVC、一元化されたソース管理)。 Azure DevOps の概要 については、こちらを参照してください。

Visual Studio 2017 には、組み込みのファースト クラスの Git サポートが含まれています。 そのしくみの簡単なデモを次に示します。

Visual Studio でプロジェクトを開いた状態で、ソリューション エクスプローラーでソリューションを右クリックし、[ソース管理にソリューションを追加] を選択します。

ソース管理にソリューションを追加する

Visual Studio では、TFVC (一元化されたバージョン管理) または Git のどちらを使用するかを確認するメッセージが表示されます。

ソース管理の選択

[Git] を選択して [OK] をクリックすると、Visual Studio によってソリューション フォルダーに新しいローカル Git リポジトリが作成されます。 新しいリポジトリにはファイルがまだありません。Git コミットを実行して、リポジトリに追加する必要があります。 ソリューション エクスプローラーでソリューションを右クリックし、[コミット] をクリックします。

コミット

Visual Studio では、コミットのすべてのプロジェクト ファイルが自動的にステージングされ、[含まれる変更] ウィンドウの [チーム エクスプローラー] に一覧表示されます。 (コミットに含める必要がないものがある場合は、それらを選択して右クリックし、[ 除外] をクリックできます)。

チーム エクスプローラー

コミット コメントを入力して [コミット] をクリックすると、Visual Studio によってコミットが実行され、コミット IDが表示されます。

チーム エクスプローラーの変更

リポジトリの内容と異なるようにコードを変更すると、違いを簡単に確認できます。 変更したファイルを右クリックし、[変更 されていないファイルと比較] を選択すると、コミットされていない変更を示す比較表示が表示されます。

変更されていないと比較する

変更を示す差分

変更内容を簡単に確認してチェックできます。

ブランチを作成する必要があるとします。これは Visual Studio でも行うことができます。 [チーム エクスプローラー] で、[新しいブランチ] をクリックします。

Team エクスプローラー New Branch - Image 1

ブランチ名を入力し、[ ブランチの作成] をクリックします。 [Checkout branch]\(ブランチのチェックアウト\) を選択した場合、Visual Studio によって新しいブランチが自動的にチェックアウトされます。

Team エクスプローラー New Branch - Image 2

ファイルを変更し、このブランチにチェックできるようになりました。 また、ブランチを簡単に切り替えることができます。Visual Studio では、チェックアウトしたブランチにファイルが自動的に同期されます。この例では、 _Layout.cshtml の Web ページ タイトルが HotFix1 ブランチの "Hot Fix 1" に変更されています。

Hotfix1 ブランチ

メイン ブランチに戻すと、_Layout.cshtml ファイルの内容は、メイン ブランチ内の内容に自動的に戻ります。

メイン ブランチ

これは、ブランチをすばやく作成し、ブランチ間を行き来する方法の簡単な例です。 この機能を使用すると、ブランチ構造と自動化スクリプトを使用して、非常にアジャイルなワークフローを実現できます。これについては、「 すべて自動化 する」の章を参照してください。 たとえば、開発ブランチで作業し、メインからホットフィックスブランチを作成し、新しいブランチに切り替えて、そこで変更を加えてコミットしてから、開発ブランチに戻って作業を続けることができます。

ここで見てきたのは、Visual Studio でローカル Git リポジトリを操作する方法です。 チーム環境では、通常、変更を共通のリポジトリにプッシュします。 Visual Studio ツールを使用すると、リモート Git リポジトリをポイントすることもできます。 その目的で GitHub.com を使用することも、作業項目やバグ追跡など、他のすべての Azure DevOps 機能と統合された Git とAzure Reposを使用することもできます。

もちろん、アジャイルブランチ戦略を実装できる唯一の方法ではありません。 一元化されたソース管理リポジトリを使用して、同じアジャイル ワークフローを有効にすることができます。

まとめ

変更を迅速に行い、安全で予測可能な方法で稼働させる方法に基づいて、ソース管理システムの成功を測定します。 1 日または 2 日の手動テストを行う必要があるため、変更を行うのが怖い場合は、その変更を数分で行うことができるように、または 1 時間を超えて最悪の場合に行うことができるように、プロセスごとに、またはテスト的に何を行う必要があるかを自問する場合があります。 これを行うための 1 つの戦略は、継続的インテグレーションと継続的デリバリーを実装することです。 これについては、次の章で取り上げる予定です。

リソース

分岐戦略の詳細については、次のリソースを参照してください。

ソース管理リポジトリに保持すべきではない機密情報を処理する方法の詳細については、次のリソースを参照してください。

機密情報をソース管理から除外するその他の方法については、「 ASP.NET MVC: プライベート設定をソース管理から除外する」を参照してください。

前へ次へ