[{"data":1,"prerenderedAt":813},["ShallowReactive",2],{"/ja-jp/blog/integrating-azure-devops-scm-and-gitlab":3,"navigation-ja-jp":41,"banner-ja-jp":451,"footer-ja-jp":461,"blog-post-authors-ja-jp-Itzik Gan Baruch":696,"blog-related-posts-ja-jp-integrating-azure-devops-scm-and-gitlab":710,"blog-promotions-ja-jp":753,"next-steps-ja-jp":804},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":26,"externalUrl":27,"featured":14,"heroImage":19,"isFeatured":14,"meta":28,"navigation":29,"path":30,"publishedDate":20,"rawbody":31,"seo":32,"slug":13,"stem":36,"tagSlugs":37,"tags":39,"template":15,"updatedDate":25,"__hash__":40},"blogPosts/ja-jp/blog/integrating-azure-devops-scm-and-gitlab.yml","Azure DevOpsリポジトリをGitLabと統合する方法",[7],"itzik-gan-baruch",[9],"Itzik Gan Baruch","## 目次\n1. Azure DevOpsはGitLabに統合できるのか\n2. GitLabとAzure DevOpsの違い\n3. GitLabからAzureへの接続方法\n4. 推奨される開発フロー\n5. デプロイのワークフローのデモ動画\n6. 試みる価値のあるソリューション\n7. まとめ\n\nAzure DevOpsリポジトリ内にコードを置いたままで、GitLabのパイプラインでCI/CDを実行する方法をご説明します。リンクは特に断りのない限り、英語版ページへのリンクとなります。ご留意ください。\n\n最近、Azure DevOps/VSTS（Visual Studio Team Services）のソースコード管理（SCM）とGitLabを統合することは可能でしょうかと質問を受けることが続きました。こういった質問をしてきた方は、GitLabのような最新の[CI/CD ソリューション](https://about.gitlab.com/topics/ci-cd/)を検討しているものの、段階移行で一時的に新旧のシステムが共存する間は、コードをAzure DevOps/VSTS内で管理する必要があるようです。\n\n## Azure DevOpsはGitLabに統合できるのか\n\nはい、Azure DevOpsはGitLabに統合できます。\n\nGitLabではGitLab CI/CDをGitLabの組み込みSCMと併せて使用することを推奨していますが、Azure DevOpsのソースコード管理とGitLabとを統合すると、コードをAzure [DevOps](https://about.gitlab.com/ja-jp/topics/devops/)リポジトリに残したままGitLab CI/CDも導入できるため、Azure DevOpsから徐々にGitLabに移行することが可能です。GitLabのセルフマネージドバージョンと、SaaSバージョンのどちらでも統合が可能です。しかし、統合可能なのは、Azure DevOps/VSTSの Gitバージョン管理のみです。TFVC（Team Foundation Version Control）はサポートされていませんのでご注意ください。\n\n### Azure DevOpsとの統合を可能にするGitLabの2つの機能\n\n[外部リポジトリ用GitLab CI/CD](https://docs.gitlab.com/ja-jp/ci/ci_cd_for_external_repos/) ― GitLab CI/CDは外部リポジトリ（GitHub, Bitbucket Cloud など）のGitサーバーで利用できます。\n\n[リモートリポジトリのミラーリング](https://docs.gitlab.com/ja-jp/user/project/repository/mirror/) ― リポジトリは外部ソースとの間でミラーリングできます。どのリポジトリをソースとして使用するかも選択できます。ミラーリングを行なうと、ブランチ、タグ、コミットなどが自動的に同期されます。\n\n#### DevOps におけるリポジトリとは？\n\nGitLabやAzureのようなツールにおけるコードリポジトリは、あらゆるソースコードを格納するために存在します。こういったリポジトリはDevOpsの「リポ」と呼ばれたり、「ソースリポジトリ」と呼ばれたりします。名前がどうであれ、デベロッパーが高いコード品質を目指して作業するための場所をコードリポジトリが提供することに変わりありません。GitLabは、バージョン管理によるソースコード管理に[Gitベースのリポジトリ（日本語版）](https://about.gitlab.com/ja-jp/solutions/source-code-management/)を使用します。Gitベースのリポジトリを使用したバージョン管理により、GitLabユーザーがコードレビューを行い、開発面での問題を簡単に解決することができるのです。\n\n## GitLabとAzure DevOpsの違い\n\nAzure DevOpsには、開発ライフサイクルを管理するための幅広いサービスがあります。主要機能には、アジャイルプランニングボード、ソースコード管理用のプライベートGitリポ、そしてAzureパイプラインなどがあります。\nDevSecOpsライフサイクル全体に対応した単一プラットフォームとして提供されるGitLabには以下が含まれます。\n- プランニングとコラボレーション\n- ソースコード管理\n- コードレビュー\n- CI/CDパイプライン\n- 継続的なセキュリティスキャンと監視\n- 高度なデプロイ\n- 脆弱性の管理\n\u003Cbr>\n\u003Cbr>\nGitLabは、セキュリティとコンプライアンスを強化しながら、DevSecOpsのライフサイクル全体の管理をサポートしてソフトウェアを迅速かつ効率的に提供します。\n\n## GitLabからAzureへの接続方法\n\nソースコード管理をAzureからGitLabへ完全に移行するには時間がかかる場合があります。ここでは、スムーズな移行のために、GitLabからAzure統合に接続する手順を説明します。\n\n1. 「New Project（新規プロジェクト）」ボタンをクリックして、GitLab内に新規プロジェクトを作成します。 ![新規プロジェクトの作成](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado1.png){: .large.center}\n\n2. 「CI/CD for external repo（外部リポジトリ用 CI/CD）」タブを選択し、Repo by URL（リポジトリのURL）をクリックします。 ![外部リポジトリ用 CI/CD](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado2.png){: .large.center}\n\n3. Azure DevOps 内でリポジトリを開き、「Clone（クローン）」をクリックします。\n ![クローンURLを入手する](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado3.png)\n\n4. URLをコピーします。お使いのリポジトリがプライベートだった場合、Gitの認証情報を生成する必要があります。「Generate Git Credentials（Git認証情報を生成）」をクリックし、ユーザー名とパスワードをコピーしてください。 ![認証情報](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado4.png){: .large.center}\n\n5. 「Git repository URL（Gitリポジトリの URL）下の欄にURLを貼り付けます。\nプロジェクト名を付けます。\n可視性の表示レベルを設定します。\n「プロジェクトを作成」をクリックします。\nAzure DevOpsリポジトリがプライベートだった場合には、ユーザー名とパスワードを追加します。\n\n__注__:リポジトリは、http://、https:// または git:// でアクセスできなければなりません。http:// または https:// プロトコルを使用する場合は、リポジトリへの正確なURLを指定してください。HTTPリダイレクトは実行されません。\n\n ![プロジェクトフォームの作成\"](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado5.png)\n\n6. プロジェクトはGitLabと正常にミラーリングされました。これで、ブランチ、タグ、コミットがGitLabと自動的に同期されるようになります。\n\n7. CI/CDパイプラインを構成するオプションは2つあります。\n ![Auto DevOps 設定](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado6.png)\n\nAuto DevOpsを使わずにパイプライン構成をご自分で定義したい場合には、お使いのリポジトリのルートディレクトリに [.gitlab-ci.yml](https://docs.gitlab.com/ja-jp/ci/yaml/) ファイルを追加してください。このyamlコードには、[CI/CD定義](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/) を必ずインクルードしてください。\n\nこのファイルがルートディレクトリにインクルードされると、CI/CDパイプラインが各コミットごとにトリガーされます。.gitlab-ci.yml に不慣れな場合には、.gitlab-ci.yml という名前でファイルを作成し、以下のコードを貼り付けてください。このコードにはビルドステージとテストステージがあり、それぞれに、単一のジョブが含まれます。このジョブは各ステージでコンソールにテキストを表示します。\n\n後でそれぞれのジョブにスクリプトを追加できます。また、ジョブやステージの追加も可能です。より複雑なパイプラインを作成するときは、ゼロから着手するのではなく、[GitLabに付属の](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates)[パイプラインテンプレートを使用する](https://docs.gitlab.com/ja-jp/ci/yaml/#includetemplate)とよいでしょう。\n\n```yaml\nstages:\n - build\n - test\n\nbuild:\n stage: build\n script:\n - echo \"Build job\"\n\ntest:\n stage: test\n script:\n - echo \"Test job\"\n\n```\n\n以上です。これで準備は済みました。\n\n## 推奨される開発フロー\n\n![開発フローの図](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado_7_2.png){: .shadow.large.center}\n\n1. コード（デベロッパーが選択したIDE）\u003Cbr>\nデベロッパーはお気に入りのIDEを使用してコードを開発し、リポジトリをワークステーションに複製し、ブランチを作成します。\n ![Visual Studioのコード](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado8.png)\n\u003Cbr>\n\n2. コミット（GIT）\u003Cbr>\nフィーチャーの開発またはバグ修正が完了したあと、デベロッパーはワークをAzureリポジトリサーバーにプッシュします。 ![Azure DevOpsリポ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado9.png){: .shadow.large.center}\n\u003Cbr>\n3. ビルド（GitLab）\u003Cbr>\nコミット履歴つきのブランチがGitLabにミラーリングされます。CI/CDパイプラインがトリガーされ、このパイプラインにより、コードがビルドされます。 ![GitLabパイプライングラフ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado10.png){: .shadow.large.center}\n\n アーティファクトが作成され、ダウンロードできるようになります。\n ![アーティファクト](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado11.png)\n\n 「Auto DevOps」が有効化されていれば、コンテナイメージが作成され、ビルトインのコンテナレジストリにプッシュされます。\n![GitLabコンテナレジストリ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado12.png){: .shadow.large.center}\n\n プロジェクト内でパッケージレジストリが有効化されている場合には、パッケージが指定されたパッケージマネージャに公開されます。\n![GitLabパッケージレジストリ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado13.png){: .shadow.large.center}\n\u003Cbr>\n4. テスト (GitLab)\u003Cbr>\nCI パイプラインの一環として、セキュリティスキャン、ライセンススキャン、その他のテストが実行されます。 ![GitLab スキャン](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado14.png){: .shadow.large.center}\n\u003Cbr>\n5. レビューとプルリクエスト (GitLabおよびAzure DevOpsリポジトリ)\u003Cbr>\nGitLabでパイプラインの結果をレビューし、エラーなくパイプラインがパスした場合、かつ、新しい変更により新たな脆弱性が生じていなければ、Azure DevOpsでプルリクエストを作成します。コードレビューが始まったら、デベロッパーはメインにマージする前に、新しい変更を加える必要がある場合があります。各コミットは、 GitLab内でCI/CDパイプラインをトリガーします。 ![Azure DevOpsプルリクエスト](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado15.png){: .shadow.large.center}\n\u003Cbr>\n6. マージ（Azure DevOpsリポジトリとGitLab）\u003Cbr>\nAzure DevOpsのプルリクエストが承認され、ブランチがAzure DevOpsリポジトリのメインブランチにマージされます。\n\nパイプラインの構成により異なりますが、メインブランチへのこのマージは GitLab内のCI/CDパイプラインをトリガーし、マージ結果が検証され、新しいパッケージとコンテナイメージがビルドされ、その後それらがデプロイされます。 ![GitLab CI/CDパイプラインのグラフ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado16.png){: .shadow.large.center}\n\u003Cbr>\n## デプロイのワークフローのデモ動画\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/HfpP2pEmkoM\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n## 試みる価値のあるソリューション\n\nGitLabは、トップクラスのソースコード管理（SCM）とCI/CDソリューションを単一のアプリケーションで提供し、多くの [GitLab顧客](https://about.gitlab.com/customers/)がこのパワフルな組み合わせを利用しています。しかし、チームがすぐにリポジトリをGitLab SCMに移行できないという制約があるケースがあることも理解しています。そのような場合のために、一時的に外部リポジトリ用GitLab CI/CDを提供しています。\n\n## まとめ\n\nソースコード管理（SCM）とGitLabのCI/CDソリューションは、簡単に統合ができます。「Azure DevOpsリポジトリをGitLabのCI/CDに統合することも**簡単にできる**ということを納得していただけたでしょうか。GitLabのCI/CDについてもっと詳しくお知りになりたい場合には、[こちらの記事（日本語版）](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)をご覧ください。\n\n### GitLab CI/CDについてさらに詳しく\n\n[フォレスターのレポート:主要なCI/CDツールの比較（英語版）](https://about.gitlab.com/press/releases/2019-09-20-gitlab-named-cloud-native-continuous-integration-tools-leader/)\n\n[AWS Fargateを使用したGitLab CIのオートスケール（英語版）](/blog/introducing-autoscaling-gitlab-runners-on-aws-fargate/)\n\n[お客様事例:ゴールドマン・サックスはビルド頻度を2週間に1回から1日に1000回以上へ改善（日本語版）](https://about.gitlab.com/ja-jp/customers/goldman-sachs/)\n\n\u003Cbr>\n\u003Cbr>\n\u003Cbr>\n\nカバーイメージ出典：[Aleksey Kuprikov](https://unsplash.com/@alekskuprfilmz) on [Unsplash](https://unsplash.com/)\n\n\n\u003Cbr>\n\u003Cbr>\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n","engineering",{"slug":13,"featured":14,"template":15},"integrating-azure-devops-scm-and-gitlab",false,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21,"updatedDate":25},"Azure DevOpsリポジトリのGitLabとの統合は簡単。やり方を学んで、Azure DevOpsからGitLab CI/CDへの移行をスムーズに行いましょう。",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664363/Blog/Hero%20Images/aleksey-kuprikov.jpg","2020-07-09",[22,23,24],"CI/CD","agile","tutorial","2025-02-26","yml",null,{},true,"/ja-jp/blog/integrating-azure-devops-scm-and-gitlab","seo:\n title: Azure DevOpsリポジトリをGitLabと統合する方法\n description: >-\n Azure DevOpsリポジトリのGitLabとの統合は簡単。やり方を学んで、Azure DevOpsからGitLab\n CI/CDへの移行をスムーズに行いましょう。\n ogTitle: Azure DevOpsリポジトリをGitLabと統合する方法\n ogDescription: >-\n Azure DevOpsリポジトリのGitLabとの統合は簡単。やり方を学んで、Azure DevOpsからGitLab\n CI/CDへの移行をスムーズに行いましょう。\n noIndex: false\n ogImage: >-\n https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664363/Blog/Hero%20Images/aleksey-kuprikov.jpg\n ogUrl: https://about.gitlab.com/blog/integrating-azure-devops-scm-and-gitlab\n ogSiteName: https://about.gitlab.com\n ogType: article\n canonicalUrls: https://about.gitlab.com/blog/integrating-azure-devops-scm-and-gitlab\ncontent:\n title: Azure DevOpsリポジトリをGitLabと統合する方法\n description: >-\n Azure DevOpsリポジトリのGitLabとの統合は簡単。やり方を学んで、Azure DevOpsからGitLab\n CI/CDへの移行をスムーズに行いましょう。\n authors:\n - Itzik Gan Baruch\n heroImage: >-\n https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664363/Blog/Hero%20Images/aleksey-kuprikov.jpg\n date: '2020-07-09'\n body: >\n ## 目次\n\n 1. Azure DevOpsはGitLabに統合できるのか\n\n 2. GitLabとAzure DevOpsの違い\n\n 3. GitLabからAzureへの接続方法\n\n 4. 推奨される開発フロー\n\n 5. デプロイのワークフローのデモ動画\n\n 6. 試みる価値のあるソリューション\n\n 7. まとめ\n\n\n Azure\n DevOpsリポジトリ内にコードを置いたままで、GitLabのパイプラインでCI/CDを実行する方法をご説明します。リンクは特に断りのない限り、英語版ページへのリンクとなります。ご留意ください。\n\n\n 最近、Azure DevOps/VSTS（Visual Studio Team\n Services）のソースコード管理（SCM）とGitLabを統合することは可能でしょうかと質問を受けることが続きました。こういった質問をしてきた方は、GitLabのような最新の[CI/CD\n ソリューション](https://about.gitlab.com/topics/ci-cd/)を検討しているものの、段階移行で一時的に新旧のシステムが共存する間は、コードをAzure\n DevOps/VSTS内で管理する必要があるようです。\n\n\n ## Azure DevOpsはGitLabに統合できるのか\n\n\n はい、Azure DevOpsはGitLabに統合できます。\n\n\n GitLabではGitLab CI/CDをGitLabの組み込みSCMと併せて使用することを推奨していますが、Azure\n DevOpsのソースコード管理とGitLabとを統合すると、コードをAzure\n [DevOps](https://about.gitlab.com/ja-jp/topics/devops/)リポジトリに残したままGitLab\n CI/CDも導入できるため、Azure\n DevOpsから徐々にGitLabに移行することが可能です。GitLabのセルフマネージドバージョンと、SaaSバージョンのどちらでも統合が可能です。しかし、統合可能なのは、Azure\n DevOps/VSTSの Gitバージョン管理のみです。TFVC（Team Foundation Version\n Control）はサポートされていませんのでご注意ください。\n\n\n ### Azure DevOpsとの統合を可能にするGitLabの2つの機能\n\n\n [外部リポジトリ用GitLab\n CI/CD](https://docs.gitlab.com/ja-jp/ci/ci_cd_for_external_repos/) ― GitLab\n CI/CDは外部リポジトリ（GitHub, Bitbucket Cloud など）のGitサーバーで利用できます。\n\n\n [リモートリポジトリのミラーリング](https://docs.gitlab.com/ja-jp/user/project/repository/mirror/)\n ―\n リポジトリは外部ソースとの間でミラーリングできます。どのリポジトリをソースとして使用するかも選択できます。ミラーリングを行なうと、ブランチ、タグ、コミットなどが自動的に同期されます。\n\n\n #### DevOps におけるリポジトリとは？\n\n\n GitLabやAzureのようなツールにおけるコードリポジトリは、あらゆるソースコードを格納するために存在します。こういったリポジトリはDevOpsの「リポ」と呼ばれたり、「ソースリポジトリ」と呼ばれたりします。名前がどうであれ、デベロッパーが高いコード品質を目指して作業するための場所をコードリポジトリが提供することに変わりありません。GitLabは、バージョン管理によるソースコード管理に[Gitベースのリポジトリ（日本語版）](https://about.gitlab.com/ja-jp/solutions/source-code-management/)を使用します。Gitベースのリポジトリを使用したバージョン管理により、GitLabユーザーがコードレビューを行い、開発面での問題を簡単に解決することができるのです。\n\n\n ## GitLabとAzure DevOpsの違い\n\n\n Azure\n DevOpsには、開発ライフサイクルを管理するための幅広いサービスがあります。主要機能には、アジャイルプランニングボード、ソースコード管理用のプライベートGitリポ、そしてAzureパイプラインなどがあります。\n\n DevSecOpsライフサイクル全体に対応した単一プラットフォームとして提供されるGitLabには以下が含まれます。\n\n - プランニングとコラボレーション\n\n - ソースコード管理\n\n - コードレビュー\n\n - CI/CDパイプライン\n\n - 継続的なセキュリティスキャンと監視\n\n - 高度なデプロイ\n\n - 脆弱性の管理\n\n \u003Cbr>\n\n \u003Cbr>\n\n GitLabは、セキュリティとコンプライアンスを強化しながら、DevSecOpsのライフサイクル全体の管理をサポートしてソフトウェアを迅速かつ効率的に提供します。\n\n\n ## GitLabからAzureへの接続方法\n\n\n ソースコード管理をAzureからGitLabへ完全に移行するには時間がかかる場合があります。ここでは、スムーズな移行のために、GitLabからAzure統合に接続する手順を説明します。\n\n\n 1. 「New Project（新規プロジェクト）」ボタンをクリックして、GitLab内に新規プロジェクトを作成します。\n ![新規プロジェクトの作成](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado1.png){:\n .large.center}\n\n\n 2. 「CI/CD for external repo（外部リポジトリ用 CI/CD）」タブを選択し、Repo by\n URL（リポジトリのURL）をクリックします。 ![外部リポジトリ用\n CI/CD](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado2.png){:\n .large.center}\n\n\n 3. Azure DevOps 内でリポジトリを開き、「Clone（クローン）」をクリックします。\n ![クローンURLを入手する](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado3.png)\n\n 4. URLをコピーします。お使いのリポジトリがプライベートだった場合、Gitの認証情報を生成する必要があります。「Generate Git\n Credentials（Git認証情報を生成）」をクリックし、ユーザー名とパスワードをコピーしてください。\n ![認証情報](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado4.png){:\n .large.center}\n\n\n 5. 「Git repository URL（Gitリポジトリの URL）下の欄にURLを貼り付けます。\n\n プロジェクト名を付けます。\n\n 可視性の表示レベルを設定します。\n\n 「プロジェクトを作成」をクリックします。\n\n Azure DevOpsリポジトリがプライベートだった場合には、ユーザー名とパスワードを追加します。\n\n\n __注__:リポジトリは、http://、https:// または git:// でアクセスできなければなりません。http:// または\n https:// プロトコルを使用する場合は、リポジトリへの正確なURLを指定してください。HTTPリダイレクトは実行されません。\n\n ![プロジェクトフォームの作成\"](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado5.png)\n\n 6. プロジェクトはGitLabと正常にミラーリングされました。これで、ブランチ、タグ、コミットがGitLabと自動的に同期されるようになります。\n\n\n 7. CI/CDパイプラインを構成するオプションは2つあります。\n ![Auto DevOps 設定](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado6.png)\n\n Auto DevOpsを使わずにパイプライン構成をご自分で定義したい場合には、お使いのリポジトリのルートディレクトリに\n [.gitlab-ci.yml](https://docs.gitlab.com/ja-jp/ci/yaml/)\n ファイルを追加してください。このyamlコードには、[CI/CD定義](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/)\n を必ずインクルードしてください。\n\n\n このファイルがルートディレクトリにインクルードされると、CI/CDパイプラインが各コミットごとにトリガーされます。.gitlab-ci.yml\n に不慣れな場合には、.gitlab-ci.yml\n という名前でファイルを作成し、以下のコードを貼り付けてください。このコードにはビルドステージとテストステージがあり、それぞれに、単一のジョブが含まれます。このジョブは各ステージでコンソールにテキストを表示します。\n\n\n 後でそれぞれのジョブにスクリプトを追加できます。また、ジョブやステージの追加も可能です。より複雑なパイプラインを作成するときは、ゼロから着手するのではなく、[GitLabに付属の](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates)[パイプラインテンプレートを使用する](https://docs.gitlab.com/ja-jp/ci/yaml/#includetemplate)とよいでしょう。\n\n\n ```yaml\n\n stages:\n - build\n - test\n\n build:\n stage: build\n script:\n - echo \"Build job\"\n\n test:\n stage: test\n script:\n - echo \"Test job\"\n\n ```\n\n\n 以上です。これで準備は済みました。\n\n\n ## 推奨される開発フロー\n\n\n ![開発フローの図](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado_7_2.png){:\n .shadow.large.center}\n\n\n 1. コード（デベロッパーが選択したIDE）\u003Cbr>\n\n デベロッパーはお気に入りのIDEを使用してコードを開発し、リポジトリをワークステーションに複製し、ブランチを作成します。\n ![Visual Studioのコード](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado8.png)\n \u003Cbr>\n\n\n 2. コミット（GIT）\u003Cbr>\n\n フィーチャーの開発またはバグ修正が完了したあと、デベロッパーはワークをAzureリポジトリサーバーにプッシュします。 ![Azure\n DevOpsリポ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado9.png){:\n .shadow.large.center}\n\n \u003Cbr>\n\n 3. ビルド（GitLab）\u003Cbr>\n\n コミット履歴つきのブランチがGitLabにミラーリングされます。CI/CDパイプラインがトリガーされ、このパイプラインにより、コードがビルドされます。\n ![GitLabパイプライングラフ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado10.png){:\n .shadow.large.center}\n\n アーティファクトが作成され、ダウンロードできるようになります。\n ![アーティファクト](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado11.png)\n\n 「Auto DevOps」が有効化されていれば、コンテナイメージが作成され、ビルトインのコンテナレジストリにプッシュされます。\n ![GitLabコンテナレジストリ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado12.png){:\n .shadow.large.center}\n\n プロジェクト内でパッケージレジストリが有効化されている場合には、パッケージが指定されたパッケージマネージャに公開されます。\n ![GitLabパッケージレジストリ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado13.png){:\n .shadow.large.center}\n\n \u003Cbr>\n\n 4. テスト (GitLab)\u003Cbr>\n\n CI パイプラインの一環として、セキュリティスキャン、ライセンススキャン、その他のテストが実行されます。 ![GitLab\n スキャン](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado14.png){:\n .shadow.large.center}\n\n \u003Cbr>\n\n 5. レビューとプルリクエスト (GitLabおよびAzure DevOpsリポジトリ)\u003Cbr>\n\n GitLabでパイプラインの結果をレビューし、エラーなくパイプラインがパスした場合、かつ、新しい変更により新たな脆弱性が生じていなければ、Azure\n DevOpsでプルリクエストを作成します。コードレビューが始まったら、デベロッパーはメインにマージする前に、新しい変更を加える必要がある場合があります。各コミットは、\n GitLab内でCI/CDパイプラインをトリガーします。 ![Azure\n DevOpsプルリクエスト](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado15.png){:\n .shadow.large.center}\n\n \u003Cbr>\n\n 6. マージ（Azure DevOpsリポジトリとGitLab）\u003Cbr>\n\n Azure DevOpsのプルリクエストが承認され、ブランチがAzure DevOpsリポジトリのメインブランチにマージされます。\n\n\n パイプラインの構成により異なりますが、メインブランチへのこのマージは\n GitLab内のCI/CDパイプラインをトリガーし、マージ結果が検証され、新しいパッケージとコンテナイメージがビルドされ、その後それらがデプロイされます。\n ![GitLab\n CI/CDパイプラインのグラフ](https://about.gitlab.com/images/blogimages/ado_and_gitlab/ado16.png){:\n .shadow.large.center}\n\n \u003Cbr>\n\n ## デプロイのワークフローのデモ動画\n\n\n \u003Ciframe width=\"560\" height=\"315\"\n src=\"https://www.youtube.com/embed/HfpP2pEmkoM\" frameborder=\"0\"\n allow=\"accelerometer; autoplay; encrypted-media; gyroscope;\n picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n\n ## 試みる価値のあるソリューション\n\n\n GitLabは、トップクラスのソースコード管理（SCM）とCI/CDソリューションを単一のアプリケーションで提供し、多くの\n [GitLab顧客](https://about.gitlab.com/customers/)がこのパワフルな組み合わせを利用しています。しかし、チームがすぐにリポジトリをGitLab\n SCMに移行できないという制約があるケースがあることも理解しています。そのような場合のために、一時的に外部リポジトリ用GitLab\n CI/CDを提供しています。\n\n\n ## まとめ\n\n\n ソースコード管理（SCM）とGitLabのCI/CDソリューションは、簡単に統合ができます。「Azure\n DevOpsリポジトリをGitLabのCI/CDに統合することも**簡単にできる**ということを納得していただけたでしょうか。GitLabのCI/CDについてもっと詳しくお知りになりたい場合には、[こちらの記事（日本語版）](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)をご覧ください。\n\n\n ### GitLab CI/CDについてさらに詳しく\n\n\n [フォレスターのレポート:主要なCI/CDツールの比較（英語版）](https://about.gitlab.com/press/releases/2019-09-20-gitlab-named-cloud-native-continuous-integration-tools-leader/)\n\n\n [AWS Fargateを使用したGitLab\n CIのオートスケール（英語版）](/blog/introducing-autoscaling-gitlab-runners-on-aws-fargate/)\n\n\n [お客様事例:ゴールドマン・サックスはビルド頻度を2週間に1回から1日に1000回以上へ改善（日本語版）](https://about.gitlab.com/ja-jp/customers/goldman-sachs/)\n\n\n \u003Cbr>\n\n \u003Cbr>\n\n \u003Cbr>\n\n\n カバーイメージ出典：[Aleksey Kuprikov](https://unsplash.com/@alekskuprfilmz) on\n [Unsplash](https://unsplash.com/)\n\n\n\n \u003Cbr>\n\n \u003Cbr>\n\n\n *監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n\n （GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n category: engineering\n tags:\n - CI/CD\n - agile\n - tutorial\n updatedDate: '2025-02-26'\nconfig:\n slug: integrating-azure-devops-scm-and-gitlab\n featured: false\n template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":14,"ogImage":19,"ogUrl":33,"ogSiteName":34,"ogType":35,"canonicalUrls":33},"https://about.gitlab.com/blog/integrating-azure-devops-scm-and-gitlab","https://about.gitlab.com","article","ja-jp/blog/integrating-azure-devops-scm-and-gitlab",[38,23,24],"cicd",[22,23,24],"XlpFCQ7kTkm32dbbi5DHc0EyUgEOvI5cwuQ9KM55jZE",{"data":42},{"logo":43,"freeTrial":48,"sales":53,"login":58,"items":63,"search":371,"minimal":404,"duo":421,"switchNav":430,"pricingDeployment":441},{"config":44},{"href":45,"dataGaName":46,"dataGaLocation":47},"/ja-jp/","gitlab logo","header",{"text":49,"config":50},"無料トライアルを開始",{"href":51,"dataGaName":52,"dataGaLocation":47},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":54,"config":55},"お問い合わせ",{"href":56,"dataGaName":57,"dataGaLocation":47},"/ja-jp/sales/","sales",{"text":59,"config":60},"サインイン",{"href":61,"dataGaName":62,"dataGaLocation":47},"https://gitlab.com/users/sign_in/","sign in",[64,91,187,192,293,353],{"text":65,"config":66,"cards":68},"プラットフォーム",{"dataNavLevelOne":67},"platform",[69,75,83],{"title":65,"description":70,"link":71},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":72,"config":73},"プラットフォームを探索",{"href":74,"dataGaName":67,"dataGaLocation":47},"/ja-jp/platform/",{"title":76,"description":77,"link":78},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":79,"config":80},"GitLab Duoのご紹介",{"href":81,"dataGaName":82,"dataGaLocation":47},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":84,"description":85,"link":86},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":87,"config":88},"詳細はこちら",{"href":89,"dataGaName":90,"dataGaLocation":47},"/ja-jp/why-gitlab/","why gitlab",{"text":92,"left":29,"config":93,"link":95,"lists":99,"footer":169},"製品",{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"すべてのソリューションを表示",{"href":98,"dataGaName":94,"dataGaLocation":47},"/ja-jp/solutions/",[100,124,147],{"title":101,"description":102,"link":103,"items":108},"自動化","CI/CDと自動化でデプロイを加速",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":47},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[109,112,115,120],{"text":22,"config":110},{"href":111,"dataGaLocation":47,"dataGaName":22},"/ja-jp/solutions/continuous-integration/",{"text":76,"config":113},{"href":81,"dataGaLocation":47,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"ソースコード管理",{"href":118,"dataGaLocation":47,"dataGaName":119},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"自動化されたソフトウェアデリバリー",{"href":106,"dataGaLocation":47,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":47,"icon":131},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[133,137,142],{"text":134,"config":135},"アプリケーションセキュリティテスト",{"href":129,"dataGaName":136,"dataGaLocation":47},"Application security testing",{"text":138,"config":139},"ソフトウェアサプライチェーンの安全性",{"href":140,"dataGaLocation":47,"dataGaName":141},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"ソフトウェアコンプライアンス",{"href":145,"dataGaName":146,"dataGaLocation":47},"/ja-jp/solutions/software-compliance/","software compliance",{"title":148,"link":149,"items":154},"測定",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":47},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"可視性と測定",{"href":152,"dataGaLocation":47,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"バリューストリーム管理",{"href":162,"dataGaLocation":47,"dataGaName":163},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"分析とインサイト",{"href":167,"dataGaLocation":47,"dataGaName":168},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLabが活躍する場所",[172,177,182],{"text":173,"config":174},"大企業",{"href":175,"dataGaLocation":47,"dataGaName":176},"/ja-jp/enterprise/","enterprise",{"text":178,"config":179},"スモールビジネス",{"href":180,"dataGaLocation":47,"dataGaName":181},"/ja-jp/small-business/","small business",{"text":183,"config":184},"公共部門",{"href":185,"dataGaLocation":47,"dataGaName":186},"/ja-jp/solutions/public-sector/","public sector",{"text":188,"config":189},"価格",{"href":190,"dataGaName":191,"dataGaLocation":47,"dataNavLevelOne":191},"/ja-jp/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":280},"リソース",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"すべてのリソースを表示",{"href":199,"dataGaName":195,"dataGaLocation":47},"/ja-jp/resources/",[201,234,252],{"title":202,"items":203},"はじめに",[204,209,214,219,224,229],{"text":205,"config":206},"インストール",{"href":207,"dataGaName":208,"dataGaLocation":47},"/ja-jp/install/","install",{"text":210,"config":211},"クイックスタートガイド",{"href":212,"dataGaName":213,"dataGaLocation":47},"/ja-jp/get-started/","quick setup checklists",{"text":215,"config":216},"学ぶ",{"href":217,"dataGaLocation":47,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"製品ドキュメント",{"href":222,"dataGaName":223,"dataGaLocation":47},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":225,"config":226},"ベストプラクティスビデオ",{"href":227,"dataGaName":228,"dataGaLocation":47},"/ja-jp/getting-started-videos/","best practice videos",{"text":230,"config":231},"インテグレーション",{"href":232,"dataGaName":233,"dataGaLocation":47},"/ja-jp/integrations/","integrations",{"title":235,"items":236},"検索する",[237,242,247],{"text":238,"config":239},"お客様成功事例",{"href":240,"dataGaName":241,"dataGaLocation":47},"/ja-jp/customers/","customer success stories",{"text":243,"config":244},"ブログ",{"href":245,"dataGaName":246,"dataGaLocation":47},"/ja-jp/blog/","blog",{"text":248,"config":249},"リモート",{"href":250,"dataGaName":251,"dataGaLocation":47},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":253,"items":254},"つなげる",[255,260,265,270,275],{"text":256,"config":257},"GitLabサービス",{"href":258,"dataGaName":259,"dataGaLocation":47},"/ja-jp/services/","services",{"text":261,"config":262},"コミュニティ",{"href":263,"dataGaName":264,"dataGaLocation":47},"/community/","community",{"text":266,"config":267},"フォーラム",{"href":268,"dataGaName":269,"dataGaLocation":47},"https://forum.gitlab.com/","forum",{"text":271,"config":272},"イベント",{"href":273,"dataGaName":274,"dataGaLocation":47},"/events/","events",{"text":276,"config":277},"パートナー",{"href":278,"dataGaName":279,"dataGaLocation":47},"/ja-jp/partners/","partners",{"background":281,"textColor":282,"text":283,"image":284,"link":288},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":285,"config":286},"ソースプロモカード",{"src":287},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":289,"config":290},"最新情報を読む",{"href":291,"dataGaName":292,"dataGaLocation":47},"/ja-jp/the-source/","the source",{"text":294,"config":295,"lists":297},"会社情報",{"dataNavLevelOne":296},"company",[298],{"items":299},[300,305,311,313,318,323,328,333,338,343,348],{"text":301,"config":302},"GitLabについて",{"href":303,"dataGaName":304,"dataGaLocation":47},"/ja-jp/company/","about",{"text":306,"config":307,"footerGa":310},"採用情報",{"href":308,"dataGaName":309,"dataGaLocation":47},"/jobs/","jobs",{"dataGaName":309},{"text":271,"config":312},{"href":273,"dataGaName":274,"dataGaLocation":47},{"text":314,"config":315},"経営陣",{"href":316,"dataGaName":317,"dataGaLocation":47},"/company/team/e-group/","leadership",{"text":319,"config":320},"チーム",{"href":321,"dataGaName":322,"dataGaLocation":47},"/company/team/","team",{"text":324,"config":325},"ハンドブック",{"href":326,"dataGaName":327,"dataGaLocation":47},"https://handbook.gitlab.com/","handbook",{"text":329,"config":330},"投資家向け情報",{"href":331,"dataGaName":332,"dataGaLocation":47},"https://ir.gitlab.com/","investor relations",{"text":334,"config":335},"トラストセンター",{"href":336,"dataGaName":337,"dataGaLocation":47},"/ja-jp/security/","trust center",{"text":339,"config":340},"AI Transparency Center",{"href":341,"dataGaName":342,"dataGaLocation":47},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":344,"config":345},"ニュースレター",{"href":346,"dataGaName":347,"dataGaLocation":47},"/company/contact/#contact-forms","newsletter",{"text":349,"config":350},"プレス",{"href":351,"dataGaName":352,"dataGaLocation":47},"/press/","press",{"text":54,"config":354,"lists":355},{"dataNavLevelOne":296},[356],{"items":357},[358,361,366],{"text":54,"config":359},{"href":56,"dataGaName":360,"dataGaLocation":47},"talk to sales",{"text":362,"config":363},"サポートを受ける",{"href":364,"dataGaName":365,"dataGaLocation":47},"https://support.gitlab.com","support portal",{"text":367,"config":368},"カスタマーポータル",{"href":369,"dataGaName":370,"dataGaLocation":47},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"閉じる",{"text":374,"link":375},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":376,"config":377},"GitLab.com",{"href":61,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"提案",[383,385,390,392,396,400],{"text":76,"config":384},{"href":81,"dataGaName":76,"dataGaLocation":379},{"text":386,"config":387},"コード提案（AI）",{"href":388,"dataGaName":389,"dataGaLocation":379},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":22,"config":391},{"href":111,"dataGaName":22,"dataGaLocation":379},{"text":393,"config":394},"GitLab on AWS",{"href":395,"dataGaName":393,"dataGaLocation":379},"/ja-jp/partners/technology-partners/aws/",{"text":397,"config":398},"GitLab on Google Cloud",{"href":399,"dataGaName":397,"dataGaLocation":379},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":401,"config":402},"GitLabを選ぶ理由",{"href":89,"dataGaName":403,"dataGaLocation":379},"Why GitLab?",{"freeTrial":405,"mobileIcon":409,"desktopIcon":414,"secondaryButton":417},{"text":49,"config":406},{"href":407,"dataGaName":52,"dataGaLocation":408},"https://gitlab.com/-/trials/new/","nav",{"altText":410,"config":411},"GitLabアイコン",{"src":412,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":410,"config":415},{"src":416,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":202,"config":418},{"href":419,"dataGaName":420,"dataGaLocation":408},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":422,"mobileIcon":426,"desktopIcon":428},{"text":423,"config":424},"GitLab Duoの詳細について",{"href":81,"dataGaName":425,"dataGaLocation":408},"gitlab duo",{"altText":410,"config":427},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":429},{"src":416,"dataGaName":413,"dataGaLocation":408},{"button":431,"mobileIcon":436,"desktopIcon":438},{"text":432,"config":433},"/switch",{"href":434,"dataGaName":435,"dataGaLocation":408},"#contact","switch",{"altText":410,"config":437},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":439},{"src":440,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":442,"mobileIcon":447,"desktopIcon":449},{"text":443,"config":444},"料金ページに戻る",{"href":190,"dataGaName":445,"dataGaLocation":408,"icon":446},"back to pricing","GoBack",{"altText":410,"config":448},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":450},{"src":416,"dataGaName":413,"dataGaLocation":408},{"title":452,"button":453,"config":458},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":454,"config":455},"GitLab Transcendを今すぐ視聴",{"href":456,"dataGaName":457,"dataGaLocation":47},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":459,"icon":460,"disabled":29},"release","AiStar",{"data":462},{"text":463,"source":464,"edit":470,"contribute":475,"config":480,"items":485,"minimal":687},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":465,"config":466},"ページのソースを表示",{"href":467,"dataGaName":468,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":471,"config":472},"このページを編集",{"href":473,"dataGaName":474,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":476,"config":477},"ご協力をお願いします",{"href":478,"dataGaName":479,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":481,"facebook":482,"youtube":483,"linkedin":484},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[486,531,583,626,653],{"title":188,"links":487,"subMenu":502},[488,492,497],{"text":489,"config":490},"プランの表示",{"href":190,"dataGaName":491,"dataGaLocation":469},"view plans",{"text":493,"config":494},"Premiumを選ぶ理由",{"href":495,"dataGaName":496,"dataGaLocation":469},"/ja-jp/pricing/premium/","why premium",{"text":498,"config":499},"Ultimateを選ぶ理由",{"href":500,"dataGaName":501,"dataGaLocation":469},"/ja-jp/pricing/ultimate/","why ultimate",[503],{"title":54,"links":504},[505,507,509,511,516,521,526],{"text":54,"config":506},{"href":56,"dataGaName":57,"dataGaLocation":469},{"text":362,"config":508},{"href":364,"dataGaName":365,"dataGaLocation":469},{"text":367,"config":510},{"href":369,"dataGaName":370,"dataGaLocation":469},{"text":512,"config":513},"ステータス",{"href":514,"dataGaName":515,"dataGaLocation":469},"https://status.gitlab.com/","status",{"text":517,"config":518},"利用規約",{"href":519,"dataGaName":520,"dataGaLocation":469},"/terms/","terms of use",{"text":522,"config":523},"プライバシーに関する声明",{"href":524,"dataGaName":525,"dataGaLocation":469},"/ja-jp/privacy/","privacy statement",{"text":527,"config":528},"Cookie 優先設定",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":29},"cookie preferences","ot-sdk-btn",{"title":92,"links":532,"subMenu":541},[533,537],{"text":534,"config":535},"DevSecOpsプラットフォーム",{"href":74,"dataGaName":536,"dataGaLocation":469},"devsecops platform",{"text":538,"config":539},"AI支援開発",{"href":81,"dataGaName":540,"dataGaLocation":469},"ai-assisted development",[542],{"title":543,"links":544},"トピック",[545,548,553,558,563,568,573,578],{"text":22,"config":546},{"href":547,"dataGaName":38,"dataGaLocation":469},"/ja-jp/topics/ci-cd/",{"text":549,"config":550},"GitOps",{"href":551,"dataGaName":552,"dataGaLocation":469},"/ja-jp/topics/gitops/","gitops",{"text":554,"config":555},"DevOps",{"href":556,"dataGaName":557,"dataGaLocation":469},"/ja-jp/topics/devops/","devops",{"text":559,"config":560},"バージョン管理",{"href":561,"dataGaName":562,"dataGaLocation":469},"/ja-jp/topics/version-control/","version control",{"text":564,"config":565},"DevSecOps",{"href":566,"dataGaName":567,"dataGaLocation":469},"/ja-jp/topics/devsecops/","devsecops",{"text":569,"config":570},"クラウドネイティブ",{"href":571,"dataGaName":572,"dataGaLocation":469},"/ja-jp/topics/cloud-native/","cloud native",{"text":574,"config":575},"コーディングのためのAI",{"href":576,"dataGaName":577,"dataGaLocation":469},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":579,"config":580},"エージェント型AI",{"href":581,"dataGaName":582,"dataGaLocation":469},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":584,"links":585},"ソリューション",[586,589,591,596,600,603,606,609,611,613,616,621],{"text":134,"config":587},{"href":129,"dataGaName":588,"dataGaLocation":469},"Application Security Testing",{"text":121,"config":590},{"href":106,"dataGaName":107,"dataGaLocation":469},{"text":592,"config":593},"アジャイル開発",{"href":594,"dataGaName":595,"dataGaLocation":469},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":597,"config":598},"SCM",{"href":118,"dataGaName":599,"dataGaLocation":469},"source code management",{"text":22,"config":601},{"href":111,"dataGaName":602,"dataGaLocation":469},"continuous integration & delivery",{"text":160,"config":604},{"href":162,"dataGaName":605,"dataGaLocation":469},"value stream management",{"text":549,"config":607},{"href":608,"dataGaName":552,"dataGaLocation":469},"/ja-jp/solutions/gitops/",{"text":173,"config":610},{"href":175,"dataGaName":176,"dataGaLocation":469},{"text":178,"config":612},{"href":180,"dataGaName":181,"dataGaLocation":469},{"text":614,"config":615},"公共機関",{"href":185,"dataGaName":186,"dataGaLocation":469},{"text":617,"config":618},"教育",{"href":619,"dataGaName":620,"dataGaLocation":469},"/ja-jp/solutions/education/","education",{"text":622,"config":623},"金融サービス",{"href":624,"dataGaName":625,"dataGaLocation":469},"/ja-jp/solutions/finance/","financial services",{"title":193,"links":627},[628,630,632,634,637,639,641,643,645,647,649,651],{"text":205,"config":629},{"href":207,"dataGaName":208,"dataGaLocation":469},{"text":210,"config":631},{"href":212,"dataGaName":213,"dataGaLocation":469},{"text":215,"config":633},{"href":217,"dataGaName":218,"dataGaLocation":469},{"text":220,"config":635},{"href":222,"dataGaName":636,"dataGaLocation":469},"docs",{"text":243,"config":638},{"href":245,"dataGaName":246,"dataGaLocation":469},{"text":238,"config":640},{"href":240,"dataGaName":241,"dataGaLocation":469},{"text":248,"config":642},{"href":250,"dataGaName":251,"dataGaLocation":469},{"text":256,"config":644},{"href":258,"dataGaName":259,"dataGaLocation":469},{"text":261,"config":646},{"href":263,"dataGaName":264,"dataGaLocation":469},{"text":266,"config":648},{"href":268,"dataGaName":269,"dataGaLocation":469},{"text":271,"config":650},{"href":273,"dataGaName":274,"dataGaLocation":469},{"text":276,"config":652},{"href":278,"dataGaName":279,"dataGaLocation":469},{"title":294,"links":654},[655,657,659,661,663,665,667,671,676,678,680,682],{"text":301,"config":656},{"href":303,"dataGaName":296,"dataGaLocation":469},{"text":306,"config":658},{"href":308,"dataGaName":309,"dataGaLocation":469},{"text":314,"config":660},{"href":316,"dataGaName":317,"dataGaLocation":469},{"text":319,"config":662},{"href":321,"dataGaName":322,"dataGaLocation":469},{"text":324,"config":664},{"href":326,"dataGaName":327,"dataGaLocation":469},{"text":329,"config":666},{"href":331,"dataGaName":332,"dataGaLocation":469},{"text":668,"config":669},"Sustainability",{"href":670,"dataGaName":668,"dataGaLocation":469},"/sustainability/",{"text":672,"config":673},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":674,"dataGaName":675,"dataGaLocation":469},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":334,"config":677},{"href":336,"dataGaName":337,"dataGaLocation":469},{"text":344,"config":679},{"href":346,"dataGaName":347,"dataGaLocation":469},{"text":349,"config":681},{"href":351,"dataGaName":352,"dataGaLocation":469},{"text":683,"config":684},"現代奴隷制の透明性に関する声明",{"href":685,"dataGaName":686,"dataGaLocation":469},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":688},[689,691,694],{"text":517,"config":690},{"href":519,"dataGaName":520,"dataGaLocation":469},{"text":692,"config":693},"Cookieの設定",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":29},{"text":522,"config":695},{"href":524,"dataGaName":525,"dataGaLocation":469},[697],{"id":698,"title":9,"body":27,"config":699,"content":701,"description":27,"extension":26,"meta":705,"navigation":29,"path":706,"seo":707,"stem":708,"__hash__":709},"blogAuthors/en-us/blog/authors/itzik-gan-baruch.yml",{"template":700},"BlogAuthor",{"name":9,"config":702},{"headshot":703,"ctfId":704},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658921/Blog/Author%20Headshots/iganbaruch-headshot.jpg","iganbaruch",{},"/en-us/blog/authors/itzik-gan-baruch",{},"en-us/blog/authors/itzik-gan-baruch","bz9VMiTQ1ixvnoxUFk0jiUcnLG3oQsymgXNCqyRqfsk",[711,726,741],{"content":712,"config":724},{"heroImage":713,"body":714,"authors":715,"updatedDate":718,"date":719,"title":720,"tags":721,"description":723,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png","Azure DevOpsからGitLabへの移行は困難な作業のように思えるかもしれませんが、適切なアプローチとツールを使用すれば、スムーズかつ効率的に進められます。このガイドでは、Azure DevOpsからGitLabへプロジェクト、リポジトリ、パイプラインを正常に移行するために必要な手順を説明します。\n\n## 概要\n\nGitLabは、Azure DevOps（ADO）からプロジェクトを移行するための[Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)([GitLabプロフェッショナルサービス（PS）](https://about.gitlab.com/ja-jp/professional-services/)によって管理）と[組み込みのGitリポジトリインポート](https://docs.gitlab.com/ja-jp/user/project/import/repo_by_url/)の両方を提供しています。これらのオプションは、リポジトリごとまたは一括移行をサポートし、Gitコミット履歴、ブランチ、タグを保持します。Congregateとプロフェッショナルサービスのツールを使用すると、Wiki、作業アイテム、CI/CD変数、コンテナイメージ、パッケージ、パイプラインなどの追加アセットもサポートされます（この[機能マトリクス](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)を参照）。このガイドを参照すれば、移行を計画・実行し、移行後のフォローアップタスクを完了できます。\n\nADOからGitLabへ移行する企業は、一般的に複数フェーズのアプローチに従います：\n\n* CongregateまたはGitLabの組み込みリポジトリ移行を使用して、ADOからGitLabにリポジトリを移行します。\n* AzureパイプラインからGitLab CI/CDにパイプラインを移行します。\n* ボード、作業アイテム、アーティファクトなどの残りのアセットを、GitLabのイシュー、エピック、パッケージレジストリ、コンテナレジストリに移行します。\n\n移行フェーズの概要:\n\n```mermaid\ngraph LR\n subgraph Prerequisites\n direction TB\n A[\"IDプロバイダー（IdP）を設定し\u003Cbr/>ユーザーをプロビジョニング\"]\n A --> B[\"Runnerとサードパーティ\u003Cbr/>インテグレーションを設定\"]\n B --> I[\"ユーザーの有効化と\u003Cbr/>変更管理\"]\n end\n \n subgraph MigrationPhase[\"移行フェーズ\"]\n direction TB\n C[\"ソースコードを移行\"]\n C --> D[\"コントリビューションを保持し\u003Cbr/>履歴をフォーマット\"]\n D --> E[\"作業アイテムを移行し\u003Cbr/>\u003Ca href=\"https://docs.gitlab.com/ja-jp/topics/plan_and_track/\">GitLab Plan\u003Cbr/>および作業追跡\u003C/a>にマッピング\"]\n end\n \n subgraph PostMigration[\"移行後の手順\"]\n direction TB\n F[\"ADOパイプラインを\u003Cbr/>GitLab CIに作成または変換\"]\n F --> G[\"その他のアセット、パッケージ、\u003Cbr/>コンテナイメージを移行\"]\n G --> H[\"\u003Ca href=\"https://docs.gitlab.com/ja-jp/user/application_security/secure_your_application/\">セキュリティ\u003C/a>と\u003Cbr/>SDLC改善を導入\"]\n end\n \n Prerequisites --> MigrationPhase\n MigrationPhase --> PostMigration\n\n style A fill:#FC6D26\n style B fill:#FC6D26\n style I fill:#FC6D26\n style C fill:#8C929D\n style D fill:#8C929D\n style E fill:#8C929D\n style F fill:#FFA500\n style G fill:#FFA500\n style H fill:#FFA500\n```\n\n## 移行の計画\n\n**移行を計画するにあたり、次の質問を検討します:**\n\n* 移行をいつまでに完了する必要があるか?\n* 何が移行されるかを理解しているか?\n* 誰が移行を実行するか?\n* GitLabでどのような組織構造を望むか?\n* 考慮すべき制約、制限、落とし穴はあるか?\n\nタイムラインを決定します。これは移行アプローチを大きく左右します。ADOとGitLabの両プラットフォームに精通したチャンピオンやグループ（アーリーアダプターなど）を特定し、導入を推進してアドバイスを提供してもらいます。\n\n**移行が必要なものをインベントリ化:**\n\n* リポジトリ、プルリクエスト、コントリビューターの数\n* 作業アイテムとパイプラインの数と複雑さ\n* リポジトリのサイズと依存関係\n* 重要なインテグレーションとRunner要件（特定の機能を持つエージェントプール）\n\nGitLab プロフェッショナルサービスの[Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)ツールを使用して、リポジトリ、PR数、コントリビューターリスト、パイプライン数、作業アイテム、CI/CD変数などを含むAzure DevOps組織全体の完全なインベントリを作成します。GitLabプロフェッショナルサービスチームと連携している場合は、このレポートをエンゲージメントマネージャーまたはテクニカルアーキテクトと共有し、移行計画に役立ててください。\n\n移行のタイミングは、主にプルリクエスト数、リポジトリサイズ、コントリビューション量（PRのコメント、作業アイテムなど）によって決まります。たとえば、PRが少なくコントリビューターが限られた1,000の小規模リポジトリは、数万のPRと数千のコントリビューターを含む少数のリポジトリよりもはるかに高速に移行できます。インベントリデータを使用して作業量を見積もり、本番移行を進める前にテスト実行を計画します。\n\nインベントリを希望のタイムラインと比較し、すべてのリポジトリを一度に移行するか、バッチで移行するかを決定します。チームが同時に移行できない場合は、チームのスケジュールに合わせて移行をバッチ化し、段階的に実行します。たとえば、プロフェッショナルサービスのエンゲージメントでは、複雑さを管理し、[GitLab](https://docs.gitlab.com/ja-jp/security/rate_limits/)と[ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)の両方のAPIレート制限を尊重するために、200〜300プロジェクト単位の段階に分割して移行を実施します。\n\nGitLabの組み込み[リポジトリインポーター](https://docs.gitlab.com/ja-jp/user/project/import/repo_by_url/)は、Gitリポジトリ（コミット、ブランチ、タグ）を1つずつ移行します。Congregateは、可能な限りプルリクエスト（GitLabではマージリクエストとして知られています）、コメント、関連メタデータを保持するように設計されています。シンプルな組み込みリポジトリインポートは、Gitデータ（履歴、ブランチ、タグ）のみに焦点を当てています。\n\n**通常、個別の移行または手動での再作成が必要な項目:**\n\n* Azureパイプライン - 同等のGitLab CI/CDパイプラインを作成([CI/CD YAML](https://docs.gitlab.com/ja-jp/ci/yaml/)または[CI/CDコンポーネント](https://docs.gitlab.com/ja-jp/ci/components/)を参照)。または、CongregateのAIベースのパイプライン変換を使用することを検討してください。\n* 作業アイテムとボード - GitLabのイシュー、エピック、イシュー ボードにマッピング。\n* アーティファクト、コンテナイメージ(ACR) - GitLabパッケージレジストリまたはコンテナレジストリに移行。\n* サービスフックと外部インテグレーション - GitLabで再作成。\n* [権限モデル](https://docs.gitlab.com/ja-jp/user/permissions/)はADOとGitLabで異なります。完全な保持を想定するのではなく、権限マッピングを確認および計画してください。\n\n各ツール（Congregateと組み込みインポート）が何を移行するかを確認し、ニーズに合ったものを選択します。手動で移行または再作成する必要があるデータやインテグレーションのリストを作成します。\n\n**誰が移行を実行するか?**\n\n移行は通常、GitLabグループオーナーまたはインスタンス管理者、または移行先グループ/プロジェクトに必要な権限を付与された指定の移行担当者によって実行されます。CongregateとGitLabインポートAPIには、Azure DevOpsとGitLabの両方の有効な認証トークンが必要です。\n\n* グループオーナー/管理者が移行を実行するか、特定のチーム/個人に委任アクセスを付与するかを決定します。\n* 移行担当者が、選択した移行ツールに必要なスコープ（api/read_repositoryスコープやツール固有の要件など）を持つ個人アクセストークン（Azure DevOpsとGitLab）を正しく設定していることを確認します。\n* 小規模なパイロット移行でトークンと権限をテストします。\n\n**注:** CongregateはADO移行のためにファイルベースのインポート機能を活用し、実行にはインスタンス管理者権限が必要です（[ドキュメントを参照](https://docs.gitlab.com/ja-jp/user/project/settings/import_export/#migrate-projects-by-uploading-an-export-file)）。GitLab.comに移行する場合は、プロフェッショナルサービスの利用を検討してください。詳細については、[Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)を参照してください。管理者以外のアカウントでは、コントリビューションの帰属を保持できません。\n\n**GitLabでどのような組織構造を望むか?**\n\nADO構造をGitLab構造に直接マッピングすることは可能ですが、移行中に構造を合理化および簡素化することをお勧めします。チームがGitLabでどのように作業するかを検討し、コラボレーションとアクセス管理を促進する構造を設計します。ADO構造をGitLab構造にマッピングする方法は次のとおりです。\n\n```mermaid\ngraph TD\n subgraph GitLab\n direction TB\n A[\"トップレベルグループ\"]\n B[\"サブグループ（オプション）\"]\n C[\"プロジェクト\"]\n A --> B\n A --> C\n B --> C\n end\n\n subgraph AzureDevOps[\"Azure DevOps\"]\n direction TB\n F[\"組織\"]\n G[\"プロジェクト\"]\n H[\"リポジトリ\"]\n F --> G\n G --> H\n end\n\n style A fill:#FC6D26\n style B fill:#FC6D26\n style C fill:#FC6D26\n style F fill:#8C929D\n style G fill:#8C929D\n style H fill:#8C929D\n```\n\n推奨アプローチ:\n\n* 各ADO組織をGitLabグループ（または少数のグループ）にマッピングし、多数の小さなグループには分割しないでください。ADOチームプロジェクトごとにGitLabグループを作成することは避けてください。移行をGitLab構造を合理化する機会として活用してください。\n* サブグループとプロジェクトレベルの権限を使用して、関連リポジトリをグループ化します。\n* GitLabグループとグループメンバーシップ（グループとサブグループ）を使用してプロジェクトのセットへのアクセスを管理し、チームプロジェクトごとに1つのグループを作成しないでください。\n* GitLabの[権限](https://docs.gitlab.com/ja-jp/user/permissions/)を確認し、[SAML Group Links](https://docs.gitlab.com/ja-jp/user/group/saml_sso/group_sync/)を検討して、GitLabインスタンス（またはGitLab.comネームスペース）のエンタープライズRBACモデルを実装します。\n\n**ADOボードと作業アイテム: 移行の状態**\n\n作業アイテムがADOからGitLab Plan（イシュー、エピック、ボード）にどのように移行されるかを理解することが重要です。\n\n* ADOボードと作業アイテムは、GitLabのイシュー、エピック、イシューボードにマッピングされます。ワークフローとボード設定がどのように変換されるかを計画します。\n* ADOのエピックと機能は、GitLabのエピックになります。\n* その他の作業アイテムタイプ（ユーザーストーリー、タスク、バグなど）は、プロジェクトスコープのイシューになります。\n* ほとんどの標準フィールドが保持されます。サポートされている場合、選択したカスタムフィールドを移行できます。\n* 親子関係が保持されるため、エピックはすべての関連イシューを参照します。\n* プルリクエストへのリンクはマージリクエストリンクに変換され、開発のトレーサビリティが維持されます。\n\n例: 個別の作業アイテムのGitLabイシューへの移行（フィールドの正確性と関係性を含む）:\n\n![例: 個別の作業アイテムのGitLabイシューへの移行](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\nバッチ処理のガイダンス:\n\n* バッチで移行を実行する必要がある場合は、新しいグループ/サブグループ構造を使用してバッチを定義します（たとえば、ADO組織ごと、または製品領域ごと）。\n* インベントリレポートを使用してバッチ選択を推進し、スケールアップする前に各バッチをパイロット移行でテストします。\n\n**パイプライン移行**\n\nCongregateは最近、Azure DevOpsからGitLab CI/CDへのマルチステージYAMLパイプラインのAI搭載変換を[導入しました](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298)。この自動変換は、シンプルな単一ファイルパイプラインに最適で、本番環境対応の`.gitlab-ci.yml`ファイルではなく、動作する出発点を提供するように設計されています。このツールは、機能的に同等のGitLabパイプラインを生成し、その後特定のニーズに合わせて調整および最適化できます。\n\n* Azureパイプライン YAMLを`.gitlab-ci.yml`形式に自動変換します。\n* シンプルな単一ファイルパイプライン設定に最適です。\n* 移行を加速するためのボイラープレートを提供し、最終的な本番環境アーティファクトではありません。\n* 複雑なシナリオ、カスタムタスク、エンタープライズ要件については、レビューや調整が必要です。\n* Azure DevOpsのクラシックリリースパイプラインはサポートしていません — 最初に[マルチステージYAMLに変換](https://learn.microsoft.com/en-us/azure/devops/pipelines/release/from-classic-pipelines?view=azure-devops)してください。\n\nリポジトリオーナーは、初期変換後にパイプラインをさらに最適化および強化するために、[GitLab CI/CDドキュメント](https://docs.gitlab.com/ja-jp/ci/)を確認する必要があります。\n\n変換されたパイプラインの例:\n\n```yml\n# azure-pipelines.yml\n\ntrigger:\n - main\n\nvariables:\n imageName: myapp\n\nstages:\n - stage: Build\n jobs:\n - job: Build\n pool:\n vmImage: 'ubuntu-latest'\n steps:\n - checkout: self\n\n - task: Docker@2\n displayName: Build Docker image\n inputs:\n command: build\n repository: $(imageName)\n Dockerfile: '**/Dockerfile'\n tags: |\n $(Build.BuildId)\n\n - stage: Test\n jobs:\n - job: Test\n pool:\n vmImage: 'ubuntu-latest'\n steps:\n - checkout: self\n\n # Example: run tests inside the container\n - script: |\n docker run --rm $(imageName):$(Build.BuildId) npm test\n displayName: Run tests\n\n - stage: Push\n jobs:\n - job: Push\n pool:\n vmImage: 'ubuntu-latest'\n steps:\n - checkout: self\n\n - task: Docker@2\n displayName: Login to ACR\n inputs:\n command: login\n containerRegistry: '\u003Cyour-acr-service-connection>'\n\n - task: Docker@2\n displayName: Push image to ACR\n inputs:\n command: push\n repository: $(imageName)\n tags: |\n $(Build.BuildId)\n```\n\n```yaml\n# .gitlab-ci.yml\n\nvariables:\n imageName: myapp\n\nstages:\n - build\n - test\n - push\n\nbuild:\n stage: build\n image: docker:latest\n services:\n - docker:dind\n script:\n - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .\n only:\n - main\n\ntest:\n stage: test\n image: docker:latest\n services:\n - docker:dind\n script:\n - docker run --rm $imageName:$CI_PIPELINE_ID npm test\n only:\n - main\n\npush:\n stage: push\n image: docker:latest\n services:\n - docker:dind\n before_script:\n - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n script:\n - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n only:\n - main\n```\n\n**最終チェックリスト:**\n\n* タイムラインとバッチ戦略を決定します。\n* リポジトリ、PR、コントリビューターの完全なインベントリを作成します。\n* スコープ（PRとメタデータ vs Gitデータのみ）に基づいて、Congregateまたは組み込みインポートを選択します。\n* 誰が移行を実行するかを決定し、トークン/権限が設定されていることを確認します。\n* 個別に移行する必要があるアセット（パイプライン、作業アイテム、アーティファクト、フック）を特定し、それらの取り組みを計画します。\n* パイロット移行を実行し、結果を検証してから、計画に従ってスケールします。\n\n## 移行の実行\n\n計画後、トライアル実行から始めて、段階的に移行を実行します。トライアル移行は、組織固有の問題を早期に明らかにし、期間を測定し、結果を検証し、本番環境前にアプローチを微調整する上で役立ちます。\n\nトライアル移行が検証する内容:\n\n* 特定のリポジトリと関連アセットが正常に移行されるかどうか（履歴、ブランチ、タグ。Congregateを使用する場合はMR/コメントも含む）\n* 移行先がすぐに使用可能かどうか（権限、Runner、CI/CD変数、インテグレーション）\n* スケジュールとステークホルダーの期待値を設定するため、各バッチにかかる時間。\n\nダウンタイムのガイダンス:\n\n* GitLabの組み込みGitインポートとCongregateは、本質的にダウンタイムを必要としません。\n* 本番環境の場合では、ADOの変更を凍結（ブランチ保護または読み取り専用）して、移行中に見逃されたコミット、PR更新、作業アイテムの作成を回避します。\n* トライアル実行では凍結は必要なく、いつでも実行できます。\n\nバッチ処理のガイダンス:\n\n* 経過時間を短縮するために、トライアルバッチを連続して実行します。チームは非同期で結果を検証できます。\n* 計画したグループ/サブグループ構造を使用してバッチを定義し、APIレート制限を遵守します。\n\n推奨手順:\n\n1. GitLabでトライアル用のテスト先を作成:\n\n* GitLab.com: 専用グループ/ネームスペースを作成（例: my-org-sandbox）\n* Self-managed: トップレベルグループまたは必要に応じて別のテストインスタンスを作成\n\n2. 認証の準備:\n\n* 必要なスコープを持つAzure DevOps PAT\n* apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）```suggestion:-0+0\n* apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）\n\n3. トライアル移行の実行:\n\n* リポジトリのみ: GitLabの組み込みインポート（URLによるレポジトリインポート）を使用\n* リポジトリ + PR/MRおよび追加アセット: Congregateを使用\n\n4. トライアル後のフォローアップ:\n\n* リポジトリ履歴、ブランチ、タグ、マージリクエスト（移行された場合）、イシュー/エピック（移行された場合）、ラベル、関係性を確認します。\n* 権限/ロール、保護ブランチ、必要な承認、Runner/タグ、変数/シークレット、インテグレーション/Webhookを確認します。\n* パイプライン（`.gitlab-ci.yml`）または（該当する場合は）変換されたパイプラインを検証します。\n\n5. ユーザーに機能とデータの正確性を検証してもらいます。\n6. トライアル中に発見された問題を解決し、実行手順を更新します。\n7. ネットワークとセキュリティ:\n\n* 移行先の環境がIP許可リストを使用している場合、インポートが成功するように、移行ホストと必要なRunner/インテグレーションのIPを追加します。\n\n8. 本番環境への移行は段階的に実行:\n\n* 各段階で、ADOで変更凍結を実施します。\n* 進捗とログを監視します。レート制限に達した場合は、再試行するか、バッチサイズを調整します。\n\n9. オプション: 完了後、サンドボックスグループを削除またはアーカイブします。\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## GitLabとAzure DevOpsの用語リファレンス\n\n| GitLab | Azure DevOps | 類似点と主な違い |\n| ------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------- |\n| グループ | 組織 | トップレベルのネームスペース、メンバーシップ、ポリシー。ADO組織にはプロジェクトが含まれ、GitLabグループにはサブグループとプロジェクトが含まれます。 |\n| グループまたはサブグループ | プロジェクト | 論理コンテナ、権限境界。ADOプロジェクトは多数のリポジトリを保持し、GitLabグループ/サブグループは多数のプロジェクトを整理します。 |\n| Project（Gitリポジトリを含む） | リポジトリ（プロジェクト内） | Git履歴、ブランチ、タグ。GitLabでは、「プロジェクト」はリポジトリとイシュー、CI/CD、Wikiなどを含みます。プロジェクトごとに1つのリポジトリ。 |\n| マージリクエスト（MR） | プルリクエスト（PR） | コードレビュー、ディスカッション、承認。MRルールには、承認、必要なパイプライン、コードオーナーが含まれます。 |\n| 保護されたブランチ、MR承認ルール、ステータスチェック | ブランチポリシー | レビューとチェックを強制。GitLabは保護 + 承認ルール + 必要なステータスチェックを組み合わせます。 |\n| GitLab CI/CD | Azureパイプライン | YAMLパイプライン、ステージ/ジョブ、ログ。ADOにはクラシックUIパイプラインもあり、GitLabは.gitlab-ci.ymlを中心にしています。 |\n| .gitlab-ci.yml | azure-pipelines.yml | ステージ/ジョブ/トリガーを定義。構文/機能が異なります。ジョブ、変数、アーティファクト、トリガーをマッピングします。 |\n| Runner（共有/特定） | エージェント/エージェントプール | マシン/コンテナでジョブを実行。デマンド（ADO）対タグ（GitLab）でターゲット。登録/スコーピングが異なります。 |\n| CI/CD変数（プロジェクト/グループ/インスタンス）、保護/マスク | パイプライン変数、変数グループ、ライブラリ | 設定/シークレットをジョブに渡します。GitLabはグループ継承とマスキング/保護フラグをサポートします。 |\n| インテグレーション、CI/CD変数、デプロイキー | サービス接続 | サービス/クラウドへの外部認証。インテグレーションまたは変数にマッピング。クラウド固有のヘルパーが利用可能。 |\n| 環境とデプロイメント（保護された環境） | 環境（承認付き） | デプロイターゲット/履歴を追跡。GitLabでは保護された環境と手動ジョブを介した承認。 |\n| リリース（タグ + ノート） | リリース（クラシックまたはパイプライン） | バージョン管理されたノート/アーティファクト。GitLabリリースはタグに結び付けられ、デプロイメントは個別に追跡されます。 |\n| ジョブアーティファクト | パイプラインアーティファクト | ジョブ出力を保持。保持/有効期限はジョブまたはプロジェクトごとに設定されます。 |\n| パッケージレジストリ（NuGet/npm/Maven/PyPI/Composerなど） | Azureアーティファクト（NuGet/npm/Mavenなど） | パッケージホスティング。認証/ネームスペースが異なります。パッケージタイプごとに移行します。 |\n| GitLabコンテナレジストリ | Azureコンテナレジストリ（ACR）または他 | OCIイメージ。GitLabはプロジェクト/グループごとのレジストリを提供します。 |\n| イシューボード | ボード | 列で作業を視覚化。GitLabボードはラベル駆動型で、プロジェクト/グループごとに複数のボードがあります。 |\n| イシュー（タイプ/ラベル）、エピック | 作業アイテム（ユーザーストーリー/バグ/タスク） | 作業単位を追跡。ADOタイプ/フィールドをラベル/カスタムフィールドにマッピング。エピックはグループレベルです。 |\n| エピック、親子イシュー | エピック/機能 | 作業の階層。スキーマが異なります。エピックとイシュー関係を使用します。 |\n| マイルストーンとイテレーション | イテレーションパス | タイムボックス化。GitLabイテレーション（グループ機能）またはプロジェクト/グループごとのマイルストーン。 |\n| ラベル（スコープ付きラベル） | エリアパス | 分類/所有権。階層エリアをスコープ付きラベルに置き換えます。 |\n| プロジェクト/グループWiki | プロジェクトWiki | マークダウンWiki。両方ともリポジトリでバックアップされます。レイアウト/認証がわずかに異なります。 |\n| CI経由のテストレポート、要件/テスト管理、インテグレーション | テストプラン/ケース/実行 | QA証拠/トレーサビリティ。ADOテストプランとの1対1対応はありません。多くの場合、CIレポート + イシュー/要件を使用します。 |\n| ロール（オーナー/メンテナー/デベロッパー/レポーター/ゲスト） + カスタムロール | アクセスレベル + きめ細かい権限 | 読み取り/書き込み/管理を制御。モデルが異なります。グループ継承と保護されたリソースを活用します。 |\n| Webhook | サービスフック | イベント駆動型インテグレーション。イベント名/ペイロードが異なります。エンドポイントを再設定します。 |\n| 高度な検索 | コードサーチ | フルテキストリポジトリ検索。Self-managed版のGitLabでは、高度な機能にElasticsearch/OpenSearchが必要な場合があります。 |",[716,717],"Evgeny Rudinsky","Michael Leopard","2025-12-08","2025-12-03","ガイド: Azure DevOpsからGitLabへの移行",[24,722,22],"git","GitLabプロフェッショナルサービスの移行ツールを使用してAzure DevOpsからGitLabへの完全な移行を実行する方法を学びます — 計画、実行から移行後のフォローアップタスクまで。",{"featured":29,"template":15,"slug":725},"migration-from-azure-devops-to-gitlab",{"content":727,"config":739},{"heroImage":728,"body":729,"authors":730,"updatedDate":732,"date":733,"title":734,"tags":735,"description":738,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1764108112/tyntnsy3xotlmehtnfkb.png","毎日、GitLabは世界最大のGitLabインスタンスであるGitLab.comにコード変更を最大12回、ダウンタイムなしでデプロイしています。これらのデプロイ管理には、GitLab独自のCI/CDプラットフォームを使用しており、世界中の数百万人のデベロッパーに影響を与えています。このデプロイ頻度は、私たちの主要な品質基準とストレステストとして機能しています。また、お客様は数週間や数か月待つことなく、開発から数時間以内で新機能にアクセスできるようになります。組織がDevOpsワークフローにGitLabを利用する場合、私たち自身のインフラストラクチャで大規模に実証されたプラットフォームを使用していることになります。この記事では、このデプロイの複雑さを処理するために、GitLab CI/CDのコア機能を使用して自動化されたデプロイパイプラインを構築した方法をご紹介します。\n\n\n## デプロイ速度がもたらすビジネスケース\n\n\n当社の実践から見えるもの：私たちのデプロイ頻度は単なるエンジニアリング指標ではなく、ビジネス上の必須要件です。迅速なデプロイサイクルにより、お客様からのフィードバックに数時間以内に対応し、セキュリティパッチを即座に提供し、新機能を本番環境で検証してからスケールすることができます。\n\n\nお客様が得られる価値：GitLab.comへのすべてのデプロイは、ユーザーに推奨するデプロイプラクティスを検証しています。GitLabのデプロイ機能を使用する場合、数百万のgit操作、CI/CDパイプライン、ユーザーインタラクションを日々処理する実証済みのアプローチを使用していることになります。以下のメリットがあります:\n\n- 最新機能が即座に利用可能：新しい機能は四半期ごとのリリースサイクルではなく、完成してから数時間以内に提供されます\n- 大規模環境で実証された信頼性：機能がGitLab.comで動作すれば、お客様の環境でも信頼できます\n- GitLabの完全な価値：ゼロダウンタイムデプロイにより、更新中でもDevOpsプラットフォームへのアクセスが失われることはありません\n- 実環境でテストされたプラクティス：当社のデプロイドキュメントは理論ではなく、世界最大のGitLabインスタンスを実際に運用する方法そのものです\n\n\n## コードフローアーキテクチャ\n\n\nデプロイパイプラインは、複数のステージを経て構造化された進行に従います。各ステージは、コード提案から本番環境へのデプロイまでの過程におけるチェックポイントとして機能します。\n\n```mermaid\n graph TD\n A[コード提案] --> B[マージリクエスト作成]\n B --> C[パイプライントリガー]\n C --> D[ビルド ＆ テスト]\n D --> E{スペック/統合/QAテスト合格？}\n E -->|いいえ| F[フィードバックループ]\n F --> B\n E -->|はい| G[デフォルトブランチへマージ]\n G -->|定期的| H[Auto-Deployブランチ]\n\n subgraph \"デプロイパイプライン\"\n H --> I[パッケージ作成]\n I --> K[Canary環境]\n K --> L[QA検証]\n L --> M[main環境]\n\n end\n```\n\n\n## デプロイパイプラインの構成\n\nデプロイアプローチでは、GitLabのネイティブCI/CD機能を使用して、ハイブリッドインフラストラクチャ全体で複雑なデプロイを調整します。\nその実装方法をご紹介します。\n\n\n### ビルド\n\n\nGitLabのビルドは、それ自体が複雑なトピックであるため、ここでは概要レベルで説明します。\n\nOmnibusパッケージとCloud Native GitLab(CNG)イメージの両方をビルドします。OmnibusパッケージはGitalyフリート(Gitストレージレイヤー)にデプロイされ、CNGイメージは他のすべてのコンポーネントをコンテナ化されたワークロードとして実行します。PostgresやRedisなどの他のステートフルサービスは非常に大規模になったため、専任チームが個別に管理しています。GitLab.comの場合、これらのシステムはAuto-Deploy手順中にはデプロイされません。\n\n\n`gitlab-org/gitlab`を定期的に確認し、デフォルトブランチで成功した(「グリーン」)パイプラインを持つ最新のコミットを検索するスケジュールされたパイプラインがあります。グリーンパイプラインは、GitLabのすべてのコンポーネントが包括的なテスト群に成功したことを示します。次に、そのコミットから**auto-deployブランチ**を作成します。\n\n\nこれにより一連のイベントがトリガーされます。主に、このパッケージとモノリスの一部であるすべてのコンポーネントをビルドする必要があります。\n別のスケジュールされたパイプラインが、最新のビルドされたパッケージを選択し、デプロイパイプラインを開始します。手順としては、このようにシンプルに見えます：\n\n\n```mermaid\n graph LR\n A[ブランチ作成] --> B[ビルド]\n B --> C[ビルドされたパッケージを選択]\n C --> D[デプロイパイプラインを開始]\n```\n\n\nビルドには時間がかかり、さまざまな状況によりデプロイが変動する可能性があるため、最新のビルドをデプロイするように選択しています。技術的には、実際にデプロイされるよりも多くのGitLabのバージョンを.com用にビルドしています。これにより、常に準備が整ったパッケージが用意され、.comに対して完全に継続的にデリバリーされる製品に最も近い状態を実現できます。\n\n\n### 環境ベースの検証とCanary戦略\n\n品質保証(QA)は単なる後付けではなく、開発からデプロイまでのすべてのレイヤーに組み込まれています。QAプロセスでは、ユニットテスト、統合テスト、GitLabの機能との実際のユーザーインタラクションをシミュレートするエンドツーエンドテストを含む自動化されたテスト群を活用しています。しかし、デプロイパイプラインにとってさらに重要なのは、QAプロセスが環境ベースの検証を通じてCanary戦略と密接に連携していることです。\n\n\n検証アプローチの一環として、GitLabのネイティブ[Canaryデプロイ](https://docs.gitlab.com/ja-jp/user/project/canary_deployments/)を活用し、完全な本番環境へのデプロイ前に、限定されたトラフィックで変更を制御しながら検証できるようにしています。[すべてのトラフィックの約5%をCanaryステージに送信しています](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/#environments-canary-stage)。このアプローチはデータベースマイグレーションの複雑性を高めますが、Canaryデプロイを成功させることで、信頼性の高い製品をシームレスにデプロイすることができます。\n\nGitLabで使用するCanaryデプロイ機能は、本番環境における最も複雑なデプロイメントシナリオの管理を通じて改良されたものです。アプリケーション用にCanaryデプロイを実装する場合、大規模環境で実証済みのパターンを使用していることになります。\n\n当社のデプロイプロセスは、段階的ロールアウト戦略に従います:\n\n1. **ステージング環境 Canary:** 初期検証環境\n\n2. **本番環境 Canary:** 限定された本番トラフィック\n\n3. **ステージング環境 main:** ステージング環境への完全デプロイ\n\n4. **本番環境 main:** 本番環境への完全ロールアウト\n\n```mermaid\n graph TD\n C[ステージング環境 Canaryデプロイ]\n C --> D[QA スモーク main Testステージ]\n C --> E[QA スモーク Canary Testステージ]\n D --> F\n E --> F{テスト合格？}\n F -->|はい| G[本番環境 Canary デプロイ]\n G --> S[QA スモーク main Testステージ]\n G --> T[QA スモーク Canary Testステージ]\n F -->|いいえ| H[イシュー作成]\n H --> K[修正＆バックポート]\n K --> C\n\n S --> M[Canary トラフィック監視]\n T --> M[Canary トラフィック監視ベイク期間]\n M --> U[本番環境安全性チェック]\n U --> N[ステージング環境 main]\n N --> V[本番環境 main]\n```\n\nQA検証は、この段階的デプロイプロセス全体の複数のチェックポイントで行われます。各Canaryデプロイ後、そしてデプロイ後のマイグレーション実施後に再度検証を行います。この多層的なアプローチにより、デプロイ戦略の各フェーズに独自のセーフティーネットが確保されます。GitLabの[包括的なテスト手法](https://handbook.gitlab.com/handbook/engineering/testing/)については、ハンドブックで詳しく説明しています。\n\n## デプロイパイプライン\n\nデプロイパイプライン全体で対処している課題についてご紹介します。\n\n### 技術アーキテクチャに関する考慮事項\n\n GitLab.comは、大規模な実環境でのデプロイの複雑性を体現しています。既知の最大規模のGitLabインスタンスとして、デプロイには公式のGitLab HelmチャートとLinuxパッケージを使用しており、これらはお客様が使用するものと同じアーティファクトです。[GitLab.comアーキテクチャ](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture)については、ハンドブックで詳しく説明しています。このハイブリッドアプローチにより、デプロイパイプラインは同一のデプロイサイクルでコンテナ化されたサービスと従来のLinuxサービスの両方をインテリジェントに処理する必要があります。\n\n **大規模なドッグフーディング:** [ゼロダウンタイムのアップグレード](https://docs.gitlab.com/ja-jp/update/zero_downtime/)用にドキュメント化したものと同じ手順を使用してデプロイしています。もし私たちにとってスムーズに機能しないものがあれば、お客様にも推奨しません。この自己規律により、デプロイツールの継続的な改善が促進されています。\n\n すべての環境とステージのアップグレードで、以下のステージが実行されます：\n\n```mermaid\n graph LR\n a[Prep] --> c[通常 Migrations - Canaryステージのみ]\n a --> f[Assets - Canaryステージのみ]\n c --> d[Gitaly]\n d --> k8s\n\n subgraph subGraph0[\"VMワークロード\"]\n d[\"Gitaly\"]\n end\n\n subgraph subGraph1[\"Kubernetesワークロード\"]\n k8s[\"k8s\"]\n end\n\n subgraph fleet[\"フリート\"]\n subGraph0\n subGraph1\n end\n```\n\n\n**ステージの詳細:**\n\n\n- **Prep：** デプロイの準備状況を検証し、デプロイ前のチェックを実行します\n\n- **Migrations：** データベースの通常マイグレーションを実行します。これはCanaryステージでのみ実行されます。Canaryステージとmainステージは同じデータベースを共有しているため、mainステージのデプロイ時にはこれらの変更がすでに利用可能であり、タスクを繰り返す必要はありません。\n\n- **Assets：** すべての静的アセットにGCSバケットを活用しています。新しいアセットが作成された場合、バケットにアップロードし、Canaryステージですぐに利用できるようにします。アセットにWebPackを活用し、アセットの命名にSHAを適切に活用しているため、古いアセットを上書きする心配はありません。したがって、古いアセットは古いデプロイで引き続き利用可能であり、新しいアセットはCanaryがデプロイを開始するとすぐに利用可能になります。これはCanaryステージのデプロイ中にのみ実行されます。Canaryステージとmainステージは同じアセットストレージを共有しているため、mainステージのデプロイ時にはこれらの変更はすでに利用可能です。\n\n- **Gitaly：** 各GitalyノードでOmnibus LinuxパッケージによりGitaly仮想マシンスのトレージレイヤーを更新します。このサービスは[`git`とバンドル](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/git-execution-environments.md)されているため、特殊です。したがって、このサービスがアトミックアップグレードを実行可能かを確認する必要があります。[Gitalyのラッパー](https://gitlab.com/gitlab-org/gitaly/-/tree/master/cmd/gitaly-wrapper)を活用し、新しいバージョンのGitalyをインストールし、ライブラリ[`tableflip`](https://github.com/cloudflare/tableflip)を使用しすることで、実行中のGitalyをクリーンにローテーションし、各インスタンスでこのサービスの高可用性を確保しています。\n\n- **Kubernetes：** Helmチャートを使用してコンテナ化されたGitLabコンポーネントをデプロイします。冗長性のために複数のゾーンにまたがる多数のクラスターにデプロイするため、通常これらは被害を最小限に抑えるために個別のステージに分割され、重大な問題が検出された場合はデプロイを途中で停止できるようにしています。\n\n\n### マルチバージョン互換性:隠れた課題\n\n\nプロセスを読むと、データベーススキーマがmainステージが認識しているコードより先行している期間があることに気付くでしょう。これは、Canaryステージが既に新しいコードをデプロイし、通常のデータベースマイグレーションを実行しているが、mainステージはまだこれらの新しいデータベース変更を認識していない以前のバージョンのコードを実行しているために発生します。\n\n**実際の例：** マージリクエストに新しい`merge_readiness`フィールドを追加するとします。デプロイ中、一部のサーバーはこのフィールドを期待するコードを実行していますが、他のサーバーはまだその存在を認識していません。これを適切に処理しないと、数百万人のユーザーが使用するGitLab.comが壊れてしまいます。適切に処理すれば、誰も何が起こったか気付きません。\n\nこれは他のほとんどのサービスでも発生します。たとえば、クライアントが複数のリクエストを送信する場合、そのうちの1つがCanaryステージに到達する可能性があります。他のリクエストはmainステージに向けられる可能性があります。これはデプロイとそれほど変わりません。サービスを実行している数千のPodを通過するのにかなりの時間がかかるためです。\n\n\nいくつかの例外を除いて、サービスの大部分は、Canaryでそのコンポーネントのわずかに新しいバージョンを一定期間実行します。ある意味では、これらのシナリオはすべて一時的な状態です。しかし、ライブの本番環境では数時間または数日間持続することがよくあります。したがって、永続的な状態と同じように注意を払って扱う必要があります。どのデプロイ中も、複数のバージョンのGitLabが同時に実行されており、それらすべてが適切に連携する必要があります。\n\n## データベース操作\n\nデータベースマイグレーションは、Canaryデプロイモデルにおいて独特の課題を提示します。新機能をサポートするためのスキーマ変更が必要な一方で、問題が発生した場合のロールバック機能を維持する必要があります。当社のソリューションでは、懸念を慎重に分離しています：\n\n- **通常マイグレーション:** Canaryステージ中に実行され、後方互換性を持つように設計され、可逆的な変更のみで構成されます\n\n- **デプロイ後マイグレーション:** 複数の成功したデプロイ後にのみ実行される「ポイント・オブ・ノーリターン」マイグレーション\n\n\nデータベース変更は、正確さと広範な検証手順により処理されます:\n\n\n```mermaid\n graph LR\n A[通常マイグレーション] --> B[Canaryステージデプロイ]\n B --> C[mainステージデプロイ]\n C --> D[デプロイ後マイグレーション]\n\n```\n\n### デプロイ後マイグレーション\n\n\nGitLabのデプロイには多くのコンポーネントが関与します。GitLabの更新はアトミックではないため、多くのコンポーネントが後方互換性を持つ必要があります。\n\n\nデプロイ後マイグレーションには、簡単にロールバックできない変更(データ変換、カラムの削除、または古いコードバージョンを壊す構造的変更など)が含まれることがよくあります。複数の成功したデプロイを通じて信頼を得た_後_にそれらを実行することで、次を保証します:\n\n\n1. **新しいコードが安定している**ため、ロールバックが必要になる可能性が低い\n\n2. **パフォーマンス特性**が本番環境で十分に理解されている\n\n3. **エッジケース**が発見され対処されている\n\n4. 問題が発生した場合に**影響範囲**が最小限に抑えられる\n\n\nこのアプローチは最適なバランスを提供します。Canaryリリースによる迅速な機能デプロイを可能にしながら、デプロイの安定性に高い信頼を得るまでロールバック機能を維持します。\n\n\n**拡張-移行-縮小パターン:** データベース、フロントエンド、アプリケーション互換性の変更は、慎重に調整された3段階のアプローチに従います。\n\n\n1. **拡張：** 古い構造を機能させたまま、新しい構造（カラム、インデックス）を追加\n\n2. **移行：** 新しい構造を使用する新しいアプリケーションコードをデプロイ\n\n3. **縮小：** すべてが安定した後、デプロイ後マイグレーションで古い構造を削除\n\n**実際の例:** マージリクエストに新しい`merge_readiness`カラムを追加する場合：\n\n1. **拡張：** デフォルト値を持つ新しいカラムを追加。既存のコードはそれを無視\n\n2. **移行：** 古いアプローチをサポートしながら、新しいカラムの読み書きを行うコードをデプロイ\n\n3 **縮小：** 複数の成功したデプロイの後、デプロイ後マイグレーションで古いカラムを削除\n\nすべてのデータベース操作、アプリケーションコード、フロントエンドコードなどは、エンジニアリングが遵守する必要がある一連のガイドラインの対象となります。これらは[マルチバージョン互換性ドキュメント](https://docs.gitlab.com/ja-jp/development/multi_version_compatibility/)で確認できます。\n\n\n## 結果と影響\n\nデプロイインフラストラクチャは測定可能なメリットを提供します:\n\n**GitLabにとって**\n\n* GitLab.comへの1日最大12回のデプロイ\n* 数百万人のデベロッパーにサービスを提供するダウンタイムゼロのデプロイ\n* セキュリティパッチを数日ではなく数時間以内で本番環境に提供可能\n* 一般公開前に大規模な本番環境で検証された新機能\n\n**お客様にとって**\n\n* 独自のアプリケーションに採用できる実証済みのデプロイパターン\n* お客様の環境に到達する前に、世界最大のGitLabインスタンスで実証された機能\n* 理論的なベストプラクティスではなく、実際の本番環境のプラクティスを反映したドキュメント\n* GitLabの推奨アップグレード手順が、あらゆる規模で機能するという確信\n\n## エンジニアリングチームへの重要なポイント\n\nGitLabのデプロイパイプラインは、デプロイ速度と運用の信頼性のバランスをとる洗練されたシステムを表しています。段階的デプロイモデル、包括的なテスト統合、堅牢なロールバック機能により、大規模な信頼性の高いソフトウェア配信の基盤を提供します。\n\n\n同様のシステムを実装するエンジニアリングチームにとって、次のような重要な考慮事項があります:\n\n\n- **自動テスト：** デプロイパイプライン全体にわたる包括的なテストカバレッジ\n\n- **段階的ロールアウト：** リスクを最小限に抑え、迅速な復旧を可能にする段階的デプロイ\n\n- **監視統合：** すべてのデプロイステージにわたる包括的な可観測性\n\n- **インシデント対応：** デプロイ問題の迅速な検出と解決能力\n\n\nGitLabのアーキテクチャは、最新のCI/CDシステムが競争力のあるソフトウェア開発に必要な速度を維持しながら、大規模デプロイの複雑性を管理する方法を実証しています。\n\n\n## 対象範囲に関する重要な注意事項\n\n\nこの記事では、特に**GitLab Omnibusパッケージ**と**Helmチャート**の一部であるサービス(基本的にコアGitLabモノリスとその緊密に統合されたコンポーネント)のデプロイパイプラインについて具体的に説明しています。\n\n\nただし、GitLabのインフラストラクチャの範囲は、ここで説明されている内容を超えて広がっています。他のサービス、特に**AIサービス**や**概念実証段階**にあるサービスは、Runwayと呼ばれる内部プラットフォームを使用した異なるデプロイアプローチに従っています。\n\n\nこれらの他のサービスで作業している場合、または興味がある場合は、[Runwayドキュメント](https://docs.runway.gitlab.com)で詳細情報を確認できます。\n\n\nGitLab Dedicatedなどの他のサービスは、お客様が**GitLab Environment Toolkit**を使用して、お客様自身で実行できることを期待する内容により沿った形でデプロイされます。詳細については、[GitLab Environment Toolkitプロジェクト](https://gitlab.com/gitlab-org/gitlab-environment-toolkit)をご覧ください。\n\n\nこの記事で概説されているデプロイ戦略、アーキテクチャに関する考慮事項、パイプラインの複雑性は、コアプラットフォームで使用している実証済みのアプローチを表していますが、大規模なエンジニアリング組織と同様に、さまざまなサービスタイプと成熟度レベルに合わせた複数のデプロイ戦略があります。\n\nAuto-Deployと手順に関する詳細なドキュメントは、以下のリンクで確認できます：\n - [Engineering Deployments](https://handbook.gitlab.com/handbook/engineering/deployments-and-releases/deployments/)\n - [Release Procedural Documentation](https://gitlab-org.gitlab.io/release/docs/)\n\n## その他のリソース\n\n- [GitLabリポジトリのバックアップ時間を48時間から41分に短縮した方法](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)\n\n- [WebSocketでGitLab CIステータスを高速化した方法](https://about.gitlab.com/blog/how-we-supercharged-gitlab-ci-statuses-with-websockets/)\n\n- [バリューストリーム管理でMRレビュー時間を短縮した方法](https://about.gitlab.com/blog/how-we-reduced-mr-review-time-with-value-stream-management/)\n",[731],"John Skarbek","2026-01-15","2025-12-01","世界最大のGitLabインスタンスを1日12回デプロイする方法",[736,737],"product","inside GitLab","GitLab.comのデプロイパイプラインを技術的に深掘りします。段階的ロールアウト、Canary戦略、データベースマイグレーション、マルチバージョン互換性について解説します。",{"featured":29,"template":15,"slug":740},"continuously-deploying-the-largest-gitlab-instance",{"content":742,"config":751},{"description":743,"title":744,"authors":745,"heroImage":747,"date":748,"category":11,"body":749,"updatedDate":750},"SaaSの基礎、利用するメリット・デメリット、PaaSやIaaSとの違い、ソフトウェア開発に役立つサービスなどをご紹介。ぜひお読みください。","SaaSとは？意味・読み方・PaaS/IaaSとの違い・メリットをわかりやすく解説",[746],"GitLab Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1760421091/iaruhhz70gncm8bqfqyg.jpg","2025-10-15","SaaSを利用することで、様々な業務をより効率的に、かつ低コストで実施できます。本記事では、SaaSとは何かを分かりやすく説明するとともに、用途別のおすすめSaaSやソフトウェア開発におけるSaaS活用のメリットなどを解説します。GitLabが提供するSaaSも後半で詳しくご紹介します。\n## 目次\n* SaaSとは？\n* ソフトウェア利用モデルの比較\n* SaaSのメリット\n* SaaSのデメリット\n* SaaSとPaaS・IaaSの違いとは？\n* SaaSを選ぶ際のポイント\n* 代表的なSaaSと主な機能\n* GitLabはソフトウェア開発にどのように貢献するのか？\n* SaaSやGitLabに関するFAQ\n## SaaSとは？仕組みやクラウドとの違い\nSaaSは「Software as a Service」の略称で、読み方は「サース」もしくは「サーズ」です。日本語にすると「サービスとしてのソフトウェア」となります。\nSaaSは、サービス提供会社（ベンダー）のサーバーで提供されているソフトウェアを、インターネットなどのネットワークを介して利用できるサービスのことです。自身のパソコンや自社サーバーにソフトウェアをインストールしなくても、インターネット経由で最新のサービスを利用できます。\nSaaSの例としてよく挙げられるのがGoogleが提供しているGoogleドキュメントやGoogleスプレッドシート、Googleドライブなどです。特定のソフトウェアやアプリをインストールしなくても、これらの機能をオンライン上で自由に利用できます。\n弊社が提供しているソフトウェア開発プラットフォーム「[GitLab](https://about.gitlab.com/ja-jp/)」も、ソフトウェア開発に関するSaaSの代表格の1つです。\n### SaaSの仕組み\n一般的なソフトウェアは自社のサーバーやパソコンなどにインストールして利用しますが、SaaSの場合には、サービス提供会社のサーバーにてソフトウェアが起動しています。インターネットを介してサービス提供会社のサーバーに接続し、そこでソフトウェアを利用する、というのがSaaSの主な仕組みです。\n提供会社がソフトウェアを頻繁にアップデートしているため、最新のサービスがどこからでも、どのデバイスからでも利用できます。\n### SaaSとクラウドサービスの違い\nよく似た言葉に「クラウドサービス」があります。同様の意味合いで使われる用語ですが、クラウドサービスはアプリに限定されないより広範な概念です。後に説明するPaaSやIaaSなどもクラウドサービスに当てはまります。クラウドサービスの1つがSaaSだと考えるとよいでしょう。\n## ソフトウェア利用モデルの比較\n企業がソフトウェアを利用する方法は主に以下の3つです。\n* オンプレミス型\n* インストール型\n* SaaS\nそれぞれの特徴について簡単に説明します。\n### オンプレミス型\nオンプレミス型とは、自社のサーバーにソフトウェアを組み入れ、自社独自のシステムを構築する方法です。思い通りにカスタマイズできる、情報漏洩のリスクが少ないなどのメリットがありますが、一方で構築までに時間と費用がかかる、保守が正しくできないとセキュリティリスクが高まるなどのデメリットもあります。\n### インストール型\nインストール型は、ソフトウェアを利用予定のパソコンにインストールすることで、そのパソコンでのみ機能が使えるようにする方法です。オンプレミス型に比べると低価格で利用できる、導入に時間がかからないなどのメリットがありますが、一方で機能の拡張が難しい、アップデートのし忘れによるセキュリティ脆弱性リスクが高いなどのデメリットがあります。\n### SaaS\n昨今の主流となっているSaaSは、運営会社が管理しているサービスにインターネットを介してアクセスし、オンライン上で利用する方法です。\nより最先端の機能を利用したい、セキュリティに配慮したソフトウェアを利用したい、料金を安く抑えたいなどのニーズの増加により、オンプレミス型やインストール型ではなく、SaaSを利用する企業が増えています。\n## SaaSのメリット\nSaaSには、オンプレミス型やインストール型にはない数々のメリットがあります。\n### 最新の機能を利用できる\nサービス提供会社が自社のサーバー内でソフトウェアのアップデートを行い、そのサービスをインターネットを経由して利用するため、常に最新の機能やデザインを利用できます。\n### 利用開始までの時間が短い\nSaaSはインターネット上で契約と支払いを済ませたら、即座に利用が可能です。最低利用期間が定められているSaaSが多いものの、解約手続きも比較的簡単です。\n### 導入費用を抑制できる\n多くのSaaSは初期導入費用が無料、もしくはオンプレミス型と比べて安い傾向にあります。\n初期投資で大きな資金を準備することが難しい企業にとっては、毎月支払いのSaaSの料金プランは大きな魅力といえます。\n### セキュリティ対策に強い\nSaaSはサービス提供会社がソフトウェアに対してセキュリティ対策を実施します。自社でセキュリティ対策を行う必要がないため、人件費や労力を削減できるとともに、高い安全性が確保されたソフトウェアを使い続けることが可能です。\n### 場所を選ばない\nSaaSはインターネットさえ使えれば、どこにいても、どのデバイスからでも同様のサービスやデータにアクセスできます。急な出張が入り自身のパソコンを利用できない場合でも、別のパソコンを使ってログインすることで、普段と同じデータにアクセスできます。\n昨今拡大しているリモートワークとも相性のよいモデルとして需要が高まっています。\n### 複数人での利用に強い\nSaaSは複数人による利用に優れています。元となるデータがクラウドサーバー上に保存されているため、複数人がそのデータに直接アクセスし、同時並行で作業を進められます。\n例えば、ソフトウェア開発に関するSaaSを利用すれば、複数のデベロッパーが同時に作業を行い、それぞれの作業を即座に反映させることが可能です。\n## SaaSのデメリット\n多くのメリットがあるSaaSですが、もちろんいくつかのデメリットもあります。SaaSを利用する際には、これらのデメリットについてもよく理解し、事前に対策を練るようにしてください。\n### ソフトウェアアップデートによる急な仕様の変更\nSaaSは、サービス提供会社によって常にアップデートが行われています。方向性の転換により、操作画面の機能やデザインが急に変更になったり、これまで頻繁に使っていたシステムがなくなったりすることがあります。以前のバージョンが使いやすかったと感じても、自社の判断によって戻すことはできません。\n### 継続的な出費が発生する\n初回導入時には比較的予算が抑えられるSaaSですが、月額・年額の継続費用が発生し、長期利用ではコストが高くなる場合があります。\n### ログイン情報の漏洩によるセキュリティリスク\nサービスにアクセスするためのログイン情報が漏れた場合、他者にアクセスされる可能性が生じます。二段階認証プロセスを利用することで不正なアクセスは防げるものの、ログイン情報の管理については慎重に実施する必要があります。\n### ネットワーク環境の影響を受ける\nSaaSは、インターネットが利用できない場所では利用できません。停電やネットワークエラーによってインターネットが使えない場合、SaaSにアクセスできなくなり、作業が一時中断してしまう可能性があります。\n### SaaS側の不具合やメンテナンス\nSaaSが何らかの不具合に直面した場合、もしくは大規模なシステムアップデートのため長期に及ぶメンテナンスが必要になった場合には、サービスが一時的に利用できなくなる可能性があります。\n利用予定のSaaSが頻繁なメンテナンスを実施していないか、メンテナンスの場合には代替機能が利用できるかどうかを事前にチェックするとよいでしょう。\n## SaaSとPasS・IaaSの違いとは？サービス内容も紹介\nSaaSとよく比較される用語に「PaaS」と「IaaS」があります。自社に最適な機能を選ぶうえで、これらの違いを理解することは非常に重要です。\n### PaaSとは\nPaaSは「Platform as a Service」の略称で、「パース」と読みます。名称からもわかる通り、PaaSは主にクラウド上で利用できるプラットフォームを指します。PaaSの提供範囲は主にプラットフォームのため、ソフトウェアやアプリは含みません。\n例えばPaaSは、システムやアプリケーションを開発するためのプラットフォームをクラウド上で提供します。複数のデベロッパーが同時にアクセスし、協力体制のもとでアプリケーション開発などを進める場合に役立ちます。\n### IaaSとは\nIaaSは「Infrastructure as a Service」の略称で、「イーアス」や「アイアース」と読みます。IaaSがクラウド上で提供するのはサーバーやネットワークなどのインフラ基盤のみです。ソフトウェアやプラットフォームなど、事前に構築されたシステムや枠組みがないため、より自由な開発環境を整えたい企業に向いています。ただし、開発環境の構築も含めて自社で実施するだけの人材力やスキルが必要とされます。\n### SaaS・PaaS・IaaSの比較\nSaaSとPaaS、IaaSの各サービス内容をまとめると、以下のようになります。\n表1　SaaS・PaaS・IaaSが網羅するサービスの比較\n| サービス | SaaS | PaaS | IaaS |\n| --------------- | ---- | ---- | ---- |\n| ソフトウェア・アプリケーション | ◎ | | |\n| ミドルウェア | 〇 | ◎ | |\n| OS | 〇 | ◎ | |\n| ネットワーク | 〇 | 〇 | ◎ |\n| ストレージ | 〇 | 〇 | ◎ |\n| サーバー | 〇 | 〇 | ◎ |\n\n\nSaaSはすべてを網羅しているとはいえ、ミドルウェアやOSの使い勝手や機能に関してはPaaSがより優れています。IaaSは質の高いインフラ基盤を比較的安価に導入できる方法として、SaaSやPaaSとは差別化できます。\nそれぞれの特徴をよく理解した上で、自社に最適なサービスを導入することが重要です。\n## SaaSを選ぶ際のポイント\n自社の現状や課題に合ったSaaSを利用することで、業務効率化やコスト削減を実現することができます。一方で、自社に合わないSaaSを選んでしまうと、不慣れな作業によって時間がかかったり、せっかく購入したにも関わらず活用されなかったりする場合があります。\nそのため、SaaSを導入する際には以下のポイントをよく確認するようにしてください。\n### 機能性\nSaaSの機能は事務系やコミュニケーション系、ソフトウェア開発系など多岐にわたります。自社で解決したい課題をリストアップするとともに、どの機能を備えたSaaSが最適かをよく検討するようにしてください。\nまた、用途だけでなく、機能や操作画面の使い勝手も確認するとよいでしょう。例えば、日本語に最適化されていないSaaSでは、言語の違いによりスムーズに利用できない可能性があります。\nミスマッチを防ぐためにも、まずは無料トライアルを提供しているSaaSを選び、試してみることをおすすめします。\n### コストや料金体系\nSaaSは初期費用が比較的安く設定されているのが特徴です。ただし、毎月もしくは毎年費用が発生するため、長期的にみると大きな費用負担になる場合があります。多くのSaaSは1ユーザーごとの料金設定のため、大勢で利用した場合にはコストが大きくなります。\nまた、SaaSは最低利用期間や解約までに必要な月数などが設定されている場合がほとんどです。解約しやすいのがSaaSの特徴の1つですが、場合によっては解約時にも費用が発生する点にも注意が必要です。\n### セキュリティ\nSaaSでは、システム利用やデータの保管はすべてサービス提供会社のサーバー内で行われるため、自社でセキュリティ対策を実施する必要はありません。ただし、提供会社側でセキュリティ問題が発生した場合には、重要なデータが消去もしくは漏洩する可能性があります。\nSaaSを利用する際には、セキュリティ対策の充実度をしっかりと確認するようにしてください。\n### サポート体制\nSaaSは様々な機能が随時追加されるため、機能やデザインなどに関して、サポートの助けが必要になることが多々あります。特に緊急性のある案件に関係するSaaSにおいては、電話対応や24時間のチャットサポートに対応しているかは重要です。また、海外発のSaaSを利用する際には、日本語サポートにも対応しているかを確認するようにしてください。\n## 代表的なSaaSと主な機能\n企業が導入を検討すべきおすすめのSaaSを紹介します。\n### オフィス業務に強い「Google WorkSpace」\n「[Google Workspace](https://www.g-workspace.jp/googleworkspace/)」は、Google社が提供する有料オンラインアプリケーションセットです。GoogleドキュメントやGoogleスプレッドシート、Googleドライブ、Gmailなど、オフィス作業や業務効率化に役立つ数々のツールが利用できます。データはすべてGoogleのサーバー内に保管され、Googleが常に最新のセキュリティ対策を行っているため、安心して利用できます。\n利用には一定の[費用](https://www.g-workspace.jp/price/)が掛かりますが、様々な便利機能を安心して利用したい企業におすすめです。\n### 気軽なチャット機能が人気「ChatWork」\n多くの企業が導入しているチャット型のコミュニケーションツールが「[ChatWork](https://go.chatwork.com/ja/)」です。メールでのやりとりでは、文章を作成したり回答を得たりするのに時間がかかりますが、ChatWorkのチャットであれば時間を大幅に削減できます。\nチャットデータはすべてChatWorkが管理するサーバー内に保管されているため、パソコンやスマホ、タブレットなど、デバイスを選ばずに利用できます。日本企業が開発したSaaSのため、日本人が使いやすいように設計・最適化されているのも大きな魅力といえます。\nフリープランは無料で利用できますが、ビジネス用途であれば高いセキュリティ性能を備えた[エンタープライズプラン](https://go.chatwork.com/ja/price/?click=header-navi)がおすすめです。現在社内でのやりとりでメールを利用している、社員間のコミュニケーションを促進するツールを探している企業に最適です。\n### オンラインミーティングの大改革を果たした「Zoom」\nミーティングや営業のあり方を大きく変えたことで知られるのが「[Zoom](https://www.zoom.com/ja)」です。インターネットを利用したオンラインミーティングが実施でき、異なる場所や出張時・在宅ワークなどでのミーティング参加が可能となりました。\nまた、Zoomは営業向けにも様々な便利機能を追加しており、録画機能や自動文字起こし、資料の共有、スケジュール管理など、1つのツールで多様な課題を解決できます。\n無料のベーシックプランでもオンラインミーティング機能は利用できますが、長時間のミーティングを開催したい、より便利な機能を利用したいという方は、有料の[ビジネスプラン](https://www.zoom.us/ja/pricing?optimizely_user_id=e1913a438ebff25397b6ac8df20b7ac4&_device_id=a3148cc2-3076-420f-9c2e-569a037fc688&_ics=1731285869840&irclickid=%7Ebhadihjcf8134WZOMNV1RIJGKHABFxwrmukopfgb3VKHFAypg-8Z&_gl=1*sl16es*_gcl_au*MzE1NDA4NTUwLjE3MzEyODU4Njk.*_ga*NTAzNTU1OTQ1LjE3MzEyODU4NzA.*_ga_L8TBF28DDX*MTczMTI4NTg3MC4xLjAuMTczMTI4NTg3MC4wLjAuMA..&_ga=2.208402578.1219391157.1731285871-503555945.1731285870)がおすすめです。\n### アプリケーション開発に最適な「GitLab」\nアプリケーション・ソフトウェア開発におすすめのSaaSが、弊社が提供する「[GitLab](https://about.gitlab.com/ja-jp/)」です。AI搭載のDevSecOpsプラットフォームで、開発効率化やセキュリティに優れています。\n複数のデベロッパーが同時並行で作業できる[マルチテナント環境](https://about.gitlab.com/ja-jp/why-gitlab/)を提供するとともに、AIを含めた様々な便利アプリにより開発を効率化できます。\nビジネス目的であれば、より多くの機能が利用でき、かつセキュリティも充実している「Premium」や「Ultimate」などの有料プランがおすすめです。60日間の[無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/why-gitlab/&glm_content=default-saas-trial)もあるため、まずはお気軽にお問い合わせください。\nまた、より迅速に開発を進めたい方向けに、シングルテナント型SaaSで提供される「[GitLab Dedicated](https://about.gitlab.com/dedicated/)」サービスもあります。GitLabチームがプラットフォーム管理やデプロイを担当するため、必要な作業が大幅に削減され、重要なタスクに注力可能です。\n## GitLabはソフトウェア開発にどのように貢献するのか？\nGitLabは、クラウド上で機能するソフトウェアアプリケーション開発プラットフォームです。企業は開発、保護、そしてデプロイの複雑化に効果的に対応でき、結果としてサイクルタイムを1/7に短縮できる可能性があります。\nデベロッパーの生産性が向上するとともに、メンテナンスに必要な時間を削減できるため、多くの時間をより重要な作業に費やすことが可能です。スピーディで効率的な開発を行うことで、他社と差別化できます。\n従来からDevSecOpsプラットフォームの開発に専念してきたGitLabでは、特にセキュリティ分野において優位性を持ちます。GitLabのセキュリティ対策チームが常に最新のセキュリティ対策を研究し、ツールに導入しているため、弊社SaaSを利用する際には、すでに最新の対策が施されている状態です。これにより、開発したソフトウェアの安全を確保します。\n## SaaSやGitLabに関するFAQ\nSaaSやGitLabに関するFAQについて以下にまとめてあります。ぜひ参考にしてください。\n### GitLabではどのようなSaaS開発環境やオプションが可能か？\nGitLabでは、GitLabプラットフォームが自由に使える[マルチテナントSaaS](https://about.gitlab.com/ja-jp/why-gitlab/)と、デプロイや管理をGitLab側で担当するシングルテナントSaaSの[GitLab Dedicated](https://about.gitlab.com/dedicated/)のどちらかをお選びいただけます。また、GitLabではオンプレミスにも対応しています。\n\n\nSaaSによるソフトウェア開発が初めてで管理や操作に不安が残る方には、GitLab Dedicatedをおすすめします。ぜひご検討ください。\n### 開発分野のSaaSに限定した場合、オンプレミスと比べてどのようなメリットがあるか？\nオンプレミス型の開発環境の場合、セキュリティやガバナンス対策を自社ですべて実施する必要があります。人材を保守や運用、調査などに回す必要があるため、大きな人的コストがかかるのと同時に、開発速度も遅くなります。\n\n\nSaaSによる開発環境では、セキュリティやガバナンスをGitLabが調査、適用するため、保守運用にかかる時間を大幅に削減できます。昨今は必要なセキュリティ対策やガバナンス対策が頻繁に変化する時代です。SaaSによる開発環境を利用することで、それらの心配をする必要がなくなり、重要な作業に集中できます。\n### その他のSaaS開発環境と比較した際のGitLabの強みとは\nGitLabは、ソフトウェア開発のライフサイクル全体に対応する**DevSecOpsプラットフォーム**です。Fortune100企業の50％強が利用し、登録ユーザー数は2024年時点で約3,000万人を超えています。\n\n\nGitLabは迅速かつ効率的なソフトウェアデリバリーを実現する包括的なプラットフォームとして常に進化を遂げてきました。また、早くからセキュリティやコンプライアンスを重要な軸として位置づけ、プラットフォーム内に機能を組み入れてきた歴史があります。\n\n\n昨今はセキュリティに配慮しつつ、ガバナンスやコンプライアンスを順守しながらソフトウェア開発を進めていく必要があります。しかしながら、優秀なデベロッパーが保守運用に時間をとられ、何よりも重要な開発作業に時間を割けない問題が多くの企業で発生しています。GitLabプラットフォームを利用することで、デベロッパーがセキュリティ対策やエラー修正にかける時間を大幅に削減できます。 [GitLab](https://about.gitlab.com/ja-jp/)は、設立当初から、リモートワーク、オープンソース、DevSecOps、イテレーションへの確固たる信念を持ち続けてきました。GitLabは新しいイノベーションを模索し続けます。より優れた開発プラットフォームを模索している企業様に、GitLabは最先端・最高品質のサービスを提供いたします。","2026-03-03",{"featured":14,"template":15,"slug":752},"what-is-saas",{"promotions":754},[755,769,780,792],{"id":756,"categories":757,"header":759,"text":760,"button":761,"image":766},"ai-modernization",[758],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":762,"config":763},"Get your AI maturity score",{"href":764,"dataGaName":765,"dataGaLocation":246},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":767},{"src":768},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":770,"categories":771,"header":772,"text":760,"button":773,"image":777},"devops-modernization",[736,567],"Are you just managing tools or shipping innovation?",{"text":774,"config":775},"Get your DevOps maturity score",{"href":776,"dataGaName":765,"dataGaLocation":246},"/assessments/devops-modernization-assessment/",{"config":778},{"src":779},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":781,"categories":782,"header":784,"text":760,"button":785,"image":789},"security-modernization",[783],"security","Are you trading speed for security?",{"text":786,"config":787},"Get your security maturity score",{"href":788,"dataGaName":765,"dataGaLocation":246},"/assessments/security-modernization-assessment/",{"config":790},{"src":791},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":793,"paths":794,"header":795,"text":796,"button":797,"image":802},"github-azure-migration",[725,13],"Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":798,"config":799},"See how GitLab compares to GitHub",{"href":800,"dataGaName":801,"dataGaLocation":246},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":803},{"src":779},{"header":805,"blurb":806,"button":807,"secondaryButton":811},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":49,"config":808},{"href":809,"dataGaName":52,"dataGaLocation":810},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":54,"config":812},{"href":56,"dataGaName":57,"dataGaLocation":810},1777493610829]