NEXTSCAPE blog

株式会社ネクストスケープの社員による会社公式ブログです。ネスケラボでは、社員が日頃どのようなことに興味をもっているのか、仕事を通してどのような面白いことに取り組んでいるのかなど、会社や技術に関する情報をマイペースに紹介しています。

MENU

Azure DevOpsのBuild PipelineでWebAppsにデプロイ(リリース編) 2019年06月20日 Matsunaga

こんにちは。クラウド推進部の松永です。
 
前回に引き続き、Azure DevOpsのBuild Pipelineをつかって、AzureのWebAppsへのリリースまでの
 
流れを解説していきたいと思います。
 
今回はリリース編です。
 
 

f:id:nextscape_blog:20210911225905p:plain

 

リリースパイプラインを作ろう




では早速始めていきましょう。

前回はビルドパイプラインの実行まで完了しました。

※もし前回の記事見ていない方は、そちらの記事からご覧ください。

今回は、このビルドされたパッケージをWebAppsにデプロイする方法を解説していきます。


Azure DevOpsの左メニューからPipelines > Releasesを選択し、NewPipelineをクリックします。

すると、右側にリリースパイプラインのテンプレートを選択するメニューが表示されます。

ここからデプロイ先にあったテンプレートを選択します。


今回はWebAppsにデプロイをしますので、Azure App Service deploymnetを選択します。

選択して、Applyボタンを押しましょう。

するとリリースパイプラインの画面が表示されます。

f:id:nextscape_blog:20210911225934p:plain




リリースタスクの設定



次にリリースのタスクの設定をしていきます。

リリースパイプラインの画面の上部のメニューから、Tasks>Stage 1を選択するか、

Stage 1とかかれたボックスの下にあるリンクをクリックしましょう。

リリースパイプラインのタスク設定に画面が切り替わります。

f:id:nextscape_blog:20210911225953p:plain


タスク設定画面が表示されると同時に右側に設定画面がでてきます。

この設定画面でWebAppsへのリリース設定を行います。

まずはAzure Subscriptionのリストから、デプロイ先のWebAppsがあるサブスクリプションを選択します。

選択をしたら、Authorizeボタンを押しましょう。

すると、サブスクリプションの認証をするため、MSアカウントのサインイン画面が出てきますので、

パスワードを入力してサインインをします。

f:id:nextscape_blog:20210911230009p:plain

 

サインインをして認証がされると赤い枠が消えますので、App service nameを選択します。

リストにはサブスクリプション配下にあるWebAppsが出てきますので、デプロイ先のWebAppsを

選択します。

これでWebAppsへのリリース設定が完了しました。

 

あとは、一番上の項目のStage nameもわかりやすい名称に変更しましょう。

最後に、画面の右上部にあるSaveボタンを押せば、リリース設定が保存されます。

f:id:nextscape_blog:20210911230023p:plain

 

※Azure Subscriptionのリストには、現在Azure DevOpsにサインインしているアカウントが、

権限を持っているAzureのサブスクリプションが表示されます。

もし表示されない場合、サインインしているAzure DevOpsのアカウントがそのサブスクリプションに

ユーザーとして登録されているか確認しましょう。

 

 

アーティファクトを設定する



リリース設定が終わりましたので、次にリリース対象のアーティファクトの設定です。

左のArtifactsのAdd on artifactをクリックしましょう。

f:id:nextscape_blog:20210911230038p:plain


右側にメニューが表示されるので、設定していきます。

まず最初の項目のSource typeはBuild Pipelineでビルドされたものを使いますので、Buildを選択します。

とはいえ、初期表示時にはBuildが予め選択されているので、そのままでよいでしょう。

Projectも同様に今のプロジェクトが設定されていると思います。

SourceではBuild Pipeline名がリストで出てきますので、前回の記事で作成したビルドパイプラインを選択します。

選択すると自動的に、Default Version、Source aliasに値が入りますので、そのままAddをクリックします。

f:id:nextscape_blog:20210911230053p:plain


これでアーティファクトも設定がされ、リリースする準備が整いました。

 

f:id:nextscape_blog:20210911230155p:plain


リリースパイプラインを実行する




それでは一度動かしてみましょう。

画面右上のCreate Releaseボタンを押します。

また右メニューが出てきますが、今回はそのままの設定でCreateボタンを押します。

f:id:nextscape_blog:20210911230210p:plain

するとリリース処理が動きます。

f:id:nextscape_blog:20210911230227p:plain


このタスクが最後まで終了するとリリースがされますが、実はこのリリースは失敗します。

しばらくするとリリース失敗となり、リリースジョブが赤くなるので、Failedのリンクをクリックして

ログ画面を表示します。

f:id:nextscape_blog:20210911230242p:plain


ログ画面はビルドやリリースが失敗した時などに、タスクが何のログをはいているのかを確認する画面です。

ログ画面ではタスク毎にログを確認することができます。

今回はどうやらDeply Azure App Serviceのタスクでエラーが出ているようです。

もう少し詳細が見たいので、リンクをクリックしましょう。

