GitHub Actionsを利用したAzure Pipelines連携を試してみた

スポンサーリンク
2019.12.22

本投稿はAzure DevOps Advent Calendar 2019の22日目の投稿になります。

qiita.com

Azure DevOpsの2019年12月2日のアップデートでGitHub Actionを利用してAzure Pipelinesを利用できるようになったようなので試してみた内容を記載します。

docs.microsoft.com

GitHub Actionを利用したAzure Pipelines連携では継続的インテグレーション（CI）をGithub、継続的配信（CD）をAzure Pipelinesと役割を分けるシナリオが考えられます。Azureアクセスやデプロイ、承認等に関してはAzure Devopsの方が扱いやすいので、そちらに委譲してしまうという考えだと思います。

GitHub側でCI管理をすれば、デプロイ先のクラウドは特定する必要がないのでロックインせずに利用できるメリットがあります。プログラムリソースはそのままなので、最小限の影響範囲でインフラを乗り換えることもできるでしょう。

※本投稿は2019年12月22日時点の情報になります。

作業準備

今回試す内容はGitHub上で管理しているAspNetCoreで作成したサイトのBuildとAzureへのデプロイをGitHub ActionをTriggerとしてAzure Devopsで実施するシナリオです。AzureDevOps側のPipelineは予め用意しておいてください。

スターターテンプレートが下記に用意されています。こちらをベースに作業をします。

github.com

必要な設定情報は下記の通りです。

  • Azure DevOps組織のプロジェクトURL
  • パイプライン名
  • パーソナルアクセストークン（PAT)

パーソナルアクセストークンの取得については下記に取得手順がまとまっているので参照してください。
※現在はRead/Writeのパーミッションについて差分があります。

docs.microsoft.com

環境構築

GitHubには予めAspNetCoreで作成したWebSiteを管理するリポジトリを用意しておきます。

GitHubのActionsから「Set up a workflow youself」をおして新規にワークフローとActionを作成します。

f:id:kingkino:20191220143440p:plain

初期情報が表示されるので任意に名称を設定します。MarkePlaceの検索画面で「Azure Pipelines」と入力して「Azure Pipelines Action」を検索します。

f:id:kingkino:20191221153116p:plain

検索したActionを追加して最終的に下記のようなYAML情報を作成することになります。

name: AzurePipeling Link 001
# trigger設定：ここではpush時に発火を設定
on: [push]
jobs:
  build:
    # 任意の名称
    name: Build & PipeLine Test
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [windows-latest]
    steps:
    - name: Azure Pipelines Action
      uses: Azure/pipelines@releases/v1
      with:
        # 対象のプロジェクト名を含むAzreDevOpsの組織URL
        azure-devops-project-url: https://dev.azure.com/<組織名>/<プロジェクト名>
        # 対象のPipeline名
        azure-pipeline-name: <pipeline名>
        # AzureDevopsのプライベートアクセストークン 
        azure-devops-token: ${{secrets.AzureDevOpsToken}}

ここで特筆するべき箇所としてプライベートアクセストークンをGithubの設定から読み取るようにしている点です。Privateのリポジトリなら埋め込んでしまっても問題はないのですが、Publicリポジトリの場合はAzureDevOpsのアクセストークンを公開してしまうことになります。こういう場合はGithubの設定にあるSecret機能を利用して管理しましょう。

メニューのSettings画面でSecretを選択して追加します。Key:Valueとして追加するのでKeyの部分は任意に設定してください。

f:id:kingkino:20191221155808p:plain

Secretで登録した情報は「secrets.<設定名>」で取得することが出来ます。

ワークフローの作成が完了するとリポジトリに> 「.github/workflows/」というフォルダが作成され、その中にYAMLファイルが生成されます。以降はこのファイルをベースに管理していくことになります。

f:id:kingkino:20191221160413p:plain

GitHub Actionsの詳細な利用方法は下記を参照してください。

help.github.com

GitHub Actionsを実行

設定が完了したら実行してみましょう。

GitHub ActionsのTriggerをPushにしているので何か変更を加えてクライアントからPushするかGitHubのページでYAMLの名称部分を変更してCommitすれば処理が実行されます。

f:id:kingkino:20191221160843p:plain

エラーが出た場合は実行履歴の画面から正常終了するまでReRunさせることも可能です。

f:id:kingkino:20191221161802p:plain

正常に実行されるとログから指定のPipelineが実行されていることがわかります。

f:id:kingkino:20191221162154p:plain

実際にAzure DevOps側の対象Pipelineを参照すると実行が開始されているか確認をしましょう。正常に実行されていれば成功です。

f:id:kingkino:20191221162459p:plain

まとめ

それぞれのプラットフォームの得意とする部分を切り出して利用できるので、組み合わせ次第で利用価値が高まると思います。ピタゴラスイッチになりがちなのと複数の同じようなサービスが混在してしまうので設計と運用メンテナンスが複雑になる部分が課題になりそうです。プログラム言語やプラットフォームの組み合わせでこれを使わなくてはならないという概念はうすまってきているので、いろいろ組み合わせて使っていくための選択肢になればいいなぁ。

コメント