Azure DevOpsリポジトリをGitLabと統合する方法

目次

1. Azure DevOpsはGitLabに統合できるのか
2. GitLabとAzure DevOpsの違い
3. GitLabからAzureへの接続方法
4. 推奨される開発フロー
5. デプロイのワークフローのデモ動画
6. 試みる価値のあるソリューション
7. まとめ

Azure DevOpsリポジトリ内にコードを置いたままで、GitLabのパイプラインでCI/CDを実行する方法をご説明します。リンクは特に断りのない限り、英語版ページへのリンクとなります。ご留意ください。

最近、Azure DevOps/VSTS（Visual Studio Team Services）のソースコード管理（SCM）とGitLabを統合することは可能でしょうかと質問を受けることが続きました。こういった質問をしてきた方は、GitLabのような最新のCI/CD ソリューションを検討しているものの、段階移行で一時的に新旧のシステムが共存する間は、コードをAzure DevOps/VSTS内で管理する必要があるようです。

Azure DevOpsはGitLabに統合できるのか

はい、Azure DevOpsはGitLabに統合できます。

GitLabではGitLab CI/CDをGitLabの組み込みSCMと併せて使用することを推奨していますが、Azure DevOpsのソースコード管理とGitLabとを統合すると、コードをAzure DevOpsリポジトリに残したままGitLab CI/CDも導入できるため、Azure DevOpsから徐々にGitLabに移行することが可能です。GitLabのセルフマネージドバージョンと、SaaSバージョンのどちらでも統合が可能です。しかし、統合可能なのは、Azure DevOps/VSTSの Gitバージョン管理のみです。TFVC（Team Foundation Version Control）はサポートされていませんのでご注意ください。

Azure DevOpsとの統合を可能にするGitLabの2つの機能

外部リポジトリ用GitLab CI/CD ― GitLab CI/CDは外部リポジトリ（GitHub, Bitbucket Cloud など）のGitサーバーで利用できます。

リモートリポジトリのミラーリング ― リポジトリは外部ソースとの間でミラーリングできます。どのリポジトリをソースとして使用するかも選択できます。ミラーリングを行なうと、ブランチ、タグ、コミットなどが自動的に同期されます。

DevOps におけるリポジトリとは？

GitLabやAzureのようなツールにおけるコードリポジトリは、あらゆるソースコードを格納するために存在します。こういったリポジトリはDevOpsの「リポ」と呼ばれたり、「ソースリポジトリ」と呼ばれたりします。名前がどうであれ、デベロッパーが高いコード品質を目指して作業するための場所をコードリポジトリが提供することに変わりありません。GitLabは、バージョン管理によるソースコード管理にGitベースのリポジトリ（日本語版）を使用します。Gitベースのリポジトリを使用したバージョン管理により、GitLabユーザーがコードレビューを行い、開発面での問題を簡単に解決することができるのです。

GitLabとAzure DevOpsの違い

Azure DevOpsには、開発ライフサイクルを管理するための幅広いサービスがあります。主要機能には、アジャイルプランニングボード、ソースコード管理用のプライベートGitリポ、そしてAzureパイプラインなどがあります。 DevSecOpsライフサイクル全体に対応した単一プラットフォームとして提供されるGitLabには以下が含まれます。

• プランニングとコラボレーション
• ソースコード管理
• コードレビュー
• CI/CDパイプライン
• 継続的なセキュリティスキャンと監視
• 高度なデプロイ
• 脆弱性の管理
  
  GitLabは、セキュリティとコンプライアンスを強化しながら、DevSecOpsのライフサイクル全体の管理をサポートしてソフトウェアを迅速かつ効率的に提供します。

GitLabからAzureへの接続方法

ソースコード管理をAzureからGitLabへ完全に移行するには時間がかかる場合があります。ここでは、スムーズな移行のために、GitLabからAzure統合に接続する手順を説明します。

1. 「New Project（新規プロジェクト）」ボタンをクリックして、GitLab内に新規プロジェクトを作成します。

2. 「CI/CD for external repo（外部リポジトリ用 CI/CD）」タブを選択し、Repo by URL（リポジトリのURL）をクリックします。

3. Azure DevOps 内でリポジトリを開き、「Clone（クローン）」をクリックします。

4. URLをコピーします。お使いのリポジトリがプライベートだった場合、Gitの認証情報を生成する必要があります。「Generate Git Credentials（Git認証情報を生成）」をクリックし、ユーザー名とパスワードをコピーしてください。

5. 「Git repository URL（Gitリポジトリの URL）下の欄にURLを貼り付けます。 プロジェクト名を付けます。 可視性の表示レベルを設定します。 「プロジェクトを作成」をクリックします。 Azure DevOpsリポジトリがプライベートだった場合には、ユーザー名とパスワードを追加します。

