[{"data":1,"prerenderedAt":757},["ShallowReactive",2],{"/en-us/blog/tags/solutions-architecture/":3,"navigation-ja-jp":20,"banner-ja-jp":437,"footer-ja-jp":450,"solutions architecture-tag-page-ja-jp":660},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/solutions-architecture","tags",false,"",{"tag":9,"tagSlug":10},"solutions architecture","solutions-architecture",{"template":12},"BlogTag","content:en-us:blog:tags:solutions-architecture.yml","yaml","Solutions Architecture","content","en-us/blog/tags/solutions-architecture.yml","en-us/blog/tags/solutions-architecture","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":433,"_type":14,"title":434,"_source":16,"_file":435,"_stem":436,"_extension":19},"/shared/ja-jp/main-navigation","ja-jp",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":411,"duo":424},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/ja-jp/","gitlab logo","header",{"text":30,"config":31},"無料トライアルを開始",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"お問い合わせ",{"href":37,"dataGaName":38,"dataGaLocation":28},"/ja-jp/sales/","sales",{"text":40,"config":41},"サインイン",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,299,359],{"text":46,"config":47,"cards":49,"footer":72},"プラットフォーム",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":53,"config":54},"プラットフォームを詳しく見る",{"href":55,"dataGaName":48,"dataGaLocation":28},"/ja-jp/platform/",{"title":57,"description":58,"link":59},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":60,"config":61},"GitLab Duoのご紹介",{"href":62,"dataGaName":63,"dataGaLocation":28},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":68,"config":69},"詳細はこちら",{"href":70,"dataGaName":71,"dataGaLocation":28},"/ja-jp/why-gitlab/","why gitlab",{"title":73,"items":74},"利用を開始：",[75,80,85],{"text":76,"config":77},"プラットフォームエンジニアリング",{"href":78,"dataGaName":79,"dataGaLocation":28},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"開発者の経験",{"href":83,"dataGaName":84,"dataGaLocation":28},"/ja-jp/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"製品",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":28},"/ja-jp/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"自動化","CI/CDと自動化でデプロイを加速",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/ja-jp/solutions/continuous-integration/",{"text":113,"config":114},"AIアシストによる開発",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"ソースコード管理",{"href":119,"dataGaLocation":28,"dataGaName":120},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"自動化されたソフトウェアデリバリー",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/ja-jp/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"ソフトウェアサプライチェーンの安全性",{"href":142,"dataGaLocation":28,"dataGaName":143},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"測定",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"可視性と測定",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"バリューストリーム管理",{"href":163,"dataGaLocation":28,"dataGaName":164},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"分析とインサイト",{"href":168,"dataGaLocation":28,"dataGaName":169},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLabが活躍する場所",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":28,"dataGaName":177},"/ja-jp/enterprise/","enterprise",{"text":179,"config":180},"スモールビジネス",{"href":181,"dataGaLocation":28,"dataGaName":182},"/ja-jp/small-business/","small business",{"text":184,"config":185},"公共機関",{"href":186,"dataGaLocation":28,"dataGaName":187},"/ja-jp/solutions/public-sector/","public sector",{"text":189,"config":190},"価格",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/ja-jp/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"関連リソース",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"すべてのリソースを表示",{"href":200,"dataGaName":196,"dataGaLocation":28},"/ja-jp/resources/",[202,235,258],{"title":203,"items":204},"はじめに",[205,210,215,220,225,230],{"text":206,"config":207},"インストール",{"href":208,"dataGaName":209,"dataGaLocation":28},"/ja-jp/install/","install",{"text":211,"config":212},"クイックスタートガイド",{"href":213,"dataGaName":214,"dataGaLocation":28},"/ja-jp/get-started/","quick setup checklists",{"text":216,"config":217},"学ぶ",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"製品ドキュメント",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"ベストプラクティスビデオ",{"href":228,"dataGaName":229,"dataGaLocation":28},"/ja-jp/getting-started-videos/","best practice videos",{"text":231,"config":232},"インテグレーション",{"href":233,"dataGaName":234,"dataGaLocation":28},"/ja-jp/integrations/","integrations",{"title":236,"items":237},"検索する",[238,243,248,253],{"text":239,"config":240},"お客様成功事例",{"href":241,"dataGaName":242,"dataGaLocation":28},"/ja-jp/customers/","customer success stories",{"text":244,"config":245},"ブログ",{"href":246,"dataGaName":247,"dataGaLocation":28},"/ja-jp/blog/","blog",{"text":249,"config":250},"リモート",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/ja-jp/teamops/","teamops",{"title":259,"items":260},"つなげる",[261,266,271,276,281],{"text":262,"config":263},"GitLabサービス",{"href":264,"dataGaName":265,"dataGaLocation":28},"/ja-jp/services/","services",{"text":267,"config":268},"コミュニティ",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"フォーラム",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"イベント",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"パートナー",{"href":284,"dataGaName":285,"dataGaLocation":28},"/ja-jp/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":291,"config":292},"ソースプロモカード",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"最新情報を読む",{"href":297,"dataGaName":298,"dataGaLocation":28},"/ja-jp/the-source/","the source",{"text":300,"config":301,"lists":303},"Company",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"GitLabについて",{"href":309,"dataGaName":310,"dataGaLocation":28},"/ja-jp/company/","about",{"text":312,"config":313,"footerGa":316},"採用情報",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"経営陣",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"チーム",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"ハンドブック",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"投資家向け情報",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"トラストセンター",{"href":342,"dataGaName":343,"dataGaLocation":28},"/ja-jp/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":28},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"ニュースレター",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"プレス",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":35,"config":360,"lists":361},{"dataNavLevelOne":302},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"サポートを受ける",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"カスタマーポータル",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"閉じる",{"text":380,"link":381},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":382,"config":383},"GitLab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"提案",[389,392,397,399,403,407],{"text":57,"config":390},{"href":62,"dataGaName":391,"dataGaLocation":385},"GitLab Duo (AI)",{"text":393,"config":394},"コード提案（AI）",{"href":395,"dataGaName":396,"dataGaLocation":385},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":398},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":400,"config":401},"GitLab on AWS",{"href":402,"dataGaName":400,"dataGaLocation":385},"/ja-jp/partners/technology-partners/aws/",{"text":404,"config":405},"GitLab on Google Cloud",{"href":406,"dataGaName":404,"dataGaLocation":385},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":408,"config":409},"GitLabを選ぶ理由",{"href":70,"dataGaName":410,"dataGaLocation":385},"Why GitLab?",{"freeTrial":412,"mobileIcon":416,"desktopIcon":421},{"text":30,"config":413},{"href":414,"dataGaName":33,"dataGaLocation":415},"https://gitlab.com/-/trials/new/","nav",{"altText":417,"config":418},"GitLabアイコン",{"src":419,"dataGaName":420,"dataGaLocation":415},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":417,"config":422},{"src":423,"dataGaName":420,"dataGaLocation":415},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"GitLab Duoの詳細について",{"href":62,"dataGaName":428,"dataGaLocation":415},"gitlab duo",{"altText":417,"config":430},{"src":419,"dataGaName":420,"dataGaLocation":415},{"altText":417,"config":432},{"src":423,"dataGaName":420,"dataGaLocation":415},"content:shared:ja-jp:main-navigation.yml","Main Navigation","shared/ja-jp/main-navigation.yml","shared/ja-jp/main-navigation",{"_path":438,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":439,"button":440,"config":445,"_id":447,"_type":14,"_source":16,"_file":448,"_stem":449,"_extension":19},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能になりました！",{"text":441,"config":442},"ベータ版を試す",{"href":443,"dataGaName":444,"dataGaLocation":28},"/ja-jp/gitlab-duo/agent-platform/","duo banner",{"layout":446},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":451,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":452,"_id":656,"_type":14,"title":657,"_source":16,"_file":658,"_stem":659,"_extension":19},"/shared/ja-jp/main-footer",{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":648},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":455,"config":456},"ページのソースを表示",{"href":457,"dataGaName":458,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":461,"config":462},"このページを編集",{"href":463,"dataGaName":464,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":466,"config":467},"ご協力をお願いします",{"href":468,"dataGaName":469,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":471,"facebook":472,"youtube":473,"linkedin":474},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[476,499,553,586,620],{"title":46,"links":477,"subMenu":482},[478],{"text":479,"config":480},"DevSecOpsプラットフォーム",{"href":55,"dataGaName":481,"dataGaLocation":459},"devsecops platform",[483],{"title":189,"links":484},[485,489,494],{"text":486,"config":487},"プランの表示",{"href":191,"dataGaName":488,"dataGaLocation":459},"view plans",{"text":490,"config":491},"Premiumを選ぶ理由",{"href":492,"dataGaName":493,"dataGaLocation":459},"/ja-jp/pricing/premium/","why premium",{"text":495,"config":496},"Ultimateを選ぶ理由",{"href":497,"dataGaName":498,"dataGaLocation":459},"/ja-jp/pricing/ultimate/","why ultimate",{"title":500,"links":501},"ソリューション",[502,507,510,512,517,522,526,529,532,537,539,541,543,548],{"text":503,"config":504},"デジタルトランスフォーメーション",{"href":505,"dataGaName":506,"dataGaLocation":459},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":508,"config":509},"セキュリティとコンプライアンス",{"href":137,"dataGaName":138,"dataGaLocation":459},{"text":122,"config":511},{"href":105,"dataGaName":106,"dataGaLocation":459},{"text":513,"config":514},"アジャイル開発",{"href":515,"dataGaName":516,"dataGaLocation":459},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":518,"config":519},"クラウドトランスフォーメーション",{"href":520,"dataGaName":521,"dataGaLocation":459},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":523,"config":524},"SCM",{"href":119,"dataGaName":525,"dataGaLocation":459},"source code management",{"text":109,"config":527},{"href":111,"dataGaName":528,"dataGaLocation":459},"continuous integration & delivery",{"text":161,"config":530},{"href":163,"dataGaName":531,"dataGaLocation":459},"value stream management",{"text":533,"config":534},"GitOps",{"href":535,"dataGaName":536,"dataGaLocation":459},"/ja-jp/solutions/gitops/","gitops",{"text":174,"config":538},{"href":176,"dataGaName":177,"dataGaLocation":459},{"text":179,"config":540},{"href":181,"dataGaName":182,"dataGaLocation":459},{"text":184,"config":542},{"href":186,"dataGaName":187,"dataGaLocation":459},{"text":544,"config":545},"教育",{"href":546,"dataGaName":547,"dataGaLocation":459},"/ja-jp/solutions/education/","education",{"text":549,"config":550},"金融サービス",{"href":551,"dataGaName":552,"dataGaLocation":459},"/ja-jp/solutions/finance/","financial services",{"title":194,"links":554},[555,557,559,561,564,566,570,572,574,576,578,580,582,584],{"text":206,"config":556},{"href":208,"dataGaName":209,"dataGaLocation":459},{"text":211,"config":558},{"href":213,"dataGaName":214,"dataGaLocation":459},{"text":216,"config":560},{"href":218,"dataGaName":219,"dataGaLocation":459},{"text":221,"config":562},{"href":223,"dataGaName":563,"dataGaLocation":459},"docs",{"text":244,"config":565},{"href":246,"dataGaName":247},{"text":567,"config":568},"お客様の成功事例",{"href":569,"dataGaLocation":459},"/customers/",{"text":239,"config":571},{"href":241,"dataGaName":242,"dataGaLocation":459},{"text":249,"config":573},{"href":251,"dataGaName":252,"dataGaLocation":459},{"text":262,"config":575},{"href":264,"dataGaName":265,"dataGaLocation":459},{"text":254,"config":577},{"href":256,"dataGaName":257,"dataGaLocation":459},{"text":267,"config":579},{"href":269,"dataGaName":270,"dataGaLocation":459},{"text":272,"config":581},{"href":274,"dataGaName":275,"dataGaLocation":459},{"text":277,"config":583},{"href":279,"dataGaName":280,"dataGaLocation":459},{"text":282,"config":585},{"href":284,"dataGaName":285,"dataGaLocation":459},{"title":300,"links":587},[588,590,592,594,596,598,600,604,609,611,613,615],{"text":307,"config":589},{"href":309,"dataGaName":302,"dataGaLocation":459},{"text":312,"config":591},{"href":314,"dataGaName":315,"dataGaLocation":459},{"text":320,"config":593},{"href":322,"dataGaName":323,"dataGaLocation":459},{"text":325,"config":595},{"href":327,"dataGaName":328,"dataGaLocation":459},{"text":330,"config":597},{"href":332,"dataGaName":333,"dataGaLocation":459},{"text":335,"config":599},{"href":337,"dataGaName":338,"dataGaLocation":459},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":459},"/sustainability/",{"text":605,"config":606},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":607,"dataGaName":608,"dataGaLocation":459},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":610},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":350,"config":612},{"href":352,"dataGaName":353,"dataGaLocation":459},{"text":355,"config":614},{"href":357,"dataGaName":358,"dataGaLocation":459},{"text":616,"config":617},"現代奴隷制の透明性に関する声明",{"href":618,"dataGaName":619,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":35,"links":621},[622,624,626,628,633,638,643],{"text":35,"config":623},{"href":37,"dataGaName":38,"dataGaLocation":459},{"text":368,"config":625},{"href":370,"dataGaName":371,"dataGaLocation":459},{"text":373,"config":627},{"href":375,"dataGaName":376,"dataGaLocation":459},{"text":629,"config":630},"ステータス",{"href":631,"dataGaName":632,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":634,"config":635},"利用規約",{"href":636,"dataGaName":637,"dataGaLocation":459},"/terms/","terms of use",{"text":639,"config":640},"プライバシーに関する声明",{"href":641,"dataGaName":642,"dataGaLocation":459},"/ja-jp/privacy/","privacy statement",{"text":644,"config":645},"Cookieの設定",{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":649},[650,652,654],{"text":634,"config":651},{"href":636,"dataGaName":637,"dataGaLocation":459},{"text":639,"config":653},{"href":641,"dataGaName":642,"dataGaLocation":459},{"text":644,"config":655},{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":91},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"allPosts":661,"featuredPost":735,"totalPagesCount":755,"initialPosts":756},[662,689,710],{"_path":663,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":664,"content":672,"config":682,"_id":685,"_type":14,"title":686,"_source":16,"_file":687,"_stem":688,"_extension":19},"/ja-jp/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"title":665,"description":666,"ogTitle":665,"ogDescription":666,"noIndex":6,"ogImage":667,"ogUrl":668,"ogSiteName":669,"ogType":670,"canonicalUrls":668,"schema":671},"データドリブンのDevSecOps：GitLabインサイトダッシュボードのご紹介","主要なメトリクスの可視化、プロジェクトの進捗状況の追跡、カスタマイズ可能なデータドリブンビューを使ったチームの生産性の改善など、GitLabインサイトダッシュボードの活用方法について説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097210/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097210214.png","https://about.gitlab.com/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"データドリブンのDevSecOps：GitLabインサイトダッシュボードのご紹介\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ricardo Amarilla Villalba\"}],\n        \"datePublished\": \"2024-11-20\",\n      }",{"title":665,"description":666,"authors":673,"heroImage":667,"date":675,"body":676,"category":677,"tags":678},[674],"Ricardo Amarilla Villalba","2024-11-20","メトリクスおよび分析は、生産性や品質を高め、成功を収める上で極めて重要な要素です。包括的なDevSecOpsプラットフォームであるGitLabでは、こういった重要なメトリクスを追跡・可視化するための強力なツールをインサイトダッシュボード上で提供しています。この記事では、ご利用の環境でのインサイトダッシュボードの使用方法についてご紹介します。\n\n\n## GitLabのメトリクスと分析ツールのご紹介 \n\n\nGitLabでは、DevSecOpsライフサイクルのさまざまな側面に対応したメトリクスおよび分析ツール群をご用意しています。\n\n\n1.\n[生産性分析](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html)：チームの開発速度、サイクルタイム、リードタイムを追跡します。  \n\n2.\n[コードレビュー分析](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html)：コード品質、テストカバレッジ、レビュー効率を測定します。  \n\n3.\n[CI/CD分析](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html)：パイプラインのパフォーマンスとデプロイ頻度をモニタリングします。  \n\n4.\n[バリューストリーム分析](https://docs.gitlab.com/ee/user/group/value_stream_analytics/)：アイデア出しから本番稼働までの作業の流れを可視化します。  \n\n5.\n[インサイト](https://docs.gitlab.com/ee/user/project/insights/)：プロジェクトやグループに関するデータを調べて可視化します。\n\n\n開発プロセスに関する貴重なインサイトを得られるこれらのメトリクスを参考にして、ボトルネックの特定、ワークフローの最適化、データドリブンな意思決定を行えます。\n\n\n## 特定のメトリクスへのラベルの活用\n\n\nあまり目立たないものの、GitLabの特に強力な機能の1つがラベルです。ラベルを使うと、特定のメトリクスに絞り込んで、極めて正確に焦点を当てられます。イシューやマージリクエスト、エピックに戦略的にラベルを適用することで、プロジェクトのパフォーマンスや進捗について的確なインサイトを得られるカスタムビューを作成できます。\n\n\n用途の広い識別子として機能するGitLabのラベルを使用すれば、作業アイテムを柔軟に分類・整理できます。機能開発やバグ修正、チーム固有のタスクなど、追跡対象が何であれ、ラベルを使用すれば、プロジェクトデータをスライスして、別の視点から分析して意味のあるパターンや傾向を特定することが可能です。この概念は、クラウドのデプロイにおいて、管理やコスト配分、運用上のインサイト取得をスムーズに行うためにタグを使用するのと似ています。\n\n\nしっかりと考えながら作業アイテムにラベルを付けていくことで、カスタムダッシュボードやレポートの生成に活用できる高度なラベリングシステムが実質的に構築されます。このアプローチにより、チームや関係者にとって最も重要なメトリクスを重点的に取り上げられるとともに、プロジェクトの健全性と勢いに焦点を絞ってわかりやすく可視化できます。\n\n\n## GitLabインサイトの設定方法\n\n\nGitLabインサイトを使用すると、プロジェクトやグループに関するデータを調べて可視化できます。特定の期間内に作成された、または完了したイシュー、マージリクエストのマージが完了するまでの平均時間、トリアージの健全性など、さまざまな側面に関する有用な分析情報を得られます。インサイトは、プロジェクトとグループのどちらにも設定できます。\n\n\nインサイトの設定手順は次のとおりです。\n\n\n1. プロジェクトにインサイトを設定する場合：  \n   * プロジェクトのルートディレクトリ内に`.gitlab/insights.yml`という名前のファイルを作成します。  \n2. グループにインサイトを設定する場合：  \n   * グループに属するプロジェクト内に`.gitlab/insights.yml`ファイルを作成します。  \n   * グループの**設定 > 一般**の順に移動します。\n   * **分析セクション**を展開し、**インサイトセクション**を見つけます。  \n   * 設定ファイルが含まれるプロジェクトを選択し、変更を保存します。\n\n`.gitlab/insights.yml`は、レポート内のチャートの構造や順序に加え、表示されるチャートの形式を定義できるYAMLファイルです。各チャートの定義には、タイトル、説明、タイプ、データソースやフィルタリング条件を指定するクエリなどのパラメータを含められます。\n\n\nインサイトを表示するには、プロジェクトまたはグループで**分析 > インサイト**の順に移動します。\n\n\n![デフォルトのインサイトダッシュボードの表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097217972.png)\n\n\n## マージリクエストインサイトのカスタマイズ\n\n\nデフォルトビューでは有用な情報が未加工で表示されますが、インサイトダッシュボードをカスタマイズすれば、各マージリクエストの担当チームや、マージリクエストごとに解決された問題の種類など、より多くの情報が明らかになります。\n\n\n## スクワッドおよび要件タイプごとのマージリクエストインサイト\n\n\nGitLabでスクワッドの生産性を測定するのは、難しい場合があります。GitLabのグループとサブグループの構造が、実際のスクワッドの構成と完全に一致していない場合は特に困難です。こういった課題に対処し、効果的にスクワッドの生産性を追跡する方法をご紹介します。\n\n\n### **スクワッドベースのメトリクスの設定**\n\n\n1.\n**ラベルの作成**：スクワッドごと（例：`squad::alpha`、`squad::beta`）および要件タイプ（例：`type::bug`、`type::feature`、`type::maintenance`）ごとに範囲指定した一意のラベルを作成します。\n\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZUOzORIUJeU?si=T8eHeGizS3blYFHB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n\n2.\n**ラベルの適用**：所属するプロジェクトやグループに関係なく、各スクワッドが対応するすべてのイシューおよびマージリクエストにこれらのスクワッドラベルを一貫して適用します。  \n\n\n\u003C!-- 空白行 -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/fJ9entEBZG8?si=MlM6mKirEdkmwDDJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- 空白行 -->\n\n\n**ヒント**：  \n   * GitLab APIを使用すれば、既存のMR（未解決、マージ済み、完了したもの）に一括でラベルを適用できます。  \n   * GitLab CIパイプラインの一環としてラベルの追加や削除、更新を行えます。  \n   * GitLabトリアージボットを活用すれば、ラベルの適用プロセスを自動化できます。  \n\n3.\nダッシュボードの設定：プロジェクトのリポジトリに`.gitlab/insights.yml`ファイルを作成し、チームやタイプ固有のマージリクエストインサイト用のカスタムチャートを定義します。\n\n\n```\n\n\n## Default Merge Requests insights.yml \n\nmergeRequests:\n  title: Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week \n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month\n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n\n## Per-teams Merge Requests insights.yml\n\nmergeRequestsTeams:\n  title: Merge requests dashboard per teams\n  charts:\n    - title: Merge requests merged per week \n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n    - title: Merge requests merged per month\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n\n## Per-teams and Type Merge Requests insights.yml\n\nmergeRequestsTeamsAndType:\n  title: Per Teams and Type - Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n    - title: Merge requests merged per week - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n\n```\n\n\nこのようにカスタマイズすることで、チームおよび要件タイプごとのマージリクエストアクティビティがわかりやく表示される、役に立つ情報満載のダッシュボードを作成できます。それをもとに、長期的なトレンドの可視化、各スクワッドのパフォーマンスの比較、スクワット単位での作業タイプの分布の分析を行えます。\n\n\n![チームおよび要件タイプごとにMRアクティビティが表示されているダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097217972.png)\n\n\n![各スクワッドのパフォーマンスが比較されているダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097217974.png)\n\n\n## 無料トライアルで今すぐスタート！\n\n\nGitLabには、GitLabインサイト以外にも、メトリクスおよび分析関連のツールや機能が多数あります。ぜひ以下のバリューストリーム管理製品ツアーで、バリューストリーム分析やCI/CD分析、コードレビューメトリクスなど、GitLabの強力な分析機能の全容をご確認ください。\n\n\n[![バリューストリーム管理製品ツアー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-11-20_at_12.28.08_PM_aHR0cHM6_1750097217976.png)](https://gitlab.navattic.com/vsm)\n\n\n> カスタムメトリクスの作成を始める準備ができたら、[今すぐGitLab\nUltimateの無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F)にご登録ください。データドリブンのDevSecOpsを最大限に活用しましょう。\n\n\n## 関連リンク\n\n-\n[スケジュール設定できるレポート生成ツールでバリューストリーム管理を簡単に実施](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n\n-\n[新たなGitLabバリューストリームダッシュボードを使い始める](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/)\n\n-\n[AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n","product",[109,679,677,680,681,9],"DevSecOps platform","features","tutorial",{"slug":683,"featured":91,"template":684},"data-driven-devsecops-exploring-gitlab-insights-dashboards","BlogPost","content:ja-jp:blog:data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","Data Driven Devsecops Exploring Gitlab Insights Dashboards","ja-jp/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","ja-jp/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"_path":690,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":691,"content":697,"config":704,"_id":706,"_type":14,"title":707,"_source":16,"_file":708,"_stem":709,"_extension":19},"/ja-jp/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":692,"description":693,"ogTitle":692,"ogDescription":693,"noIndex":6,"ogImage":694,"ogUrl":695,"ogSiteName":669,"ogType":670,"canonicalUrls":695,"schema":696},"エンタープライズ規模のGitLabパッケージレジストリの構築","GitLab独自のプロジェクトベースの公開モデルを活用し、ルートグループレベルを使用して、安全で柔軟なパッケージ管理戦略を立てる方法についてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662332/Blog/Hero%20Images/blog-image-template-1800x945__23_.png","https://about.gitlab.com/blog/structuring-the-gitlab-package-registry-for-enterprise-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"エンタープライズ規模のGitLabパッケージレジストリの構築\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":692,"description":693,"authors":698,"heroImage":694,"date":700,"body":701,"category":677,"tags":702},[699],"Tim Rizzi","2025-02-19","組織の規模が拡大するにつれ、社内パッケージの管理はますます複雑になります。JFrog ArtifactoryやSonatype\nNexusなどの従来のパッケージ管理システムでは一元化されたリポジトリアプローチが使用される一方で、GitLabでは現代の開発チームの作業により合致する、別の方法を採用しています。この記事では、Mavenパッケージとnpmパッケージを例に、エンタープライズ規模のGitLabパッケージレジストリを効果的に構築する方法について見ていきます。\n\n\n## GitLabパッケージレジストリモデルについて\n\n\n従来のパッケージ管理システムからGitLabのアプローチへ移行する際は、その違いに最初は戸惑うかもしれません。GitLabでは、単一の集中型リポジトリを使用する代わりに、パッケージ管理を既存のプロジェクト構造とグループ構造に直接統合します。これにより、次のような運用が可能になります。\n\n\n- チームは、コードが含まれる特定のプロジェクトにパッケージを公開\n\n- チームは、ルートグループレジストリ（その下にある全パッケージを網羅）からパッケージを使用\n\n- アクセス制御はGitLabの既存の権限設定から継承\n\n\nこのモデルには、次のようないくつかの利点があります。\n\n\n- パッケージとともにそのソースコードの所有権を明確化\n\n- 追加設定なしできめ細かいアクセス制御を実現\n\n- CI/CD統合を簡素化\n\n- チーム構造との自然な整合性を実現\n\n- ルートグループを使用することで、自社の全パッケージに単一のURLからアクセス可能\n\n\n### ルートグループパッケージレジストリを利用する利点\n\n\nGitLabではさまざまなグループレベルでパッケージを利用できますが、GitLabユーザーの間では、ルートグループレベルを使うことがベストプラクティスとして定着しつつあります。それには、以下のような理由があります。\n\n\n- **単一のアクセスポイント**：単一のURLから組織内の全プライベートパッケージにアクセス可能\n\n- **一貫性のあるパッケージ名**：グループレベルのエンドポイントにより、各チームは競合することなく、希望する命名規則を適用可能\n\n- **設定の簡素化**：すべてのデベロッパーが同じ設定を使用してパッケージにアクセス可能\n\n- **安全なアクセス管理**：デプロイトークンと組み合わせることで、容易にローテーションとアクセス制御を実現\n\n- **階層型の構造**：統一された方法でのアクセスを維持しながら、組織構造に自然にマッピング可能\n\n\n## 実世界での例：エンタープライズ向け構成\n\n\nでは、実際に大規模な企業ではどのように機能するか見ていきましょう。\n\n\n```\n\ncompany/ (root group)\n\n├── retail-division/\n\n│   ├── shared-libraries/     # 部門固有の共有コード\n\n│   └── teams/\n\n│       ├── checkout/        # チームはここにパッケージを公開\n\n│       └── inventory/       # チームはここにパッケージを公開\n\n├── banking-division/\n\n│   ├── shared-libraries/    # 部門固有の共有コード\n\n│   └── teams/\n\n│       ├── payments/       # チームはここにパッケージを公開\n\n│       └── fraud/         # チームはここにパッケージを公開\n\n└── shared-platform/        # 企業全体の共有コード\n    ├── java-commons/      # 共有Javaライブラリ\n    └── ui-components/     # 共有UIコンポーネント\n```\n\n\n### 公開設定\n\n\nチームは各自のプロジェクトレジストリにパッケージを公開します。これにより、所有権が明確化されます。\n\n\n1. Mavenの例\n\n\n```xml\n\n\u003C!-- checkout/pom.xml -->\n\n\u003CdistributionManagement>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/distributionManagement>\n\n```\n\n\n2. npmの例\n\n\n```json\n\n// ui-components/package.json\n\n{\n  \"name\": \"@company/ui-components\",\n  \"publishConfig\": {\n    \"registry\": \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/\"\n  }\n}\n\n```\n\n\n### 使用設定\n\n\nルートグループを使用する利点をここで発揮します。全チームは、パッケージへのアクセス用に単一のエンドポイントを設定します。\n\n\n1. Mavenの例\n\n\n```xml\n\n\u003C!-- 任意のプロジェクトのpom.xml -->\n\n\u003Crepositories>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>https://gitlab.example.com/api/v4/groups/company/-/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/repositories>\n\n```\n\n\n2. npmの例\n\n\n```\n\n# 任意のプロジェクトのnpmrcファイル\n\n@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/\n\n```\n\n\nこの設定では、プロジェクトベースでの公開による利点を活用しつつ、社内全体にわたってすべてのパッケージへのアクセスを自動的に提供します。\n\n\n## 認証とアクセス制御\n\n\nGitLabが採用しているモデルでは、デプロイトークンとCI/CD統合により、認証が簡素化されます。\n\n\n### CI/CDパイプラインでの利用\n\n\nGitLabは、`CI_JOB_TOKEN`を使用してパイプラインでの認証を自動的に処理します。\n\n\n```yaml\n\n#-.gitlab. .gitlab-ci.yml\n\npublish:\n  script:\n    - mvn deploy  # またはnpm publish\n  # CI_JOB_TOKENによって自動的に認証が行われる\n```\n\n\n### 開発環境での利用\n\n\nグループデプロイトークンを用いて、パッケージを使用します。\n\n\n- ルートグループレベルで読み取り専用のデプロイトークンを作成\n\n- セキュリティのために定期的にトークンローテーションを行う\n\n- すべてのデベロッパー間で単一の設定を共有\n\n\n## ルートグループパッケージレジストリを使用する利点\n\n\n1. 設定の簡素化\n   - 単一のURLからすべてのパッケージにアクセス可能\n   - チーム間で一貫した設定\n   - トークンローテーションを簡単に実施可能\n2. 所有権の明確化\n   - パッケージをソースコードと一緒に保管\n   - 各チームが公開を制御\n   - バージョン履歴をプロジェクトアクティビティに関連付け\n3. 自然な構造\n   - 企業構造に合致\n   - チームの自律性をサポート\n   - チーム間のコラボレーションが可能\n\n## 始め方\n\n\n1. ルートグループの設定\n   - 明確なグループ構造を作成\n   - 適切なアクセス制御を設定\n   - グループデプロイトークンを作成\n2. チームプロジェクトの設定\n   - プロジェクトレベルでの公開設定を行う\n   - CI/CDパイプラインを実装\n   - パッケージの命名規則を文書化\n3. 使用の標準化\n   - ルートグループレジストリへのアクセスを設定\n   - デプロイトークンを安全に共有\n   - パッケージの検索プロセスを文書化\n\n## まとめ\n\n\nGitLabのパッケージレジストリモデルは、特にルートグループの使用を活用すれば、エンタープライズ向けのパッケージ管理用の強力なソリューションとなります。組織は、プロジェクトベースでの公開とルートグループでの利用を組み合わせることで、所有権の明確化とアクセスの簡素化の両方を実現できます。このアプローチなら、セキュリティと使いやすさを維持しながら、組織の規模に合わせて自然にスケールできます。\n\n\nまずは、1つのチームまたは部門にこのモデルを導入し、この統合アプローチの効果を実感しながら徐々に展開していくことをおすすめします。なお、この記事ではMavenとnpmに焦点を当ててご説明しましたが、GitLabでサポートされているすべてのタイプのパッケージにも、同じ原則を適用できます。\n\n\n> 今すぐパッケージレジストリを使い始めましょう！[GitLab\nUltimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)にぜひお申し込みください。\n",[703,681,9],"DevSecOps",{"slug":705,"featured":91,"template":684},"structuring-the-gitlab-package-registry-for-enterprise-scale","content:ja-jp:blog:structuring-the-gitlab-package-registry-for-enterprise-scale.yml","Structuring The Gitlab Package Registry For Enterprise Scale","ja-jp/blog/structuring-the-gitlab-package-registry-for-enterprise-scale.yml","ja-jp/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"_path":711,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":712,"content":718,"config":729,"_id":731,"_type":14,"title":732,"_source":16,"_file":733,"_stem":734,"_extension":19},"/ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"title":713,"description":714,"ogTitle":713,"ogDescription":714,"noIndex":6,"ogImage":715,"ogUrl":716,"ogSiteName":669,"ogType":670,"canonicalUrls":716,"schema":717},"【徹底解説！】AWS CodeCommitからGitLabへの移行ガイド","この記事では、AWSサービスからGitLabに移行し、DevSecOpsプラットフォームとシームレスに統合する方法をわかりやすく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097810/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2828%29_4mi0l4wzUa5VI4wtf8gInx_1750097810027.png","https://about.gitlab.com/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"【徹底解説！】AWS CodeCommitからGitLabへの移行ガイド\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"},{\"@type\":\"Person\",\"name\":\"Samer Akkoub\"},{\"@type\":\"Person\",\"name\":\"Bart Zhang\"}],\n        \"datePublished\": \"2024-08-26\",\n      }",{"title":713,"description":714,"authors":719,"heroImage":715,"date":724,"body":725,"category":677,"tags":726,"updatedDate":728},[720,721,722,723],"Tsukasa Komatsubara","Darwin Sanoy","Samer Akkoub","Bart Zhang","2024-08-26","2024年7月25日に、AWSが自社のCodeCommitサービスについて重要な発表を行いました。詳細はAWSの[公式ブログ記事（外部サイト）](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)に記載されていますが、CodeCommitでの新規顧客の利用受付が終了することになりました。既存のお客様は引き続きサービスを利用できるものの、今後AWSが新機能を実装することはなく、セキュリティ、可用性、パフォーマンスの改善のみに注力するとのことです。\n\n今回の発表は、開発チームがリポジトリを別のGitプロバイダーに移行することを検討するきっかけとなっています。これらの変更をふまえ、お客様がGitLabに移行して他のAWSサービスと統合できるように、抱括的なガイドをご用意しました。\n\n__注：__ 移行に関するAWSの公式推奨事項の詳細については、[AWSのブログ記事（外部サイト）](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)をご覧ください。\n\n## このガイドについて\n\nこのガイドでは、GitLabを使用していてAWSサービスとの統合を検討している開発チームや、AWSにホストされているGitリポジトリからGitLab.comに移行予定の開発チーム向けに包括的な情報を提供します。このガイドは次の3つの主要セクションで構成されています。\n\n* [GitLabへの並行移行](https://app.contentful.com/spaces/r9o86ar0p03f/entries/2tGP1LjJy6E5hzf9B24KIl?focusedField=body\\&focusedLocale=en-US\\#section-1-parallel-migration-to-gitlab)：リスクを最小限に抑えつつ、AWSにホストされている既存リポジトリからGitLab.comへ徐々に移行する方法について説明します。  \n* [AWS CodeBuildとの統合](https://app.contentful.com/spaces/r9o86ar0p03f/entries/2tGP1LjJy6E5hzf9B24KIl?focusedField=body\\&focusedLocale=en-US\\#section-2-integrating-gitlab-with-aws-codebuild)：GitLabリポジトリをAWS CodeBuildと統合し、強力な継続的インテグレーション（CI）環境を設定する手順を紹介します。  \n* [AWS CodePipelineとの統合](https://app.contentful.com/spaces/r9o86ar0p03f/entries/2tGP1LjJy6E5hzf9B24KIl?focusedField=body\\&focusedLocale=en-US\\#section-3-integrating-gitlab-with-aws-codepipeline)：効率的な継続的デリバリーパイプラインを構築するために、GitLabリポジトリをAWS CodePipelineと接続する方法について詳しく説明します。  \n* [CodePipelineとCodeStar Connectionsのダウンストリーム統合](https://app.contentful.com/spaces/r9o86ar0p03f/entries/2tGP1LjJy6E5hzf9B24KIl?focusedField=body\\&focusedLocale=en-US\\#section-4-migrating-to-gitlab)：GitLabとAWS間の接続を活用して広範なサービスの利用を実現する方法について説明します。この方法を用いると、AWSエコシステム全体での統合の可能性が連鎖的に広がります。\n\nこのガイドを通して、GitLabとAWSの強力な機能を組み合わせ、効率的で柔軟な開発ワークフローを作成する方法を学びましょう！\n\n## **第1セクション：GitLabへの並行移行**\n\nAWSにホストされているGitリポジトリをGitLab.comに移行することを検討中の方向けに、段階的なアプローチについて取り上げる本セクションでは、リスクを最小限に抑えながら移行を達成する方法をご紹介します。GitLabのミラーリング機能を活用すれば、既存の開発フローを維持しながら、新しい環境をテストできます。\n\n### **並行移行が重要な理由**\n\n大規模なシステムの移行には常にリスクが伴います。特に、実施中の開発作業や既存のインテグレーション、自動化されたプロセスに影響が生じる可能性があります。並行移行アプローチを採用すると、次のようなメリットがあります。\n\n1\\. リスクの最小化：既存のシステムを稼働させた状態で新しい環境をテストできます。  \n2\\. シームレスな移行：開発チームが新しいシステムに少しずつ慣れることができます。   \n3\\. インテグレーションテスト：すべてのインテグレーションと自動化を新しい環境で徹底的にテストできます。   \n4\\. 将来性：既存のCIと並行して、チームが徐々にGitLab [CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)に移行できるようにします。\n\n直接GitLabに一括で移行することが望ましいとわかっている場合は、並行移行を行う必要はありません。\n\n### **GitLab.comへの移行手順**\n\n#### **ステップ1：GitLab.comをセットアップする**\n\n* 会社で使用中のGitLab.comのグループがあるかどうか、またシングルサインオン（SSO）を設定済みであるかどうかを確認します。グループがあり、シングルサインオンを設定済みである場合は、両方とも使用することになります。\n\n* GitLab.comに会社で使用しているグループがない場合は、[GitLab.com](https://app.contentful.com/spaces/r9o86ar0p03f/entries/www.gitlab.com)にアクセスして新規アカウントを作成するか、既存のアカウントにログインしてください。\n\n* 会社用のネームスペース（Gitlab.comのルートレベルのグループ）を新たに作成します。  \n* ネームスペースに、（これまでに使用されていない）会社に合った名前を付けます。\n\n#### **ステップ2：リポジトリをインポートする**\n\n並行移行の場合：GitLabのプルミラーリング機能を使用して、AWSにホストされているリポジトリからGitLab.comに変更を自動的に同期します。\n\n1. GitLab.comのターゲットグループに移動します。  \n2. 右上の「新規プロジェクト」をクリックします。   \n3. 「新しいプロジェクトを作成」ページで「プロジェクトをインポート」をクリックします。   \n4. 「プロジェクトをインポート」ページで「URLによるリポジトリ」をクリックします。  \n5. 「GitリポジトリのURL」フィールドに、AWSにホストされているリポジトリのURLを入力します。   \n6. 「GitリポジトリのURL」フィールドの下にある「リポジトリをミラーリング」にチェックを入れます。  \n7. 認証の設定：AWS CodeCommitコンソールで、移行するリポジトリのクローンURLを選択します。CodeCommitリポジトリをGitLabに移行する場合は、HTTPS CodeCommit URLを使用して、GitLabのリポジトリのミラーリングを介してリポジトリをクローンできます。また、GitLabにAWSのIAMユーザーに割り当てたGit認証情報を入力する必要があります。AWS CodeCommit用のGit認証情報を作成する方法は、こちらの[AWSガイド（外部サイト）](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html)に従ってください。\n\n![クローンURL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/clone-url-screenshot__1__aHR0cHM6_1750097822121.png)\n\nこの設定を行うと、デフォルトでは5分ごとにAWSにホストされているリポジトリからGitLab.comに変更が自動的にプルされます。\n\n詳細については、[リポジトリのミラーリングに関するドキュメント](https://docs.gitlab.com/ee/user/project/repository/mirror/)をご参照ください。\n\n#### **ステップ3：インテグレーションのテストと検証を行う**\n\n1. [CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)パイプライン：既存のパイプラインを複製するために、GitLab CIで `.gitlab-ci.yml`  ファイルを設定します。[他のCIツールからGitLab CI/CDへの移行の計画](https://docs.gitlab.com/ee/ci/migration/plan\\_a\\_migration.html)について詳細をご確認ください。  \n2. イシュートラッキング：プロジェクトのイシューとテストワークフローをインポートします。  \n3. コードレビュー：マージリクエストプロセスとテストレビューワークフローを設定します。\n\n#### **ステップ4：段階的に移行する**\n\n1. 小規模または重要度の低いプロジェクトから移行を始めて、GitLab.comでの作業に慣れましょう。  \n2. チームメンバー向けにトレーニングを行い、新しいワークフローに適応する時間を十分に確保します。  \n3. インテグレーションとワークフローに問題がないことを確認しながら、徐々にその他のプロジェクトを移行します。\n\n詳細については、[CodeCommitからGitLabへの移行の自動化](https://gitlab.com/guided-explorations/aws/migrating-from-codecommit-to-gitlab/-/blob/main/migrating\\_codecommit\\_to\\_gitlab.md)をご参照ください。\n\n#### **ステップ5：移行を完了する**\n\nすべてのテストと検証が完了し、新しい環境にチームが慣れてきたら、完全な移行の計画を立てます。プロジェクトごとに以下の対応を行います。\n\n1. 移行日を決めて、すべてのステークホルダーに通知する。  \n2. 最後のデータ同期を行う。  \n3. ミラーリング設定をGitLabプロジェクトから削除する。  \n4. AWSにホストされているリポジトリを読み取り専用に設定し、すべての開発作業をGitLab.comに移行する。\n\n#### **ステップ6：新しい機能を導入するかどうかを判断する**\n\nGitLabでデベロッパーが利用できるコラボレーションとワークフローの自動化機能は、CodeCommitと比べてはるかに豊富です。これらの機能について理解するには、ある程度時間がかかります。中でもマージリクエストプロセスは、CodeCommitよりも強力です。\n\nGitLab上でリポジトリが安定させてしまえば、既存のソリューションと並行して非常に簡単にGitLab CI/CDを試せることになるでしょう。本番環境のワークフローはそのままに、時間をかけてGitLab CI/CDの自動化を完成させることができるのです。\n\nGitLabのアーティファクト管理も、リリース機能や多くのパッケージレジストリで非常に役に立ちます。\n\n### **第1セクションのまとめ**\n\nGitLabへの並行移行アプローチを採用すると、リスクを最小限に抑えながらスムーズな移行を実現できます。このプロセスを通じて、チームは新しい環境に徐々に適応でき、すべてのインテグレーションと自動化が正しく機能するようになります。並行移行を行う必要がないとわかっていて一括で移行する場合でも、スキップできるのは1つのチェックボックス設定のみです。\n\n## **第2セクション：GitLabとAWS CodeBuildの統合**\n\nAWS CodeBuildを使用して、GitLabリポジトリを構築してコードをテストしたい方は、こちらの完全ガイドを参考にして、CIパイプラインを効率的に設定してください。\n\n### **前提条件**\n\n* GitLab.comアカウント  \n* AWSアカウント  \n* AWS CLI（構成済み）\n\n### **ステップ1：AWS CodeStar ConnectionsでGitLabとの接続を作成する**\n\n1. AWSマネージメントコンソールにログインし、CodeBuildサービスに移動します。  \n2. 左側のナビゲーションパネルから「設定」\\>「接続」の順に選択します。  \n3. 「接続を作成」ボタンをクリックします。  \n4. プロバイダーとして「GitLab」を選択します。  \n5. 接続名を入力して「GitLabに接続」をクリックします。  \n6. GitLabの認証ページにリダイレクトされます。  \n7. 必要な権限を承認します。  \n8. 正常に接続されると、接続ステータスが「利用可能」に変わります。\n\n![CodeStar Connectセットアップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### **ステップ2：AWS CodeBuildプロジェクトを作成する**\n\n1. CodeBuildダッシュボードで「ビルドプロジェクトを作成」をクリックします。  \n2. プロジェクトの名前と説明を入力します。  \n3. ソース設定では、プロバイダーとして「GitLab」を選択します。  \n4. 先程作成した接続を選択し、GitLabのリポジトリとブランチを指定します。\n\n![CodeBuildプロジェクトを追加](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_3_add_codebuild_aHR0cHM6_1750097822123.png)\n\n**注：ステップ3以降では、ご自身の環境とニーズに応じて設定を行ってください。**\n\n### **第2セクションのまとめ**\n\nこのセクションでは、GitLabリポジトリをAWS CodeBuildと統合する方法について詳しく説明しました。このように設定することで、GitLabで行ったコード変更がAWS CodeBuildによって自動的にビルド・テストされる継続的インテグレーションパイプラインを実現できます。\n\n## **第3セクション：GitLabとAWS CodePipelineの統合**\n\nAWS CodePipelineを使用してGitLabリポジトリからの継続的デリバリーを実装しようとしている方は、この詳細なガイドを参考にしてください。GitLabをAWS CodeStar Connectionsプロバイダーとして利用できるようになったため、これまでよりも統合しやすくなりました。\n\n### **前提条件**\n\n* GitLab.comアカウント  \n* AWSアカウント  \n* AWS CLI（構成済み）\n\n### **ステップ1：AWS CodeStar ConnectionsでGitLabとの接続を作成する**\n\n1. AWSマネージメントコンソールにログインし、CodePipelineサービスに移動します。  \n2. 左側のナビゲーションパネルから「設定」\\>「接続」の順に選択します。   \n3. 「接続を作成」ボタンをクリックします。  \n4. プロバイダーとして「GitLab」を選択します。  \n5. 接続名を入力して「GitLabに接続」をクリックします。  \n6. GitLabの認証ページにリダイレクトされます。  \n7. 必要な権限を承認します。  \n8. 正常に接続されると、接続ステータスが「利用可能」に変わります。\n\n![CodeStar Connectセットアップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### **ステップ2：AWS CodePipelineを作成する**\n\n1. CodePipelineダッシュボードで「パイプラインを作成」をクリックします。  \n2. パイプライン名を入力して「次へ」をクリックします。  \n3. ソースプロバイダーとして「GitLab」を選択します。  \n4. 先程作成した接続を選択し、GitLabのリポジトリとブランチを指定します。  \n5. トリガータイプを選択します。リポジトリ内の特定のブランチやファイルタイプに対するプルイベントまたはプッシュイベントに基づいて、CodePipelineパイプラインの実行をトリガーできます。\n\n![ソースプロバイダーを追加](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822125.png)\n\n![ソース構成を追加](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_provider_aHR0cHM6_1750097822127.png)\n\n**注：ステップ3以降では、ご自身の環境とニーズに応じて設定を行ってください。** \n\n### **第3セクションのまとめ**\n\nこのセクションでは、GitLabリポジトリをAWS CodePipelineと統合する方法について詳しく説明しました。このように設定することで、GitLabで行ったコード変更が自動的にAWS環境にデプロイされる継続的デリバリーパイプラインを実現できます。\n\n## **第4セクション：GitLabへの移行**\n\nGitLabにAWSを統合すると、開発ワークフローとデプロイワークフローを効率化する強力な機能を利用できるようになり、ソースコード管理に伴う問題を解決しやすくなります。統合方法は次のようにいくつかあり、それぞれに独自のメリットがあります。\n\n* AWS CodeStar Connectionsを使用してGitLabとAWSサービスを連携させる場合、さまざまなAWSサービスにGitLabなどの外部のGitリポジトリを接続できるようになるため、より一貫したワークフローを実現できます。この設定方法では、GitLabレポジトリでの自動ビルド、デプロイ、その他の重要なアクションが直接サポートされるため、開発プロセスの一貫性および効率性が向上します。  \n* AWS CodeStar Connections経由でGitLabとAWS CodePipelineを接続すると、完全なCI/CDパイプラインを作成できるため、自動化を次のレベルへと進められます。このアプローチでは、GitLabをAWS CodePipelineと統合することで、CodeBuildやCodeDeployなどのAWSサービスを使用して、ソース管理やビルドからテストやデプロイまでの全プロセスを自動化できます。これにより、堅牢でスケーラブルかつ効率的なデリバリープロセスを実現できます。\n\n![GitLabとAWSを一緒に使用するための新しいテクノロジーとソリューションのチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_configured_aHR0cHM6_1750097822129.png)\u003Cbr>\u003Cbr>\n\n1.AWS CodeStar Connectionsを使ってGitLabとAWSサービスを接続する\n\nAWS CodeStar Connectionsは、外部のGitリポジトリ（GitHubやBitbucketなど）をAWSサービスと接続するためのサービスです。また、CodeStar Connections経由でGitLabをAWSサービスに接続することもできます。GitLabを使用する場合、HTTP Gitサーバーとしてカスタム接続を設定しなければならない可能性があります。 この方法でGitLabに接続できるAWSサービスは以下のとおりです。\n\n* __AWSサービスカタログ__ \n\nAWS Service Catalogは、組織におけるAWSリソースの標準化および管理を支援します。AWS Service CatalogをGitLabと統合すると、リソース管理の透明性が向上し、変更を追跡しやすくなります。具体的には、GitLabのコミットに基づいてカタログの更新を自動化し、運用効率を向上させることができます。\n\n* __AWS CodeBuild__ \n\nAWS CodeBuildは、ソースコードをコンパイルし、テストを実行し、デプロイできるソフトウェアパッケージを生成するマネージド型のビルドサービスです。GitLabとCodeBuildを統合すると、GitLabにコード変更がプッシュされるたびに自動化されたビルドプロセスが開始されるようになります。これにより、ビルドの一貫性が確保され、コラボレーションとバージョン管理を容易に進められます。\n\n* __AWS Glue ノートブックジョブ__ \n\nAWS Glueノートブックジョブは、データの準備とETL （抽出、変換、ロード）タスクを対話形式で開発して実行できるサービスです。GitLabとGlueノートブックジョブを統合すると、ノートブックとETLスクリプトのバージョン管理を行えるようになり、チームメンバー間のコラボレーションが促進され、データ処理パイプラインの品質管理が強化されます。\n\n* __AWS Proton__\n\nAWS Protonは、[マイクロサービス](https://about.gitlab.com/ja-jp/blog/what-are-the-benefits-of-a-microservices-architecture/)とServerlessアプリケーションの開発とデプロイを自動化するサービスです。GitLabとAWS Protonを統合することで、インフラストラクチャをコードとして管理し、デプロイを自動化し、一貫した環境管理を実現できるため、開発プロセスをさらに効率化できます。\n\nAWS CodeStar Connectionsのサポート対象のサービスが増えるにつれ、より多くのAWSサービスをGitLabとさらに簡単に接続できるようになります。そのため、CodeStar Connectionsを新たにサポートするサービスを定期的にチェックすることをお勧めします。\u003Cbr>\u003Cbr>\n\n2. AWS CodeStar Connections経由（CodeDeployを含む）でCodePipelineとGitLabを接続する\n\nAWS CodePipelineは、ソフトウェアのリリースプロセスを自動化する継続的デリバリーサービスです。GitLabとCodePipelineを接続するには、AWS CodeStar Connectionsを使用する必要があります。この設定方法を用いると、GitLabリポジトリをソースとして指定し、CI/CDパイプライン全体を自動化できます。 CodePipelineがサポートする主なアクションは以下のとおりです。\n\n* __ソース管理__ ：AWS CodeCommit、GitHub、Bitbucket、GitLab  \n* __ビルドとテスト__ ：AWS CodeBuild、Jenkins  \n* __デプロイ__ ：AWS CodeDeploy、Elastic Beanstalk、ECS、S3  \n* __承認__ ：手動承認  \n* __インフラストラクチャ管理__ ：AWS CloudFormation  \n* __Serverless__ ：AWS Lambda  \n* __テスト__ ：AWS Device Farm  \n* __カスタムアクション__ ：AWS Step Functions\n\nGitLabとCodePipelineを統合すると、GitLabにコード変更がプッシュされるたびにパイプラインが自動的にトリガーされるため、一貫したプロセスでビルドからデプロイまでを行えます。さらに、これをGitLabのバージョン管理機能と組み合わせることで、デプロイの履歴と状態を簡単に追跡できるようになり、より柔軟で信頼性の高いソフトウェアデリバリーを実現できます。\n\n## **まとめ**\n\nこのガイドでは、GitLabへの移行、およびGitLabとAWSとの統合に関する包括的な情報を提供しました。4つの主なトピックを通して、以下の内容を取り上げました。\n\n* GitLabへの並行移行：リスクを最小限に抑えつつ、AWSにホストされている既存リポジトリからGitLab.comへ徐々に移行する方法。  \n* AWS CodeBuildとの統合：GitLabリポジトリと統合された強力なCI環境を設定する手順。  \n* AWS CodePipelineとの統合：GitLabリポジトリを使用して効率的な継続的デリバリーパイプラインを構築する方法。  \n* CodePipelineとCodeStar Connectionsのダウンストリーム統合：GitLabとAWS間の接続を活用して広範なサービスの利用を実現する方法。この方法を用いると、AWSエコシステム全体での統合の可能性が連鎖的に広がります。\n\nコードホスティングと統合の実装戦略は組織ごとに異なります。このガイドをチュートリアルとして、貴社独自のGitLab とAWSの統合および実装戦略の出発点としてご利用ください。\n\n## **リソース**\n\nより詳しい情報と高度な設定については、以下のリソースを参照してください。\n\n* [GitLabドキュメント](https://docs.gitlab.com/)  \n* [AWS CodeBuildユーザーガイド](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)  \n* [AWS CodePipelineユーザーガイド](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)  \n* [GitLab CI/CDドキュメント](https://docs.gitlab.com/ee/ci/)  \n* [AWSとの統合](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab\\_aws\\_integration.html)\n\nご質問がある場合やサポートが必要な場合は、[GitLabサポート](https://about.gitlab.com/support/)またはAWSサポートまでお問い合わせください。みなさまがAWSとGitLabの統合を始める上で、こちらの総合ガイドがお役に立てば幸いです。\n\u003Cbr>\u003Cbr>\n\n*監修：小松原 つかさ [@tkomatsubara](https://gitlab.com/tkomatsubara)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）*\n",[109,727,679,681,9,677,234],"AWS","2024-09-05",{"slug":730,"featured":91,"template":684},"ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","content:ja-jp:blog:ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","Ultimate Guide To Migrating From Aws Codecommit To Gitlab","ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"_path":736,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":737,"content":743,"config":749,"_id":751,"_type":14,"title":752,"_source":16,"_file":753,"_stem":754,"_extension":19},"/ja-jp/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"title":738,"description":739,"ogTitle":738,"ogDescription":739,"noIndex":6,"ogImage":740,"ogUrl":741,"ogSiteName":669,"ogType":670,"canonicalUrls":741,"schema":742},"Amazon ECRからGitLabへのコンテナイメージ移行の自動化","プラットフォームチームがCI/CDをGitLabに移行する際、コンテナイメージの移行がボトルネックになってはなりません。このガイドでは、パイプライン移行を自動化する方法を詳しく解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","https://about.gitlab.com/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Amazon ECRからGitLabへのコンテナイメージ移行の自動化\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-13\",\n      }",{"title":738,"description":739,"authors":744,"heroImage":740,"date":745,"body":746,"category":747,"tags":748},[699],"2025-02-13","「Amazon Elastic Container\nRegistry（ECR）からGitLabに数百ものコンテナイメージを移行する必要があるのですが、手伝ってもらえますか？」これまでのプラットフォームエンジニアとの会話の中で、何度もこの質問が出てきました。彼らは、DevSecOpsツールチェーンをGitLabに統合してモダナイズしようとしていたものの、コンテナイメージの移行の箇所でつまずいていました。個々のイメージの移行は簡単でも、数が多すぎると、手作業で行うのは現実的ではありません。\n\n\nまさに、あるエンジニアは「やるべきことはわかっています。プルして、再タグ付けして、プッシュするだけです。しかし、マイクロサービスが200個もあり、それぞれに複数のタグがあります。インフラストラクチャ関連の重要な仕事が山積みの中、この移行作業に何週間も費やすわけにはいきません」と話していました。\n\n\n## 課題\n\n\nこの会話をきっかけに、プロセス全体を自動化できないかと考えました。[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)をGitLabに移行する際、コンテナイメージの移行がボトルネックになってはなりません。手作業はシンプルですが、繰り返しが多すぎます。各イメージをプルし、再タグ付けし、GitLabのコンテナレジストリにプッシュする…これを数十のリポジトリ、各イメージの何百ものタグに対して行うとなると、数日から数週間かかる途方もない作業になります。\n\n\n## 解決策\n\n\nそこで、こういった大変な作業を自動処理するGitLabパイプラインの作成に取り掛かりました。目標はシンプルです。プラットフォームエンジニアが数分でセットアップできて、一晩放置すればすべてのイメージの移行が完了している、そんなツールを作ることでした。\n\n\n### アクセス権の設定\n\n\nまずはセキュリティです。チームが最小限のAWS権限でこの移行作業を実行できるようにすることを重視しました。以下の読み取り専用のアイデンティティおよびアクセス管理（IAM）ポリシーを用意しました。\n\n\n```json\n\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": [\n                \"ecr:GetAuthorizationToken\",\n                \"ecr:BatchCheckLayerAvailability\",\n                \"ecr:GetDownloadUrlForLayer\",\n                \"ecr:DescribeRepositories\",\n                \"ecr:ListImages\",\n                \"ecr:DescribeImages\",\n                \"ecr:BatchGetImage\"\n            ],\n            \"Resource\": \"*\"\n        }\n    ]\n}\n\n```\n\n\n### GitLabの設定\n\n\nセキュリティの次はGitLab側の設定です。最小限の構成で済むようにしました。CI/CD設定で以下の変数を設定します。\n\n\n```\n\nAWS_ACCOUNT_ID: AWSのアカウントID\n\nAWS_DEFAULT_REGION: ECRのリージョン\n\nAWS_ACCESS_KEY_ID: [マスク]\n\nAWS_SECRET_ACCESS_KEY: [マスク]\n\nBULK_MIGRATE: true\n\n```\n\n\n### 移行パイプライン\n\n\nここからが本番です。このパイプラインはDocker-in-Dockerを使って構築し、すべてのイメージ操作を安定して実行できるようにしました。\n\n\n```yaml\n\nimage: docker:20.10\n\nservices:\n  - docker:20.10-dind\n\nbefore_script:\n  - apk add --no-cache aws-cli jq\n  - aws sts get-caller-identity\n  - aws ecr get-login-password | docker login --username AWS --password-stdin\n  - docker login -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD} ${CI_REGISTRY}\n```\n\n\nこのパイプラインは3つのフェーズで構成され、それぞれが前のフェーズをベースにします。\n\n\n1. 検出\n\n\nまず、すべてのECRリポジトリを取得します。\n\n\n```bash\n\nREPOS=$(aws ecr describe-repositories --query\n'repositories[*].repositoryName' --output text)\n\n```\n\n\n2. タグの列挙\n\n\n次に、各リポジトリの全タグを取得します。\n\n\n```bash\n\nTAGS=$(aws ecr describe-images --repository-name $repo --query\n'imageDetails[*].imageTags[]' --output text)\n\n```\n\n\n3. 移行\n\n\n最後に、実際にイメージ移行を実行します。\n\n\n```bash\n\ndocker pull\n${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag}\n\ndocker tag\n${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag}\n${CI_REGISTRY_IMAGE}/${repo}:${tag}\n\ndocker push ${CI_REGISTRY_IMAGE}/${repo}:${tag}\n\n```\n\n\n## 期待できる成果\n\n\n移行に何週間もかける時間がないというプラットフォームエンジニアのために、このソリューションは次のような成果を提供します。\n\n\n- すべてのリポジトリとタグを自動的に検出・移行\n\n- ECRとGitLabのイメージ命名規則を統一\n\n- 転送失敗時のエラーハンドリング\n\n- 進捗を追跡できる明確なログ\n\n\n\n移行スクリプトを書いたり、移行作業を監視したりする必要がなくなり、プラットフォームエンジニアは他の重要な作業に集中できるようになります。\n\n\n## 使い方\n\n\n手順はシンプルです。\n\n\n1. `.gitlab-ci.yml`をリポジトリにコピー\n\n2. AWSとGitLabの変数を設定\n\n3. `BULK_MIGRATE`を「true」に設定して、移行を開始\n\n\n## ベストプラクティス\n\n\nさまざまなチームの移行を支援する中で、いくつかの重要なポイントが見えてきました。\n\n\n- ピーク時以外に実行し、チームへの影響を最小限に抑える\n\n- パイプラインのログを確認し、必要な対応がないかチェックする\n\n- すべてのイメージが正常に転送されたことを確認するまで、ECRを廃止しない\n\n- 大規模な移行の場合、ネットワーク負荷を避けるためにレート制限の適用を検討する\n\n\nこのパイプラインは、GitLabの公開リポジトリでオープンソースとして提供しています。プラットフォームエンジニアがコンテナイメージの移行に時間を取られるのではなく、本来の業務に専念できるよう設計されています。ニーズに応じてカスタマイズしてお使いください。実装についてのご質問もお待ちしています。\n\n\n> ####\nこのパッケージおよびその他のコンポーネントの詳細については、[CI/CDカタログのドキュメント](https://gitlab.com/explore/catalog/components/package)をご覧ください。\n","engineering",[109,727,681,679,677,9],{"slug":750,"featured":91,"template":684},"automating-container-image-migration-from-amazon-ecr-to-gitlab","content:ja-jp:blog:automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","Automating Container Image Migration From Amazon Ecr To Gitlab","ja-jp/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","ja-jp/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",1,[662,689,710],1758326277427]