f:id:nextscape_blog:20210911230300p:plain


すると、ダイアログ画面に詳細のログが表示されます。

これをみると、どうもビルドパッケージがないと怒られているようです。

##[error]Error: No package found with specified pattern: D:\a\r1\a\**\*.zip


 

f:id:nextscape_blog:20210911230314p:plain


しかし、ビルドは前回成功しているので、パッケージ自体はどこかに存在しているはずです。

ということは、タスクの設定で指定したパスにパッケージが存在しないことが考えられます。

ではDeply Azure App Serviceのタスク設定を確認してみます。

Package or folderの設定値に、$(System.DefaultWorkingDirectory)/**/*.zipという値が

設定されていることがわかります。

この$(System.DefaultWorkingDirectory)=D:\a\r1\a\を指しているので、

リリース実行時にD:\a\r1\a\**\*.zipのファイルを探しにいっているようです。

f:id:nextscape_blog:20210911230328p:plain


それではこのエラーを解消していきましょう。

実はこのエラー解消方法はいくつかありますが、今回はビルドパイプラインでビルドパッケージを

Azure DevOpsに登録する処理を追加し、リリースパイプラインでもビルドパッケージを参照できるよう

にしていきます。

これをすることで、D:\a\r1\a\配下にビルドパッケージがダウンロードされ、リリースができるように

なります。

 

 

ビルドパイプラインの修正




 では、ビルドパイプラインを修正していきましょう。

ビルドパイプラインを選択したら、Editボタンを押してビルドパイプラインの編集画面に遷移します。

右側にTasksテンプレートを選択するメニューがでてきますので、検索で"Publish Build"と入力します。

すると2種類の”Publish Build Artifacts" タスクがでてきますので、上のタスクをクリックします。

f:id:nextscape_blog:20210911230344p:plain

次にタスクの設定画面が出てきます。

パラメータはそのままにして、yamlファイルの一番下にカーソルを移動してから、

Addボタンをクリックします。

f:id:nextscape_blog:20210911230358p:plain


すると、yamlファイルに”PublishBuildArtifacts@1”というタスクが設定されます。

Build Pipelineでは、このようにタスクのテンプレートを追加すると、設定値が記載されたスニペットが

yamlファイルに自動で書き込まれるようになっています。

 

f:id:nextscape_blog:20210911230413p:plain

そうしたら、この状態でSaveしましょう。

Saveする際にはまたコミットメッセージを求められるので、適当なメッセージを入力して保存します。

再びビルドとリリースを実行

 


では、再度ビルドパイプラインとリリースパイプラインを動かしてみましょう。

とはいえ、実はSaveした時点でビルドパイプラインはすでに動いている人もいるかと思います。

もし動いていないようであれば、ビルドパイプラインのQueueボタンを押して実行しましょう。

ビルドが正常に終了したことを確認したら、再度リリースパイプラインを動かします。

Create Releaseボタンを押して、右メニューからCreateを押します。

リリースの状況を確認すると、今度は最後まで実行されると思います。

f:id:nextscape_blog:20210911230430p:plain


リリース処理が終了したらWebAppsの画面を見てみましょう。

ASP.NET Coreのデフォルト画面を見ることができると思います。

これでリリースパイプラインの作成が完了し、自動でWebAppsへリリースすることが

できるようになりました。

 

f:id:nextscape_blog:20210911230446p:plain


ビルドパイプラインの補足



今回ビルドパイプラインに追加したPublish Build Artifactsについて、少し補足をしましょう。

Publish Build Artifactsのタスクですが、これはPathtoPublishに指定されたパスを成果物として、

Azure DevOpsに登録するタスクです。

この設定では、$(Build.ArtifactStagingDirectory)が対象パスになっています。

f:id:nextscape_blog:20210911230500p:plain


ということは、ビルドしたパッケージがそのパスにないといけません。

さて、そのような設定はしていたでしょうか?

実はビルドパイプラインを作成した時点で、設定は既にされています。

$(Build.ArtifactStagingDirectory)は、2つ上のVSBuild@1のタスクの中でビルドパッケージの

出力先パスとして設定されているのです。

ですから、Publish Build Artifactsを追加するだけでビルドパッケージのAzure DevOpsへの登録が

できるようになるのです。

ちなみに、どのように設定されているか気になる方は、ArtifactStagingDirectoryで検索をかけてみると

VSBuildでの設定場所がわかると思います。

ちなみにリリースパイプラインのログを見てみると、Deply Azure App Serviceのタスクの前に

Download Artifact のタスクが追加されていて、登録されたArtifactsをD:\a\r1\a\配下に

ダウンロードしていることがわかります。


CI/CDの入口にようこそ



いかがでしたでしょうか。

ここまで実行できた方は、これでCI/CDの入口に到達したのではないでしょうか。

ただ道のりはこれからです。

ぜひこれ機会にAzure DevOpsをじっくり触りつつ、自分のPJにどう組み込んでいけばいいのか、

検討してみてはいかがでしょうか。