注:リポジトリは、http://、https:// または git:// でアクセスできなければなりません。http:// または https:// プロトコルを使用する場合は、リポジトリへの正確なURLを指定してください。HTTPリダイレクトは実行されません。

6. プロジェクトはGitLabと正常にミラーリングされました。これで、ブランチ、タグ、コミットがGitLabと自動的に同期されるようになります。

7. CI/CDパイプラインを構成するオプションは2つあります。

Auto DevOpsを使わずにパイプライン構成をご自分で定義したい場合には、お使いのリポジトリのルートディレクトリに .gitlab-ci.yml ファイルを追加してください。このyamlコードには、CI/CD定義 を必ずインクルードしてください。

このファイルがルートディレクトリにインクルードされると、CI/CDパイプラインが各コミットごとにトリガーされます。.gitlab-ci.yml に不慣れな場合には、.gitlab-ci.yml という名前でファイルを作成し、以下のコードを貼り付けてください。このコードにはビルドステージとテストステージがあり、それぞれに、単一のジョブが含まれます。このジョブは各ステージでコンソールにテキストを表示します。

後でそれぞれのジョブにスクリプトを追加できます。また、ジョブやステージの追加も可能です。より複雑なパイプラインを作成するときは、ゼロから着手するのではなく、GitLabに付属のパイプラインテンプレートを使用するとよいでしょう。

stages:
  - build
  - test 

build:
  stage: build
  script:
    - echo "Build job"

test:
  stage: test
  script:
    - echo "Test job"

以上です。これで準備は済みました。

推奨される開発フロー

1. コード（デベロッパーが選択したIDE）
   デベロッパーはお気に入りのIDEを使用してコードを開発し、リポジトリをワークステーションに複製し、ブランチを作成します。
   

2. コミット（GIT）
   フィーチャーの開発またはバグ修正が完了したあと、デベロッパーはワークをAzureリポジトリサーバーにプッシュします。
   

3. ビルド（GitLab）
   コミット履歴つきのブランチがGitLabにミラーリングされます。CI/CDパイプラインがトリガーされ、このパイプラインにより、コードがビルドされます。

   アーティファクトが作成され、ダウンロードできるようになります。

   「Auto DevOps」が有効化されていれば、コンテナイメージが作成され、ビルトインのコンテナレジストリにプッシュされます。

   プロジェクト内でパッケージレジストリが有効化されている場合には、パッケージが指定されたパッケージマネージャに公開されます。
   

4. テスト (GitLab)
   CI パイプラインの一環として、セキュリティスキャン、ライセンススキャン、その他のテストが実行されます。
   

5. レビューとプルリクエスト (GitLabおよびAzure DevOpsリポジトリ)
   GitLabでパイプラインの結果をレビューし、エラーなくパイプラインがパスした場合、かつ、新しい変更により新たな脆弱性が生じていなければ、Azure DevOpsでプルリクエストを作成します。コードレビューが始まったら、デベロッパーはメインにマージする前に、新しい変更を加える必要がある場合があります。各コミットは、 GitLab内でCI/CDパイプラインをトリガーします。
   

6. マージ（Azure DevOpsリポジトリとGitLab）
   Azure DevOpsのプルリクエストが承認され、ブランチがAzure DevOpsリポジトリのメインブランチにマージされます。

パイプラインの構成により異なりますが、メインブランチへのこのマージは GitLab内のCI/CDパイプラインをトリガーし、マージ結果が検証され、新しいパッケージとコンテナイメージがビルドされ、その後それらがデプロイされます。

デプロイのワークフローのデモ動画

試みる価値のあるソリューション

GitLabは、トップクラスのソースコード管理（SCM）とCI/CDソリューションを単一のアプリケーションで提供し、多くの GitLab顧客がこのパワフルな組み合わせを利用しています。しかし、チームがすぐにリポジトリをGitLab SCMに移行できないという制約があるケースがあることも理解しています。そのような場合のために、一時的に外部リポジトリ用GitLab CI/CDを提供しています。

まとめ

ソースコード管理（SCM）とGitLabのCI/CDソリューションは、簡単に統合ができます。「Azure DevOpsリポジトリをGitLabのCI/CDに統合することも簡単にできるということを納得していただけたでしょうか。GitLabのCI/CDについてもっと詳しくお知りになりたい場合には、こちらの記事（日本語版）をご覧ください。

GitLab CI/CDについてさらに詳しく

フォレスターのレポート:主要なCI/CDツールの比較（英語版）

AWS Fargateを使用したGitLab CIのオートスケール（英語版）

お客様事例:ゴールドマン・サックスはビルド頻度を2週間に1回から1日に1000回以上へ改善（日本語版）

カバーイメージ出典：Aleksey Kuprikov on Unsplash

監修：ソリス ジェレズ / Jerez Solis @jerezs
（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）