[{"data":1,"prerenderedAt":820},["ShallowReactive",2],{"/en-us/blog/remote-development-beta":3,"navigation-en-us":43,"banner-en-us":453,"footer-en-us":463,"blog-post-authors-en-us-David O'Regan":702,"blog-related-posts-en-us-remote-development-beta":717,"blog-promotions-en-us":757,"next-steps-en-us":810},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":29,"isFeatured":12,"meta":30,"navigation":31,"path":32,"publishedDate":20,"seo":33,"stem":37,"tagSlugs":38,"__hash__":42},"blogPosts/en-us/blog/remote-development-beta.yml","Remote Development Beta",[7],"david-oregan",null,"engineering",{"slug":11,"featured":12,"template":13},"remote-development-beta",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"Behind the scenes of the Remote Development Beta release","Discover the epic journey of GitLab's Remote Development team as they navigate last-minute pivots, adapt, and deliver new features for users worldwide.",[18],"David O'Regan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679888/Blog/Hero%20Images/remotedevelopment.jpg","2023-08-16","\nIn May 2023, the Create:IDE team faced an epic challenge – to merge the [Remote Development Rails monolith integration branch](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105783) into the `master` branch of the GitLab Project. This was no small ask, as the merge request was of considerable size and complexity. In this blog post, we'll delve into the background, justifications, and process behind this endeavor.\n\nThe merge request titled \"Remote Development feature behind a feature flag\" was initiated by the Create:IDE team, aiming to merge the branch \"remote_dev\" into the \"master\" branch in the Rails monolith GitLab project. The MR contained `4` commits, `258` pipelines, and `143` changes that amounted to a total of `+7243` lines of code added to the codebase.\n\nInitially, the MR was created to reflect the work related to \"Remote Development\" under the \"Category: Remote Development.\" It was primarily intended to have CI pipeline coverage for the integration branch and was not meant for individual review or direct merging. The plan was to merge this code into the master branch via the [\"Remote Development Beta - Review and merge\" Epic](https://gitlab.com/groups/gitlab-org/-/epics/10258).\n\n![SUM](https://about.gitlab.com/images/blogimages/remote-development/SUM.png){: .shadow.medium}\n\n### How the Remote Development project started\nAs a team, we embarked on an ambitious journey to create a greenfield feature: the [Remote Development](https://docs.gitlab.com/ee/user/project/remote_development/) offering at GitLab. This feature had a vast scope, many unknowns, and required solving numerous new problems. To efficiently tackle this task, we decided to work on an integration branch using a [low-ceremony process](https://stackoverflow.com/questions/68092498/what-does-low-ceremony-mean). This decision enabled us to develop and release the feature in an impressively short time frame of less than four months.\n\nWorking on an integration branch provided us the flexibility to make significant progress, but it was always intended to eventually break down the work into smaller, iterative MRs that would follow the standard [GitLab review process](https://docs.gitlab.com/ee/development/code_review.html). We had a [detailed plan](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/blob/main/doc/integration-branch-process.md#master-mr-process-summary) for this process, but we realized that following the original plan would not allow us to meet our goal of releasing of the feature in GitLab 16.0.\n\n### Merging the integration branch MR without breaking it up\nDuring the development of the Remote Development feature, our team faced several challenges that led us to adopt a new approach for merging the integration branch into the master. First, as part of our [velocity-based XP/Scrum style process](https://handbook.gitlab.com/handbook/engineering/devops/dev/create/remote-development/#-remote-development-iteration-planning), we realized that meeting the 16.0 release goal would require us to cut scope. A velocity report, \"[Velocity-based agile planning report](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118436),\" highlighted that breaking down and reviewing individual MRs would take too long, considering the impending due date and the likelihood of last-minute scope additions.\n\nSecond, we [made the decision](https://gitlab.com/gitlab-org/gitlab/-/issues/398227#note_1361192858) to release workspaces as a **beta feature for public projects** for customers in [GitLab 16.0](/releases/2023/05/22/gitlab-16-0-released/#remote-development-workspaces-available-in-beta-for-public-projects). This approach reduced the complexity of the rollout plan and allowed us to get valuable feedback earlier, but required us to enable the feature by default earlier than planned. To align with this decision, we determined that merging the integration branch after review was the best course of action. An announcement was made to explain the change in plan, and we set specific timelines for the review process to ensure smooth coordination.\n\n> Hello Reviewers/Maintainers πŸ‘‹ We have opened up a Zoom room through all of next week as an easy sync place for us all to collaborate and triage questions. As the MR is quite large, it might be overwhelming to determine where to begin. To help, we will aim to furnish a summary of what we have included, such as two new database tables and a couple of GraphQL/REST APIs. We will also be available through the week in the Zoom room and without it being too prescriptive of a approach, I would suggest we do a sync walkthrough of the MR first and then kick off the reviews.\n\nAddressing the concerns about risk, team members discussed the challenges and potential solutions. While there were apprehensions, we were confident in the overall quality of the feature. A disciplined plan for merging MRs was initially considered, but based on our velocity metrics, it was evident that meeting the public beta release goal required a new strategy.\n\nDespite the deviations from our usual practices, we acknowledged the urgency to deliver the initial release on time. The decision was not taken lightly, and we ensured that the merge had extensive [test coverage](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html) and [feature flags](https://docs.gitlab.com/ee/operations/feature_flags.html) in place to address any potential issues. We accepted that some aspects would be overlooked in the initial MR review cycle, but we committed to addressing them in subsequent iterations.\n\n### Keeping the pipeline green and stable for the merge\nTo ensure the successful merge of the integration branch containing the Remote Development feature, our team made significant efforts to keep the pipeline green and stable. As the MR was quite large and contained critical functionality, it was crucial to maintain a high level of quality and reduce the risk of introducing regressions.\n\nTo address these challenges, the team adopted a disciplined approach to [CI/CD](https://about.gitlab.com/topics/ci-cd/). Throughout the development process, CI pipelines were carefully monitored, and any failing tests or issues were promptly addressed. The team conducted rigorous testing and code reviews to identify and fix potential bugs and ensure that the changes did not negatively impact the existing functionality of the codebase.\n\nAdditionally, extensive test coverage was put in place to ensure that the new feature worked as expected and did not cause unintended side effects. The team utilized GitLab's [test coverage visualization](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html) capabilities to track the extent of test coverage and identify areas that required additional testing.\n\n![PIPE](https://about.gitlab.com/images/blogimages/remote-development/PIPE.png){: .shadow.medium}\n\n## The merging process\nAs part of the Remote Development team, we took a strategic approach to the merging process. We identified three categories of follow-up tasks that needed to be addressed after the release:\n\n1. **To-dos:** This category encompassed follow-up issues that required further attention.\n2. **Disabled linting rules:** Any issues related to disabled linting rules were included in this category.\n3. **Follow-up from review:** Non-blocking concerns raised during the review process were categorized here.\n\nTo manage this process effectively, we organized these categories into [child epics](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#multi-level-child-epics) under the main epic representing the merging effort.\n\n1. Child epic for [to-do follow-up issues](https://gitlab.com/groups/gitlab-org/-/epics/10472)\n2. Child epic for [disabled linting rules follow-up issues](https://gitlab.com/groups/gitlab-org/-/epics/10473)\n3. Child epic for [follow-up issues from review](https://gitlab.com/groups/gitlab-org/-/epics/10474)\n\n\n## Reviewer resources\nDuring the integration branch merge process for the Remote Development feature, we ensured a smooth and collaborative review experience for all involved. To facilitate this, we set up the following resources and documented the information in GitLab's issue, epic, and MR reviews for better persistence and traceability:\n\n1. **Dedicated Slack channel:** We had a Slack channel that served as our primary hub for coordinating reviews and resolving any blockers that arose during the process. The discussions, decisions, and important points discussed in this channel were documented in the related GitLab issues and epics. This approach enabled us to maintain a historical record of the conversations for to refer back to in the future.\n2. **General Slack channel:** For non-urgent or non-blocking questions and discussions, reviewers could use the a general Slack channel. Similar to the dedicated channel, we documented the relevant information from this channel in the corresponding issues and MR reviews in GitLab.\n3. **Addressing urgent issues:** When urgent issues required immediate attention, reviewers could directly address our technical leads [Vishal Tak](https://gitlab.com/vtak) and/or [Chad Woolley](https://gitlab.com/cwoolley-gitlab) in their Slack messages. However, we kindly requested that [direct messages were avoided](https://handbook.gitlab.com/handbook/communication/#avoid-direct-messages) to promote open collaboration. The resolutions to these urgent issues were documented in the corresponding GitLab issues or MR discussions.\n4. **Zoom collaboration room:** The collaborative sessions held in the open Zoom room were not only beneficial for real-time discussions but also for fostering a collaborative environment. After each session, we summarized the key points and decisions made during the meeting in the associated GitLab issue or MR, making sure all important outcomes were captured and accessible to the team.\n\nThroughout the review process, we were committed to maintaining a seamless and well-documented workflow. By capturing all relevant information in GitLab issues, epics, and MR reviews, we ensured that the knowledge was persistently available, and future team members could easily understand the context and decisions made during the integration process.\n\n## Application security review\nDuring the application security review process, we focused on providing a secure and reliable Remote Development feature for our users. Here are the key resources and updates related to the application security review:\n\n1. **Main application security review issue:** The main application security review issue served as the central hub for tracking security-related considerations. You can find the defined process we followed [here](https://handbook.gitlab.com/handbook/security/product-security/application-security/appsec-reviews/).\n2. **Application security review comment:** The application security review issue contained a comment indicating that the merge was not blocked unless there were severe issues that could impact production. \"In order to maintain a smooth merge process, we do not block MRs from being merged unless we identify severe issues that could prevent the feature from going into production, such as S1 or S2 level problems. If you are aware of any design flaws or concerns that might qualify as such issues, please bring them to our attention. We can review them together and address any questions or concerns that arise. Let's work collaboratively to find an approach that works for both parties. πŸ‘\"\n3. **Engineering perspective:** For managing the application security review process from an engineering team perspective, we had a dedicated issue, which is kept confidential for security reasons.\n4. **Security and authentication matters:** All security and authentication concerns pertaining to the Beta release were documented within the [`Remote Development Beta -Auth` epic](https://gitlab.com/groups/gitlab-org/-/epics/10377). As of April 30, 2023, we are delighted to announce that **no known issues or obstacles were found that would impede the merge**. This represents a significant accomplishment, considering the intricate nature of this new feature.\n5. **Initial question raised:** During the application security review, one initial question was raised, and we promptly addressed it. You can track the issue and our response [here](https://gitlab.com/gitlab-org/gitlab/-/issues/409317).\n\n## Database review\nTo ensure the reliability and efficiency of the Remote Development feature, we sought guidance from the database reviewer. Although the team had not conducted a thorough self-review, we were fully prepared to address any blocking issues raised during the review process. Our references for the review were:\n\n- [Database review documentation](https://docs.gitlab.com/ee/development/database_review.html)\n- [Database reviewer guidelines](https://docs.gitlab.com/ee/development/database/database_reviewer_guidelines.html)\n\nAs an example, during the database migration review, a discussion arose between [Alper Akgun](https://gitlab.com/a_akgun) and Chad, regarding the efficient ordering of columns in the workspaces table. Alper initially suggested placing integer values at the beginning of the table based on relevant documentation.\n\nChad questioned the benefit of this suggestion, pointing out that the specific integer field, `max_hours_before_termination`, would still be padded with empty bytes even if moved to the front, due to its current position between two text fields.\n\nAlper proposed an alternative approach, emphasizing that organizing variable-sized fields (such as `text`, `varchar`, `arrays`, `json`, `jsonb`) at the end of the table could be sufficient for the workspaces table.\n\nUltimately, Chad took the initiative to implement the changes, moving all variable length fields to the end of the table, and documented the discussion as a comment to address review suggestions.\n\nWith this collaborative effort, the workspaces table was efficiently optimized, and the team gained valuable insights into database column ordering strategies.\n\n![DB](https://about.gitlab.com/images/blogimages/remote-development/DB.png){: .shadow.medium}\n\n## Ruby code review\nDuring the Ruby code review phase, we followed a meticulous approach by conducting a comprehensive self-review of every line of code. Our goal was to ensure the highest code quality and address any potential issues identified by the reviewers effectively.\n\nTo ensure clarity, it's important to clarify that the Ruby code review primarily focused on backend changes and server-side improvements. This included optimizing performance, enhancing functionalities, and refining the overall codebase to deliver a seamless user experience.\n\nFor the code review process, we referred to the [Code review documentation](https://docs.gitlab.com/ee/development/code_review.html), a valuable resource that guided us in maintaining industry best practices and adhering to the GitLab community's coding standards.\n\n### Example: Enhance error messages for unavailable features\nAs an example during the code review, we addressed an essential aspect of the workspace method, focusing on how we handle scenarios related to the `remote_development_feature_flag` and the `remote_development` licensed feature. The primary objective was to enhance the error messages presented to users when these features are not available.\n\nInitially, the code employed identical error messages for both cases, making it less clear to users whether the issue was due to a missing license or a disabled feature flag. This ambiguity could lead to confusion and hinder the user experience.\n\n#### The suggested improvement\nDuring the review, one of our maintainers, [Peter Leitzen](https://gitlab.com/splattael), raised an important question: \"Are we OK with having only a single error message for both cases (missing license and missing feature flag)?\"\n\nRecognizing the importance of clear communication, Chad proposed enhancing the error messages to provide distinct descriptions for each case. This improvement aimed to empower users by precisely conveying the reason behind the unavailability of certain features.\n\n#### The revised implementation\nFollowing Chad's suggestion, the code underwent the following changes:\n\n```ruby\nunless ::Feature.enabled?(:remote_development_feature_flag)\n # TODO: Could have `included Gitlab::Graphql::Authorize::AuthorizeResource` and then use\n # raise_resource_not_available_error!, but didn't want to take the risk to mix that into\n # the root query type\n raise ::Gitlab::Graphql::Errors::ResourceNotAvailable,\n \"'remote_development_feature_flag' feature flag is disabled\"\nend\n\nunless License.feature_available?(:remote_development)\n # TODO: Could have `included Gitlab::Graphql::Authorize::AuthorizeResource` and then use\n # raise_resource_not_available_error!, but didn't want to take the risk to mix that into\n # the root query type\n raise ::Gitlab::Graphql::Errors::ResourceNotAvailable,\n \"'remote_development' licensed feature is not available\"\nend\n\nraise_resource_not_available_error!('Feature is not available') unless current_user&.can?(:read_workspace)\n```\n\n#### The value of distinct error messages\nBy implementing distinct and descriptive error messages, we reinforce our commitment to user-centric development. Users interacting with our system will receive accurate feedback, helping them navigate potential roadblocks effectively. This enhancement not only improves the user experience but also streamlines troubleshooting and support processes.\n\nThis code review example highlights the significance of concise and informative error messages in delivering a top-notch user experience within the GitLab ecosystem. Our team's collaborative efforts ensure that users can confidently interact with our platform, knowing they'll receive clear and helpful error messages when needed.\n\n![BE1](https://about.gitlab.com/images/blogimages/remote-development/BE1.png){: .shadow.medium}\n\n### Example: Improving performance and addressing N+1 issues in WorkspaceType\nIn a recent code review, our team focused on optimizing the WorkspaceType and addressing potential N+1 query problems. The discussion involved two key contributors, [Laura Montemayor](https://gitlab.com/lauraX) and Chad, who worked together to enhance the performance of the codebase.\n\n#### Identifying the performance concerns\nDuring the review, Laura raised a performance concern regarding the possibility of N+1 queries in the WorkspaceType resolver. She suggested that preloading certain associations could be beneficial to avoid this common performance issue.\n\n#### A separate issue for N+1 control\nChad took prompt action and created a separate issue specifically aimed at resolving the N+1 query problems. The new issue, titled \"Address review feedback: Resolve N+1 issues,\" would address the concerns raised by Laura and implement the necessary preloading.\n\n#### Evaluating the potential N+1 impact\nChad provided insightful information about the low risk of real N+1 impact from two particular fields in the current implementation. He elaborated on how the queries for user and agent associations would largely be cache hits due to scoping and usage patterns. Chad diligently examined the cache hits happening in development, confirming the potential optimization.\n\nHere's a code snippet from the initial implementation:\n\n```ruby\n# Initial Implementation\nclass WorkspaceType \u003C BaseType\n field :user, ::Types::UserType,\n description: \"User associated with this workspace\",\n null: true\n\n field :agent, ::Types::AgentType,\n description: \"Agent associated with this workspace\",\n null: true\n\n # Resolver for the user association\n def user\n object.user\n end\n\n # Resolver for the agent association\n def agent\n object.agent\n end\nend\n```\n\n#### Treating performance as a priority\nBoth contributors acknowledged the significance of addressing the performance concern, with Laura emphasizing its importance. They agreed to prioritize the separate issue dedicated to resolving the N+1 queries and ensuring proper test coverage.\n\nHere's a code snippet from the revised implementation:\n\n```ruby\n# Revised Implementation with Preloading\nclass WorkspaceType \u003C BaseType\n field :user, ::Types::UserType,\n description: \"User associated with this workspace\",\n null: true\n\n field :agent, ::Types::AgentType,\n description: \"Agent associated with this workspace\",\n null: true\n\n # Resolver for the user association with preloading\n def user\n ::Dataloader.for(::User).load(object.user_id)\n end\n\n # Resolver for the agent association with preloading\n def agent\n ::Dataloader.for(::Agent).load(object.agent_id)\n end\nend\n```\n\n#### Considering future usage\nChad expressed excitement about the possibility of the new feature gaining significant usage. He humorously stated that encountering enough legitimate traffic on workspaces to trigger any performance impact would be a delightful problem to have, as it would indicate a growing user base.\n\n#### Collaboration and performance improvement\nThe code review exemplifies the collaborative and proactive approach of our team in optimizing the WorkspaceType. The team's dedication to addressing performance concerns ensures that our codebase remains performant and efficient, even as our user base grows.\n\n![BE2](https://about.gitlab.com/images/blogimages/remote-development/BE2.png){: .shadow.medium}\n\n## Frontend code review\nThe frontend code review process was managed by our resident `Create: IDE` frontend maintainers, [Paul Slaughter](https://gitlab.com/pslaughter) and [Enrique AlcΓ‘tara](https://gitlab.com/ealcantara). Additionally, a significant portion of the new frontend UI code had already undergone separate reviews and was merged to master, contributing to the overall quality of the Remote Development feature.\n\n### Example: Collaborative code improvement for ApolloCache Mutators\nPaul started a thread on an old version of the diff related to `ee/spec/frontend/remote_development/pages/create_spec.js``. The code snippet in question involved creating a mock Apollo instance and writing queries to the cache.\n\n#### The initial implementation\nInitially, the code involved writing to the cache twice, which raised concerns among the maintainers, Paul and Enrique. Paul pointed out that the duplicate write was unintentional and wondered if the writeQuery was even necessary, given the removal of @client directives. However, he also acknowledged the need to test that the created workspace was added to the ApolloCache.\n\n```javascript\n// Initial Implementation\nconst buildMockApollo = () => {\n // ... Other mock setup ...\n\n // Initial writeQuery for userWorkspacesQuery\n mockApollo.clients.defaultClient.cache.writeQuery({\n query: userWorkspacesQuery,\n data: USER_WORKSPACES_QUERY_EMPTY_RESULT.data,\n });\n\n // ... Other mock setup ...\n};\n```\n\n#### Identifying a potential issue\nEnrique agreed that the duplicate write was unintentional and probably introduced during a rebase. He explained that pre-populating the cache with a user workspaces query empty result was essential for the mutator to have a place to add the workspace. However, he encountered difficulties in making the workaround work effectively in unit tests.\n\n#### Resolving the issue\nPaul highlighted the significance of pre-populating the cache with the user workspaces query empty result. He suggested leaving a comment to explain the necessity of the initial writeQuery, as it would be implicitly coupled to future writeQuery operations.\n\n```javascript\n// Resolving the Issue - Leaving a Comment\n// Pre-populate the cache with user workspaces query empty result to provide a place\n// for the mutator to add the Workspace later. This is needed for both test and production environments.\nmockApollo.clients.defaultClient.cache.writeQuery({\n query: userWorkspacesQuery,\n data: USER_WORKSPACES_QUERY_EMPTY_RESULT.data,\n});\n```\n\nHowever, upon further investigation, Paul discovered that the writeQuery might not be needed, and the issue might be a symptom of an underlying problem. He decided to open a separate thread to address this concern and indicated that he would work on a separate MR to handle it.\n\n```javascript\n// Resolving the Issue - Opening a Separate Thread and MR\n// Open a separate thread to discuss potential underlying issues.\n// Plan to work on a separate MR to handle it.\n// Stay tuned for updates!\n```\n\n![FE](https://about.gitlab.com/images/blogimages/remote-development/FE.png){: .shadow.medium}\n\n## What we learned\nAs part of the Remote Development team, we faced the challenge of merging the Remote Development Rails monolith integration branch to meet our ambitious release goal. We adapted to last-minute pivots and focused on minimizing risks during the review process. The successful merge brought us one step closer to benefiting GitLab users worldwide. We acknowledged areas for improvement and remained committed to refining the feature's quality. Our journey reflects our dedication to delivering results, embracing change, and pushing boundaries in the DevOps community. The release of the Remote Development feature in GitLab 16.0 is a significant milestone for GitLab, and we continue to iterate and grow, providing innovative solutions for developers worldwide.\n\nAn outcome of this process was an ongoing conversation to propose a [simplified review process for greenfield features](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125117). Through this proposal, we aim to distill the lessons we learned during this experience and provide guidance to future teams facing similar challenges.\n\n## What is next for Remote Development?\nAfter the merge of the MR, several changes were implemented:\n- The first production tests were conducted to ensure the stability and functionality of the merged code.\n- Collaboration took place between the Dev Evangelism and Technical Marketing teams, focusing on [creating content](https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/190). This collaboration aimed to troubleshoot any issues that arose during the merge.\n- Feedback from the community was taken into account, and changes were made to address the concerns raised. This feedback was incorporated into an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/410031) and influenced the overall roadmap and direction of the project.\n\nDo you want to [contribute to GitLab](/community/contribute/)? Come and join in the conversation in the `#contribute` channel on GitLab's [Discord](https://discord.gg/gitlab), or just pop in and say \"Hi.\"\n\n",[23,24,25,26,27,28],"tutorial","DevSecOps","workflow","cloud native","contributors","open source","yml",{},true,"/en-us/blog/remote-development-beta",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":12,"ogImage":19,"ogUrl":34,"ogSiteName":35,"ogType":36,"canonicalUrls":34},"https://about.gitlab.com/blog/remote-development-beta","https://about.gitlab.com","article","en-us/blog/remote-development-beta",[23,39,25,40,27,41],"devsecops","cloud-native","open-source","sSd25rtl5foFf-4qdaTXH5xdMBR2mwvrTGfgpC-LTdI",{"data":44},{"logo":45,"freeTrial":50,"sales":55,"login":60,"items":65,"search":373,"minimal":404,"duo":423,"switchNav":432,"pricingDeployment":443},{"config":46},{"href":47,"dataGaName":48,"dataGaLocation":49},"/","gitlab logo","header",{"text":51,"config":52},"Get free trial",{"href":53,"dataGaName":54,"dataGaLocation":49},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":56,"config":57},"Talk to sales",{"href":58,"dataGaName":59,"dataGaLocation":49},"/sales/","sales",{"text":61,"config":62},"Sign in",{"href":63,"dataGaName":64,"dataGaLocation":49},"https://gitlab.com/users/sign_in/","sign in",[66,93,188,193,294,354],{"text":67,"config":68,"cards":70},"Platform",{"dataNavLevelOne":69},"platform",[71,77,85],{"title":67,"description":72,"link":73},"The intelligent orchestration platform for DevSecOps",{"text":74,"config":75},"Explore our Platform",{"href":76,"dataGaName":69,"dataGaLocation":49},"/platform/",{"title":78,"description":79,"link":80},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":81,"config":82},"Meet GitLab Duo",{"href":83,"dataGaName":84,"dataGaLocation":49},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":86,"description":87,"link":88},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":89,"config":90},"Learn more",{"href":91,"dataGaName":92,"dataGaLocation":49},"/why-gitlab/","why gitlab",{"text":94,"left":31,"config":95,"link":97,"lists":101,"footer":170},"Product",{"dataNavLevelOne":96},"solutions",{"text":98,"config":99},"View all Solutions",{"href":100,"dataGaName":96,"dataGaLocation":49},"/solutions/",[102,126,149],{"title":103,"description":104,"link":105,"items":110},"Automation","CI/CD and automation to accelerate deployment",{"config":106},{"icon":107,"href":108,"dataGaName":109,"dataGaLocation":49},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[111,115,118,122],{"text":112,"config":113},"CI/CD",{"href":114,"dataGaLocation":49,"dataGaName":112},"/solutions/continuous-integration/",{"text":78,"config":116},{"href":83,"dataGaLocation":49,"dataGaName":117},"gitlab duo agent platform - product menu",{"text":119,"config":120},"Source Code Management",{"href":121,"dataGaLocation":49,"dataGaName":119},"/solutions/source-code-management/",{"text":123,"config":124},"Automated Software Delivery",{"href":108,"dataGaLocation":49,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"Security","Deliver code faster without compromising security",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":49,"icon":133},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[135,139,144],{"text":136,"config":137},"Application Security Testing",{"href":131,"dataGaName":138,"dataGaLocation":49},"Application security testing",{"text":140,"config":141},"Software Supply Chain Security",{"href":142,"dataGaLocation":49,"dataGaName":143},"/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":148,"dataGaLocation":49},"/solutions/software-compliance/","software compliance",{"title":150,"link":151,"items":156},"Measurement",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":49},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[157,161,165],{"text":158,"config":159},"Visibility & Measurement",{"href":154,"dataGaLocation":49,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Value Stream Management",{"href":164,"dataGaLocation":49,"dataGaName":162},"/solutions/value-stream-management/",{"text":166,"config":167},"Analytics & Insights",{"href":168,"dataGaLocation":49,"dataGaName":169},"/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab for",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":49,"dataGaName":177},"/enterprise/","enterprise",{"text":179,"config":180},"Small Business",{"href":181,"dataGaLocation":49,"dataGaName":182},"/small-business/","small business",{"text":184,"config":185},"Public Sector",{"href":186,"dataGaLocation":49,"dataGaName":187},"/solutions/public-sector/","public sector",{"text":189,"config":190},"Pricing",{"href":191,"dataGaName":192,"dataGaLocation":49,"dataNavLevelOne":192},"/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":281},"Resources",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"View all resources",{"href":200,"dataGaName":196,"dataGaLocation":49},"/resources/",[202,235,253],{"title":203,"items":204},"Getting started",[205,210,215,220,225,230],{"text":206,"config":207},"Install",{"href":208,"dataGaName":209,"dataGaLocation":49},"/install/","install",{"text":211,"config":212},"Quick start guides",{"href":213,"dataGaName":214,"dataGaLocation":49},"/get-started/","quick setup checklists",{"text":216,"config":217},"Learn",{"href":218,"dataGaLocation":49,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Product documentation",{"href":223,"dataGaName":224,"dataGaLocation":49},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Best practice videos",{"href":228,"dataGaName":229,"dataGaLocation":49},"/getting-started-videos/","best practice videos",{"text":231,"config":232},"Integrations",{"href":233,"dataGaName":234,"dataGaLocation":49},"/integrations/","integrations",{"title":236,"items":237},"Discover",[238,243,248],{"text":239,"config":240},"Customer success stories",{"href":241,"dataGaName":242,"dataGaLocation":49},"/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":49},"/blog/","blog",{"text":249,"config":250},"Remote",{"href":251,"dataGaName":252,"dataGaLocation":49},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":254,"items":255},"Connect",[256,261,266,271,276],{"text":257,"config":258},"GitLab Services",{"href":259,"dataGaName":260,"dataGaLocation":49},"/services/","services",{"text":262,"config":263},"Community",{"href":264,"dataGaName":265,"dataGaLocation":49},"/community/","community",{"text":267,"config":268},"Forum",{"href":269,"dataGaName":270,"dataGaLocation":49},"https://forum.gitlab.com/","forum",{"text":272,"config":273},"Events",{"href":274,"dataGaName":275,"dataGaLocation":49},"/events/","events",{"text":277,"config":278},"Partners",{"href":279,"dataGaName":280,"dataGaLocation":49},"/partners/","partners",{"backgroundColor":282,"textColor":283,"text":284,"image":285,"link":289},"#2f2a6b","#fff","Insights for the future of software development",{"altText":286,"config":287},"the source promo card",{"src":288},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":290,"config":291},"Read the latest",{"href":292,"dataGaName":293,"dataGaLocation":49},"/the-source/","the source",{"text":295,"config":296,"lists":298},"Company",{"dataNavLevelOne":297},"company",[299],{"items":300},[301,306,312,314,319,324,329,334,339,344,349],{"text":302,"config":303},"About",{"href":304,"dataGaName":305,"dataGaLocation":49},"/company/","about",{"text":307,"config":308,"footerGa":311},"Jobs",{"href":309,"dataGaName":310,"dataGaLocation":49},"/jobs/","jobs",{"dataGaName":310},{"text":272,"config":313},{"href":274,"dataGaName":275,"dataGaLocation":49},{"text":315,"config":316},"Leadership",{"href":317,"dataGaName":318,"dataGaLocation":49},"/company/team/e-group/","leadership",{"text":320,"config":321},"Team",{"href":322,"dataGaName":323,"dataGaLocation":49},"/company/team/","team",{"text":325,"config":326},"Handbook",{"href":327,"dataGaName":328,"dataGaLocation":49},"https://handbook.gitlab.com/","handbook",{"text":330,"config":331},"Investor relations",{"href":332,"dataGaName":333,"dataGaLocation":49},"https://ir.gitlab.com/","investor relations",{"text":335,"config":336},"Trust Center",{"href":337,"dataGaName":338,"dataGaLocation":49},"/security/","trust center",{"text":340,"config":341},"AI Transparency Center",{"href":342,"dataGaName":343,"dataGaLocation":49},"/ai-transparency-center/","ai transparency center",{"text":345,"config":346},"Newsletter",{"href":347,"dataGaName":348,"dataGaLocation":49},"/company/contact/#contact-forms","newsletter",{"text":350,"config":351},"Press",{"href":352,"dataGaName":353,"dataGaLocation":49},"/press/","press",{"text":355,"config":356,"lists":357},"Contact us",{"dataNavLevelOne":297},[358],{"items":359},[360,363,368],{"text":56,"config":361},{"href":58,"dataGaName":362,"dataGaLocation":49},"talk to sales",{"text":364,"config":365},"Support portal",{"href":366,"dataGaName":367,"dataGaLocation":49},"https://support.gitlab.com","support portal",{"text":369,"config":370},"Customer portal",{"href":371,"dataGaName":372,"dataGaLocation":49},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":374,"login":375,"suggestions":382},"Close",{"text":376,"link":377},"To search repositories and projects, login to",{"text":378,"config":379},"gitlab.com",{"href":63,"dataGaName":380,"dataGaLocation":381},"search login","search",{"text":383,"default":384},"Suggestions",[385,387,391,393,397,401],{"text":78,"config":386},{"href":83,"dataGaName":78,"dataGaLocation":381},{"text":388,"config":389},"Code Suggestions (AI)",{"href":390,"dataGaName":388,"dataGaLocation":381},"/solutions/code-suggestions/",{"text":112,"config":392},{"href":114,"dataGaName":112,"dataGaLocation":381},{"text":394,"config":395},"GitLab on AWS",{"href":396,"dataGaName":394,"dataGaLocation":381},"/partners/technology-partners/aws/",{"text":398,"config":399},"GitLab on Google Cloud",{"href":400,"dataGaName":398,"dataGaLocation":381},"/partners/technology-partners/google-cloud-platform/",{"text":402,"config":403},"Why GitLab?",{"href":91,"dataGaName":402,"dataGaLocation":381},{"freeTrial":405,"mobileIcon":410,"desktopIcon":415,"secondaryButton":418},{"text":406,"config":407},"Start free trial",{"href":408,"dataGaName":54,"dataGaLocation":409},"https://gitlab.com/-/trials/new/","nav",{"altText":411,"config":412},"Gitlab Icon",{"src":413,"dataGaName":414,"dataGaLocation":409},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":411,"config":416},{"src":417,"dataGaName":414,"dataGaLocation":409},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":419,"config":420},"Get Started",{"href":421,"dataGaName":422,"dataGaLocation":409},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/get-started/","get started",{"freeTrial":424,"mobileIcon":428,"desktopIcon":430},{"text":425,"config":426},"Learn more about GitLab Duo",{"href":83,"dataGaName":427,"dataGaLocation":409},"gitlab duo",{"altText":411,"config":429},{"src":413,"dataGaName":414,"dataGaLocation":409},{"altText":411,"config":431},{"src":417,"dataGaName":414,"dataGaLocation":409},{"button":433,"mobileIcon":438,"desktopIcon":440},{"text":434,"config":435},"/switch",{"href":436,"dataGaName":437,"dataGaLocation":409},"#contact","switch",{"altText":411,"config":439},{"src":413,"dataGaName":414,"dataGaLocation":409},{"altText":411,"config":441},{"src":442,"dataGaName":414,"dataGaLocation":409},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":444,"mobileIcon":449,"desktopIcon":451},{"text":445,"config":446},"Back to pricing",{"href":191,"dataGaName":447,"dataGaLocation":409,"icon":448},"back to pricing","GoBack",{"altText":411,"config":450},{"src":413,"dataGaName":414,"dataGaLocation":409},{"altText":411,"config":452},{"src":417,"dataGaName":414,"dataGaLocation":409},{"title":454,"button":455,"config":460},"See how agentic AI transforms software delivery",{"text":456,"config":457},"Watch GitLab Transcend now",{"href":458,"dataGaName":459,"dataGaLocation":49},"/events/transcend/virtual/","transcend event",{"layout":461,"icon":462,"disabled":31},"release","AiStar",{"data":464},{"text":465,"source":466,"edit":472,"contribute":477,"config":482,"items":487,"minimal":691},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":467,"config":468},"View page source",{"href":469,"dataGaName":470,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":473,"config":474},"Edit this page",{"href":475,"dataGaName":476,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":478,"config":479},"Please contribute",{"href":480,"dataGaName":481,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":483,"facebook":484,"youtube":485,"linkedin":486},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[488,535,586,630,657],{"title":189,"links":489,"subMenu":504},[490,494,499],{"text":491,"config":492},"View plans",{"href":191,"dataGaName":493,"dataGaLocation":471},"view plans",{"text":495,"config":496},"Why Premium?",{"href":497,"dataGaName":498,"dataGaLocation":471},"/pricing/premium/","why premium",{"text":500,"config":501},"Why Ultimate?",{"href":502,"dataGaName":503,"dataGaLocation":471},"/pricing/ultimate/","why ultimate",[505],{"title":506,"links":507},"Contact Us",[508,511,513,515,520,525,530],{"text":509,"config":510},"Contact sales",{"href":58,"dataGaName":59,"dataGaLocation":471},{"text":364,"config":512},{"href":366,"dataGaName":367,"dataGaLocation":471},{"text":369,"config":514},{"href":371,"dataGaName":372,"dataGaLocation":471},{"text":516,"config":517},"Status",{"href":518,"dataGaName":519,"dataGaLocation":471},"https://status.gitlab.com/","status",{"text":521,"config":522},"Terms of use",{"href":523,"dataGaName":524,"dataGaLocation":471},"/terms/","terms of use",{"text":526,"config":527},"Privacy statement",{"href":528,"dataGaName":529,"dataGaLocation":471},"/privacy/","privacy statement",{"text":531,"config":532},"Cookie preferences",{"dataGaName":533,"dataGaLocation":471,"id":534,"isOneTrustButton":31},"cookie preferences","ot-sdk-btn",{"title":94,"links":536,"subMenu":545},[537,541],{"text":538,"config":539},"DevSecOps platform",{"href":76,"dataGaName":540,"dataGaLocation":471},"devsecops platform",{"text":542,"config":543},"AI-Assisted Development",{"href":83,"dataGaName":544,"dataGaLocation":471},"ai-assisted development",[546],{"title":547,"links":548},"Topics",[549,554,559,564,569,572,576,581],{"text":550,"config":551},"CICD",{"href":552,"dataGaName":553,"dataGaLocation":471},"/topics/ci-cd/","cicd",{"text":555,"config":556},"GitOps",{"href":557,"dataGaName":558,"dataGaLocation":471},"/topics/gitops/","gitops",{"text":560,"config":561},"DevOps",{"href":562,"dataGaName":563,"dataGaLocation":471},"/topics/devops/","devops",{"text":565,"config":566},"Version Control",{"href":567,"dataGaName":568,"dataGaLocation":471},"/topics/version-control/","version control",{"text":24,"config":570},{"href":571,"dataGaName":39,"dataGaLocation":471},"/topics/devsecops/",{"text":573,"config":574},"Cloud Native",{"href":575,"dataGaName":26,"dataGaLocation":471},"/topics/cloud-native/",{"text":577,"config":578},"AI for Coding",{"href":579,"dataGaName":580,"dataGaLocation":471},"/topics/devops/ai-for-coding/","ai for coding",{"text":582,"config":583},"Agentic AI",{"href":584,"dataGaName":585,"dataGaLocation":471},"/topics/agentic-ai/","agentic ai",{"title":587,"links":588},"Solutions",[589,591,593,598,602,605,609,612,614,617,620,625],{"text":136,"config":590},{"href":131,"dataGaName":136,"dataGaLocation":471},{"text":125,"config":592},{"href":108,"dataGaName":109,"dataGaLocation":471},{"text":594,"config":595},"Agile development",{"href":596,"dataGaName":597,"dataGaLocation":471},"/solutions/agile-delivery/","agile delivery",{"text":599,"config":600},"SCM",{"href":121,"dataGaName":601,"dataGaLocation":471},"source code management",{"text":550,"config":603},{"href":114,"dataGaName":604,"dataGaLocation":471},"continuous integration & delivery",{"text":606,"config":607},"Value stream management",{"href":164,"dataGaName":608,"dataGaLocation":471},"value stream management",{"text":555,"config":610},{"href":611,"dataGaName":558,"dataGaLocation":471},"/solutions/gitops/",{"text":174,"config":613},{"href":176,"dataGaName":177,"dataGaLocation":471},{"text":615,"config":616},"Small business",{"href":181,"dataGaName":182,"dataGaLocation":471},{"text":618,"config":619},"Public sector",{"href":186,"dataGaName":187,"dataGaLocation":471},{"text":621,"config":622},"Education",{"href":623,"dataGaName":624,"dataGaLocation":471},"/solutions/education/","education",{"text":626,"config":627},"Financial services",{"href":628,"dataGaName":629,"dataGaLocation":471},"/solutions/finance/","financial services",{"title":194,"links":631},[632,634,636,638,641,643,645,647,649,651,653,655],{"text":206,"config":633},{"href":208,"dataGaName":209,"dataGaLocation":471},{"text":211,"config":635},{"href":213,"dataGaName":214,"dataGaLocation":471},{"text":216,"config":637},{"href":218,"dataGaName":219,"dataGaLocation":471},{"text":221,"config":639},{"href":223,"dataGaName":640,"dataGaLocation":471},"docs",{"text":244,"config":642},{"href":246,"dataGaName":247,"dataGaLocation":471},{"text":239,"config":644},{"href":241,"dataGaName":242,"dataGaLocation":471},{"text":249,"config":646},{"href":251,"dataGaName":252,"dataGaLocation":471},{"text":257,"config":648},{"href":259,"dataGaName":260,"dataGaLocation":471},{"text":262,"config":650},{"href":264,"dataGaName":265,"dataGaLocation":471},{"text":267,"config":652},{"href":269,"dataGaName":270,"dataGaLocation":471},{"text":272,"config":654},{"href":274,"dataGaName":275,"dataGaLocation":471},{"text":277,"config":656},{"href":279,"dataGaName":280,"dataGaLocation":471},{"title":295,"links":658},[659,661,663,665,667,669,671,675,680,682,684,686],{"text":302,"config":660},{"href":304,"dataGaName":297,"dataGaLocation":471},{"text":307,"config":662},{"href":309,"dataGaName":310,"dataGaLocation":471},{"text":315,"config":664},{"href":317,"dataGaName":318,"dataGaLocation":471},{"text":320,"config":666},{"href":322,"dataGaName":323,"dataGaLocation":471},{"text":325,"config":668},{"href":327,"dataGaName":328,"dataGaLocation":471},{"text":330,"config":670},{"href":332,"dataGaName":333,"dataGaLocation":471},{"text":672,"config":673},"Sustainability",{"href":674,"dataGaName":672,"dataGaLocation":471},"/sustainability/",{"text":676,"config":677},"Diversity, inclusion and belonging (DIB)",{"href":678,"dataGaName":679,"dataGaLocation":471},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":335,"config":681},{"href":337,"dataGaName":338,"dataGaLocation":471},{"text":345,"config":683},{"href":347,"dataGaName":348,"dataGaLocation":471},{"text":350,"config":685},{"href":352,"dataGaName":353,"dataGaLocation":471},{"text":687,"config":688},"Modern Slavery Transparency Statement",{"href":689,"dataGaName":690,"dataGaLocation":471},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":692},[693,696,699],{"text":694,"config":695},"Terms",{"href":523,"dataGaName":524,"dataGaLocation":471},{"text":697,"config":698},"Cookies",{"dataGaName":533,"dataGaLocation":471,"id":534,"isOneTrustButton":31},{"text":700,"config":701},"Privacy",{"href":528,"dataGaName":529,"dataGaLocation":471},[703],{"id":704,"title":705,"body":8,"config":706,"content":708,"description":8,"extension":29,"meta":712,"navigation":31,"path":713,"seo":714,"stem":715,"__hash__":716},"blogAuthors/en-us/blog/authors/david-oregan.yml","David Oregan",{"template":707},"BlogAuthor",{"name":18,"config":709},{"headshot":710,"ctfId":711},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659853/Blog/Author%20Headshots/oregand-headshot.png","oregand",{},"/en-us/blog/authors/david-oregan",{},"en-us/blog/authors/david-oregan","CX5gLc3Gs5FrmvpMNVkBtC5zRi3vj8l3wJGnW0iSa6Y",[718,732,745],{"content":719,"config":730},{"body":720,"title":721,"description":722,"authors":723,"heroImage":725,"date":726,"category":9,"tags":727},"Most CI/CD tools can run a build and ship a deployment. Where they diverge is what happens when your delivery needs get real: a monorepo with a dozen services, microservices spread across multiple repositories, deployments to dozens of environments, or a platform team trying to enforce standards without becoming a bottleneck.\n \nGitLab's pipeline execution model was designed for that complexity. Parent-child pipelines, DAG execution, dynamic pipeline generation, multi-project triggers, merge request pipelines with merged results, and CI/CD Components each solve a distinct class of problems. Because they compose, understanding the full model unlocks something more than a faster pipeline. In this article, you'll learn about the five patterns where that model stands out, each mapped to a real engineering scenario with the configuration to match.\n \nThe configs below are illustrative. The scripts use echo commands to keep the signal-to-noise ratio low. Swap them out for your actual build, test, and deploy steps and they are ready to use.\n\n\n## 1. Monorepos: Parent-child pipelines + DAG execution\n\n\nThe problem: Your monorepo has a frontend, a backend, and a docs site. Every commit triggers a full rebuild of everything, even when only a README changed.\n\n\nGitLab solves this with two complementary features: [parent-child pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#parent-child-pipelines) (which let a top-level pipeline spawn isolated sub-pipelines) and [DAG execution via `needs`](https://docs.gitlab.com/ci/yaml/#needs) (which breaks rigid stage-by-stage ordering and lets jobs start the moment their dependencies finish).\n\n\nA parent pipeline detects what changed and triggers only the relevant child pipelines:\n\n```yaml\n# .gitlab-ci.yml\nstages:\n - trigger\n\ntrigger-services:\n stage: trigger\n trigger:\n include:\n - local: '.gitlab/ci/api-service.yml'\n - local: '.gitlab/ci/web-service.yml'\n - local: '.gitlab/ci/worker-service.yml'\n strategy: depend\n```\n\n\nEach child pipeline is a fully independent pipeline with its own stages, jobs, and artifacts. The parent waits for all of them via [strategy: depend](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#wait-for-downstream-pipeline-to-complete) so you get a single green/red signal at the top level, with full drill-down into each service's pipeline. This organizational separation is the bigger win for large teams: each service owns its pipeline config, changes in one cannot break another, and the complexity stays manageable as the repo grows.\n\n\nOne thing worth knowing: when you pass [multiple files to a single `trigger: include:`](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#combine-multiple-child-pipeline-configuration-files), GitLab merges them into a single child pipeline configuration. This means jobs defined across those files share the same pipeline context and can reference each other with `needs:`, which is what makes the DAG optimization possible. If you split them into separate trigger jobs instead, each would be its own isolated pipeline and cross-file `needs:` references would not work.\n\n\nCombine this with `needs:` inside each child pipeline and you get DAG execution. Your integration tests can start the moment the build finishes, without waiting for other jobs in the same stage.\n\n```yaml\n# .gitlab/ci/api-service.yml\nstages:\n - build\n - test\n\nbuild-api:\n stage: build\n script:\n - echo \"Building API service\"\n\ntest-api:\n stage: test\n needs: [build-api]\n script:\n - echo \"Running API tests\"\n```\n\n\nWhy it matters: Teams with large monorepos typically report significant reductions in pipeline runtime after switching to DAG execution, since jobs no longer wait on unrelated work in the same stage. Parent-child pipelines add the organizational layer that keeps the configuration maintainable as the repo and team grow.\n\n![Local downstream pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738759/Blog/Imported/hackathon-fake-blog-post-s/image3_vwj3rz.png \"Local downstream pipelines\")\n\n## 2. Microservices: Cross-repo, multi-project pipelines\n\n\nThe problem: Your frontend lives in one repo, your backend in another. When the frontend team ships a change, they have no visibility into whether it broke the backend integration and vice versa.\n\n\nGitLab's [multi-project pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#multi-project-pipelines) let one project trigger a pipeline in a completely separate project and wait for the result. The triggering project gets a linked downstream pipeline right in its own pipeline view.\n\n\nThe frontend pipeline builds an API contract artifact and publishes it, then triggers the backend pipeline. The backend fetches that artifact directly using the [Jobs API](https://docs.gitlab.com/ee/api/jobs.html#download-a-single-artifact-file-from-specific-tag-or-branch) and validates it before allowing anything to proceed. If a breaking change is detected, the backend pipeline fails and the frontend pipeline fails with it.\n\n```yaml\n# frontend repo: .gitlab-ci.yml\nstages:\n - build\n - test\n - trigger-backend\n\nbuild-frontend:\n stage: build\n script:\n - echo \"Building frontend and generating API contract...\"\n - mkdir -p dist\n - |\n echo '{\n \"api_version\": \"v2\",\n \"breaking_changes\": false\n }' > dist/api-contract.json\n - cat dist/api-contract.json\n artifacts:\n paths:\n - dist/api-contract.json\n expire_in: 1 hour\n\ntest-frontend:\n stage: test\n script:\n - echo \"All frontend tests passed!\"\n\ntrigger-backend-pipeline:\n stage: trigger-backend\n trigger:\n project: my-org/backend-service\n branch: main\n strategy: depend\n rules:\n - if: $CI_COMMIT_BRANCH == \"main\"\n```\n\n```yaml\n# backend repo: .gitlab-ci.yml\nstages:\n - build\n - test\n\nbuild-backend:\n stage: build\n script:\n - echo \"All backend tests passed!\"\n\nintegration-test:\n stage: test\n rules:\n - if: $CI_PIPELINE_SOURCE == \"pipeline\"\n script:\n - echo \"Fetching API contract from frontend...\"\n - |\n curl --silent --fail \\\n --header \"JOB-TOKEN: $CI_JOB_TOKEN\" \\\n --output api-contract.json \\\n \"${CI_API_V4_URL}/projects/${FRONTEND_PROJECT_ID}/jobs/artifacts/main/raw/dist/api-contract.json?job=build-frontend\"\n - cat api-contract.json\n - |\n if grep -q '\"breaking_changes\": true' api-contract.json; then\n echo \"FAIL: Breaking API changes detected - backend integration blocked!\"\n exit 1\n fi\n echo \"PASS: API contract is compatible!\"\n```\n\n\nA few things worth noting in this config. The `integration-test` job uses `$CI_PIPELINE_SOURCE == \"pipeline\"` to ensure it only runs when triggered by an upstream pipeline, not on a standalone push to the backend repo. The frontend project ID is referenced via `$FRONTEND_PROJECT_ID`, which should be set as a [CI/CD variable](https://docs.gitlab.com/ci/variables/) in the backend project settings to avoid hardcoding it.\n\n\nWhy it matters: Cross-service breakage that previously surfaced in production gets caught in the pipeline instead. The dependency between services stops being invisible and becomes something teams can see, track, and act on.\n\n\n![Cross-project pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738762/Blog/Imported/hackathon-fake-blog-post-s/image4_h6mfsb.png \"Cross-project pipelines\")\n\n\n## 3. Multi-tenant / matrix deployments: Dynamic child pipelines\n\n\nThe problem: You deploy the same application to 15 customer environments, or three cloud regions, or dev/staging/prod. Updating a deploy stage across all of them one by one is the kind of work that leads to configuration drift. Writing a separate pipeline for each environment is unmaintainable from day one.\n\n\nGitLab's [dynamic child pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#dynamic-child-pipelines) let you generate a pipeline at runtime. A job runs a script that produces a YAML file, and that YAML becomes the pipeline for the next stage. The pipeline structure itself becomes data.\n\n\n```yaml\n# .gitlab-ci.yml\nstages:\n - generate\n - trigger-environments\n\ngenerate-config:\n stage: generate\n script:\n - |\n # ENVIRONMENTS can be passed as a CI variable or read from a config file.\n # Default to dev, staging, prod if not set.\n ENVIRONMENTS=${ENVIRONMENTS:-\"dev staging prod\"}\n for ENV in $ENVIRONMENTS; do\n cat > ${ENV}-pipeline.yml \u003C\u003C EOF\n stages:\n - deploy\n - verify\n deploy-${ENV}:\n stage: deploy\n script:\n - echo \"Deploying to ${ENV} environment\"\n verify-${ENV}:\n stage: verify\n script:\n - echo \"Running smoke tests on ${ENV}\"\n EOF\n done\n artifacts:\n paths:\n - \"*.yml\"\n exclude:\n - \".gitlab-ci.yml\"\n\n.trigger-template:\n stage: trigger-environments\n trigger:\n strategy: depend\n\ntrigger-dev:\n extends: .trigger-template\n trigger:\n include:\n - artifact: dev-pipeline.yml\n job: generate-config\n\ntrigger-staging:\n extends: .trigger-template\n needs: [trigger-dev]\n trigger:\n include:\n - artifact: staging-pipeline.yml\n job: generate-config\n\ntrigger-prod:\n extends: .trigger-template\n needs: [trigger-staging]\n trigger:\n include:\n - artifact: prod-pipeline.yml\n job: generate-config\n when: manual\n```\n\n\nThe generation script loops over an `ENVIRONMENTS` variable rather than hardcoding each environment separately. Pass in a different list via a CI variable or read it from a config file and the pipeline adapts without touching the YAML. The trigger jobs use [extends:](https://docs.gitlab.com/ci/yaml/#extends) to inherit shared configuration from `.trigger-template`, so `strategy: depend` is defined once rather than repeated on every trigger job. Add a new environment by updating the variable, not by duplicating pipeline config. Add [when: manual](https://docs.gitlab.com/ci/yaml/#when) to the production trigger and you get a promotion gate baked right into the pipeline graph.\n\n\nWhy it matters: SaaS companies and platform teams use this pattern to manage dozens of environments without duplicating pipeline logic. The pipeline structure itself stays lean as the deployment matrix grows.\n\n\n![Dynamic pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738765/Blog/Imported/hackathon-fake-blog-post-s/image7_wr0kx2.png \"Dynamic pipeline\")\n\n\n## 4. MR-first delivery: Merge request pipelines, merged results, and workflow routing\n\n\nThe problem: Your pipeline runs on every push to every branch. Expensive tests run on feature branches that will never merge. Meanwhile, you have no guarantee that what you tested is actually what will land on `main` after a merge.\n\n\nGitLab has three interlocking features that solve this together:\n\n\n* [Merge request pipelines](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) run only when a merge request exists, not on every branch push. This alone eliminates a significant amount of wasted compute.\n\n* [Merged results pipelines](https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/) go further. GitLab creates a temporary merge commit (your branch plus the current target branch) and runs the pipeline against that. You are testing what will actually exist after the merge, not just your branch in isolation.\n\n* [Workflow rules](https://docs.gitlab.com/ci/yaml/workflow/) let you define exactly which pipeline type runs under which conditions and suppress everything else. The `$CI_OPEN_MERGE_REQUESTS` guard below prevents duplicate pipelines firing for both a branch and its open MR simultaneously.\n\n\nWith those three working together, here is what a tiered pipeline looks like:\n\n```yaml\n# .gitlab-ci.yml\nworkflow:\n rules:\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS\n when: never\n - if: $CI_COMMIT_BRANCH\n - if: $CI_PIPELINE_SOURCE == \"schedule\"\n\nstages:\n - fast-checks\n - expensive-tests\n - deploy\n\nlint-code:\n stage: fast-checks\n script:\n - echo \"Running linter\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"push\"\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\nunit-tests:\n stage: fast-checks\n script:\n - echo \"Running unit tests\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"push\"\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\nintegration-tests:\n stage: expensive-tests\n script:\n - echo \"Running integration tests (15 min)\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\ne2e-tests:\n stage: expensive-tests\n script:\n - echo \"Running E2E tests (30 min)\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n - if: $CI_COMMIT_BRANCH == \"main\"\n\nnightly-comprehensive-scan:\n stage: expensive-tests\n script:\n - echo \"Running full nightly suite (2 hours)\"\n rules:\n - if: $CI_PIPELINE_SOURCE == \"schedule\"\n\ndeploy-production:\n stage: deploy\n script:\n - echo \"Deploying to production\"\n rules:\n - if: $CI_COMMIT_BRANCH == \"main\"\n when: manual\n```\n\nWith this setup, the pipeline behaves differently depending on context. A push to a feature branch with no open MR runs lint and unit tests only. Once an MR is opened, the workflow rules switch from a branch pipeline to an MR pipeline, and the full integration and E2E suite runs against the merged result. Merging to `main` queues a manual production deployment. A nightly schedule runs the comprehensive scan once, not on every commit.\n\n\nWhy it matters: Teams routinely cut CI costs significantly with this pattern, not by running fewer tests, but by running the right tests at the right time. Merged results pipelines catch the class of bugs that only appear after a merge, before they ever reach `main`.\n\n\n![Conditional pipelines (within a branch with no MR)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738768/Blog/Imported/hackathon-fake-blog-post-s/image6_dnfcny.png \"Conditional pipelines (within a branch with no MR)\")\n\n\n\n![Conditional pipelines (within an MR)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738772/Blog/Imported/hackathon-fake-blog-post-s/image1_wyiafu.png \"Conditional pipelines (within an MR)\")\n\n\n\n![Conditional pipelines (on the main branch)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738774/Blog/Imported/hackathon-fake-blog-post-s/image5_r6lkfd.png \"Conditional pipelines (on the main branch)\")\n\n## 5. Governed pipelines: CI/CD Components\n\n\nThe problem: Your platform team has defined the right way to build, test, and deploy. But every team has their own `.gitlab-ci.yml` with subtle variations. Security scanning gets skipped. Deployment standards drift. Audits are painful.\n\n\nGitLab [CI/CD Components](https://docs.gitlab.com/ci/components/) let platform teams publish versioned, reusable pipeline building blocks. Application teams consume them with a single `include:` line and optional inputs β€” no copy-paste, no drift. Components are discoverable through the [CI/CD Catalog](https://docs.gitlab.com/ci/components/#cicd-catalog), which means teams can find and adopt approved building blocks without needing to go through the platform team directly.\n\n\nHere is a component definition from a shared library:\n\n```yaml\n# templates/deploy.yml\nspec:\n inputs:\n stage:\n default: deploy\n environment:\n default: production\n---\ndeploy-job:\n stage: $[[ inputs.stage ]]\n script:\n - echo \"Deploying $APP_NAME to $[[ inputs.environment ]]\"\n - echo \"Deploy URL: $DEPLOY_URL\"\n environment:\n name: $[[ inputs.environment ]]\n```\nAnd here is how an application team consumes it:\n\n```yaml\n# Application repo: .gitlab-ci.yml\nvariables:\n APP_NAME: \"my-awesome-app\"\n DEPLOY_URL: \"https://api.example.com\"\n\ninclude:\n - component: gitlab.com/my-org/component-library/build@v1.0.6\n - component: gitlab.com/my-org/component-library/test@v1.0.6\n - component: gitlab.com/my-org/component-library/deploy@v1.0.6\n inputs:\n environment: staging\n\nstages:\n - build\n - test\n - deploy\n```\n\nThree lines of `include:` replace hundreds of lines of duplicated YAML. The platform team can push a security fix to `v1.0.7` and teams opt in on their own schedule β€” or the platform team can pin everyone to a minimum version. Either way, one change propagates everywhere instead of needing to be applied repo by repo.\n\n\nPair this with [resource groups](https://docs.gitlab.com/ci/resource_groups/) to prevent concurrent deployments to the same environment, and [protected environments](https://docs.gitlab.com/ci/environments/protected_environments/) to enforce approval gates - and you have a governed delivery platform where compliance is the default, not the exception.\n\n\nWhy it matters: This is the pattern that makes GitLab CI/CD scale across hundreds of teams. Platform engineering teams enforce compliance without becoming a bottleneck. Application teams get a fast path to a working pipeline without reinventing the wheel.\n\n\n![Component pipeline (imported jobs)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738776/Blog/Imported/hackathon-fake-blog-post-s/image2_pizuxd.png \"Component pipeline (imported jobs)\")\n\n## Putting it all together\n\nNone of these features exist in isolation. The reason GitLab's pipeline model is worth understanding deeply is that these primitives compose:\n\n* A monorepo uses parent-child pipelines, and each child uses DAG execution\n\n* A microservices platform uses multi-project pipelines, and each project uses MR pipelines with merged results\n\n* A governed platform uses CI/CD components to standardize the patterns above across every team\n\n\nMost teams discover one of these features when they hit a specific pain point. The ones who invest in understanding the full model end up with a delivery system that actually reflects how their engineering organization works, not a pipeline that fights it.\n\n## Other patterns worth exploring\n\n\nThe five patterns above cover the most common structural pain points, but GitLab's pipeline model goes further. A few others worth looking into as your needs grow:\n\n\n* [Review apps with dynamic environments](https://docs.gitlab.com/ci/environments/) let you spin up a live preview for every feature branch and tear it down automatically when the MR closes. Useful for teams doing frontend work or API changes that need stakeholder sign-off before merging.\n\n* [Caching and artifact strategies](https://docs.gitlab.com/ci/caching/) are often the fastest way to cut pipeline runtime after the structural work is done. Structuring `cache:` keys around dependency lockfiles and being deliberate about what gets passed between jobs with [artifacts:](https://docs.gitlab.com/ci/yaml/#artifacts) can make a significant difference without changing your pipeline shape at all.\n\n* [Scheduled and API-triggered pipelines](https://docs.gitlab.com/ci/pipelines/schedules/) are worth knowing about because not everything should run on a code push. Nightly security scans, compliance reports, and release automation are better modeled as scheduled or [API-triggered](https://docs.gitlab.com/ci/triggers/) pipelines with `$CI_PIPELINE_SOURCE` routing the right jobs for each context.\n\n## How to get started\n\nModern software delivery is complex. Teams are managing monorepos with dozens of services, coordinating across multiple repositories, deploying to many environments at once, and trying to keep standards consistent as organizations grow. GitLab's pipeline model was built with all of that in mind.\n\nWhat makes it worth investing time in is how well the pieces fit together. Parent-child pipelines bring structure to large codebases. Multi-project pipelines make cross-team dependencies visible and testable. Dynamic pipelines turn environment management into something that scales gracefully. MR-first delivery with merged results ensures confidence at every step of the review process. And CI/CD Components give platform teams a way to share best practices across an entire organization without becoming a bottleneck.\n\nEach of these features is powerful on its own, and even more so when combined. GitLab gives you the building blocks to design a delivery system that fits how your team actually works, and grows with you as your needs evolve.\n\n> [Start a free trial of GitLab Ultimate](https://about.gitlab.com/free-trial/) to use pipeline logic today.\n\n## Read more\n\n* [Variable and artifact sharing in GitLab parent-child pipelines](https://about.gitlab.com/blog/variable-and-artifact-sharing-in-gitlab-parent-child-pipelines/)\n* [CI/CD inputs: Secure and preferred method to pass parameters to a pipeline](https://about.gitlab.com/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline/)\n* [Tutorial: How to set up your first GitLab CI/CD component](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n* [How to include file references in your CI/CD components](https://about.gitlab.com/blog/how-to-include-file-references-in-your-ci-cd-components/)\n* [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n* [Building a GitLab CI/CD pipeline for a monorepo the easy way](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n* [A CI/CD component builder's journey](https://about.gitlab.com/blog/a-ci-component-builders-journey/)\n* [CI/CD Catalog goes GA: No more building pipelines from scratch](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)","5 ways GitLab pipeline logic solves real engineering problems","Learn how to scale CI/CD with composable patterns for monorepos, microservices, environments, and governance.",[724],"Omid Khan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","2026-04-09",[112,728,23,729],"DevOps platform","features",{"featured":31,"template":13,"slug":731},"5-ways-gitlab-pipeline-logic-solves-real-engineering-problems",{"content":733,"config":743},{"title":734,"description":735,"authors":736,"heroImage":738,"date":739,"body":740,"category":9,"tags":741},"How to use GitLab Container Virtual Registry with Docker Hardened Images","Learn how to simplify container image management with this step-by-step guide.",[737],"Tim Rizzi","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772111172/mwhgbjawn62kymfwrhle.png","2026-03-12","If you're a platform engineer, you've probably had this conversation:\n \n*\"Security says we need to use hardened base images.\"*\n\n*\"Great, where do I configure credentials for yet another registry?\"*\n\n*\"Also, how do we make sure everyone actually uses them?\"*\n\nOr this one:\n\n*\"Why are our builds so slow?\"*\n\n*\"We're pulling the same 500MB image from Docker Hub in every single job.\"*\n\n*\"Can't we just cache these somewhere?\"*\n\nI've been working on [Container Virtual Registry](https://docs.gitlab.com/user/packages/virtual_registry/container/) at GitLab specifically to solve these problems. It's a pull-through cache that sits in front of your upstream registries β€” Docker Hub, dhi.io (Docker Hardened Images), MCR, and Quay β€” and gives your teams a single endpoint to pull from. Images get cached on the first pull. Subsequent pulls come from the cache. Your developers don't need to know or care which upstream a particular image came from.\n\nThis article shows you how to set up Container Virtual Registry, specifically with Docker Hardened Images in mind, since that's a combination that makes a lot of sense for teams concerned about security and not making their developers' lives harder.\n\n## What problem are we actually solving?\n\nThe Platform teams I usually talk to manage container images across three to five registries:\n\n* **Docker Hub** for most base images\n* **dhi.io** for Docker Hardened Images (security-conscious workloads)\n* **MCR** for .NET and Azure tooling\n* **Quay.io** for Red Hat ecosystem stuff\n* **Internal registries** for proprietary images\n\nEach one has its own:\n\n* Authentication mechanism\n* Network latency characteristics\n* Way of organizing image paths\n\nYour CI/CD configs end up littered with registry-specific logic. Credential management becomes a project unto itself. And every pipeline job pulls the same base images over the network, even though they haven't changed in weeks.\n\nContainer Virtual Registry consolidates this. One registry URL. One authentication flow (GitLab's). Cached images are served from GitLab's infrastructure rather than traversing the internet each time.\n\n## How it works\n\nThe model is straightforward:\n\n```text\nYour pipeline pulls:\n gitlab.com/virtual_registries/container/1000016/python:3.13\n\nVirtual registry checks:\n 1. Do I have this cached? β†’ Return it\n 2. No? β†’ Fetch from upstream, cache it, return it\n\n```\n\nYou configure upstreams in priority order. When a pull request comes in, the virtual registry checks each upstream until it finds the image. The result gets cached for a configurable period (default 24 hours).\n\n```text\nβ”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”\nβ”‚ CI/CD Pipeline β”‚\nβ”‚ β”‚ β”‚\nβ”‚ β–Ό β”‚\nβ”‚ gitlab.com/virtual_registries/container/\u003Cid>/image β”‚\nβ””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜\n β”‚\n β–Ό\nβ”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”\nβ”‚ Container Virtual Registry β”‚\nβ”‚ β”‚\nβ”‚ Upstream 1: Docker Hub ────────────────┐ β”‚\nβ”‚ Upstream 2: dhi.io (Hardened) ────────┐│ β”‚\nβ”‚ Upstream 3: MCR ─────────────────────┐││ β”‚\nβ”‚ Upstream 4: Quay.io ────────────────┐│││ β”‚\nβ”‚ β”‚β”‚β”‚β”‚ β”‚\nβ”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”΄β”΄β”΄β”€β”€β” β”‚\nβ”‚ β”‚ Cache β”‚ β”‚\nβ”‚ β”‚ (manifests + layers) β”‚ β”‚\nβ”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚\nβ””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜\n```\n\n## Why this matters for Docker Hardened Images\n\n[Docker Hardened Images](https://docs.docker.com/dhi/) are great because of the minimal attack surface, near-zero CVEs, proper software bills of materials (SBOMs), and SLSA provenance. If you're evaluating base images for security-sensitive workloads, they should be on your list.\n\nBut adopting them creates the same operational friction as any new registry:\n\n* **Credential distribution**: You need to get Docker credentials to every system that pulls images from dhi.io.\n* **CI/CD changes**: Every pipeline needs to be updated to authenticate with dhi.io.\n* **Developer friction**: People need to remember to use the hardened variants.\n* **Visibility gap**: It's difficult to tell if teams are actually using hardened images vs. regular ones.\n\nVirtual registry addresses each of these:\n\n**Single credential**: Teams authenticate to GitLab. The virtual registry handles upstream authentication. You configure Docker credentials once, at the registry level, and they apply to all pulls.\n\n**No CI/CD changes per-team**: Point pipelines at your virtual registry. Done. The upstream configuration is centralized.\n\n**Gradual adoption**: Since images get cached with their full path, you can see in the cache what's being pulled. If someone's pulling `library/python:3.11` instead of the hardened variant, you'll know.\n\n**Audit trail**: The cache shows you exactly which images are in active use. Useful for compliance, useful for understanding what your fleet actually depends on.\n\n## Setting it up\n\nHere's a real setup using the Python client from this demo project.\n\n### Create the virtual registry\n\n```python\nfrom virtual_registry_client import VirtualRegistryClient\n\nclient = VirtualRegistryClient()\n\nregistry = client.create_virtual_registry(\n group_id=\"785414\", # Your top-level group ID\n name=\"platform-images\",\n description=\"Cached container images for platform teams\"\n)\n\nprint(f\"Registry ID: {registry['id']}\")\n# You'll need this ID for the pull URL\n```\n\n### Add Docker Hub as an upstream\n\nFor official images like Alpine, Python, etc.:\n\n```python\ndocker_upstream = client.create_upstream(\n registry_id=registry['id'],\n url=\"https://registry-1.docker.io\",\n name=\"Docker Hub\",\n cache_validity_hours=24\n)\n```\n\n### Add Docker Hardened Images (dhi.io)\n\nDocker Hardened Images are hosted on `dhi.io`, a separate registry that requires authentication:\n\n```python\ndhi_upstream = client.create_upstream(\n registry_id=registry['id'],\n url=\"https://dhi.io\",\n name=\"Docker Hardened Images\",\n username=\"your-docker-username\",\n password=\"your-docker-access-token\",\n cache_validity_hours=24\n)\n```\n\n### Add other upstreams\n\n```python\n# MCR for .NET teams\nclient.create_upstream(\n registry_id=registry['id'],\n url=\"https://mcr.microsoft.com\",\n name=\"Microsoft Container Registry\",\n cache_validity_hours=48\n)\n\n# Quay for Red Hat stuff\nclient.create_upstream(\n registry_id=registry['id'],\n url=\"https://quay.io\",\n name=\"Quay.io\",\n cache_validity_hours=24\n)\n```\n\n### Update your CI/CD\n\nHere's a `.gitlab-ci.yml` that pulls through the virtual registry:\n\n```yaml\nvariables:\n VIRTUAL_REGISTRY_ID: \u003Cyour_virtual_registry_ID>\n\n \nbuild:\n image: docker:24\n services:\n - docker:24-dind\n before_script:\n # Authenticate to GitLab (which handles upstream auth for you)\n - echo \"${CI_JOB_TOKEN}\" | docker login -u gitlab-ci-token --password-stdin gitlab.com\n script:\n # All of these go through your single virtual registry\n \n # Official Docker Hub images (use library/ prefix)\n - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/library/alpine:latest\n \n # Docker Hardened Images from dhi.io (no prefix needed)\n - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/python:3.13\n \n # .NET from MCR\n - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/dotnet/sdk:8.0\n```\n\n### Image path formats\n\nDifferent registries use different path conventions:\n\n| Registry | Pull URL Example |\n|----------|------------------|\n| Docker Hub (official) | `.../library/python:3.11-slim` |\n| Docker Hardened Images (dhi.io) | `.../python:3.13` |\n| MCR | `.../dotnet/sdk:8.0` |\n| Quay.io | `.../prometheus/prometheus:latest` |\n\n### Verify it's working\n\nAfter some pulls, check your cache:\n\n```python\nupstreams = client.list_registry_upstreams(registry['id'])\nfor upstream in upstreams:\n entries = client.list_cache_entries(upstream['id'])\n print(f\"{upstream['name']}: {len(entries)} cached entries\")\n\n```\n\n## What the numbers look like\n\nI ran tests pulling images through the virtual registry:\n\n| Metric | Without Cache | With Warm Cache |\n|--------|---------------|-----------------|\n| Pull time (Alpine) | 10.3s | 4.2s |\n| Pull time (Python 3.13 DHI) | 11.6s | ~4s |\n| Network roundtrips to upstream | Every pull | Cache misses only |\n\n\n\n\nThe first pull is the same speed (it has to fetch from upstream). Every pull after that, for the cache validity period, comes straight from GitLab's storage. No network hop to Docker Hub, dhi.io, MCR, or wherever the image lives.\n\nFor a team running hundreds of pipeline jobs per day, that's hours of cumulative build time saved.\n\n## Practical considerations\nHere are some considerations to keep in mind:\n\n### Cache validity\n\n24 hours is the default. For security-sensitive images where you want patches quickly, consider 12 hours or less:\n\n```python\nclient.create_upstream(\n registry_id=registry['id'],\n url=\"https://dhi.io\",\n name=\"Docker Hardened Images\",\n username=\"your-username\",\n password=\"your-token\",\n cache_validity_hours=12\n)\n```\n\nFor stable, infrequently-updated images (like specific version tags), longer validity is fine.\n\n### Upstream priority\n\nUpstreams are checked in order. If you have images with the same name on different registries, the first matching upstream wins.\n\n### Limits\n\n* Maximum of 20 virtual registries per group\n* Maximum of 20 upstreams per virtual registry\n\n## Configuration via UI\n\nYou can also configure virtual registries and upstreams directly from the GitLab UIβ€”no API calls required. Navigate to your group's **Settings > Packages and registries > Virtual Registry** to:\n\n* Create and manage virtual registries\n* Add, edit, and reorder upstream registries\n* View and manage the cache\n* Monitor which images are being pulled\n\n## What's next\n\nWe're actively developing:\n\n* **Allow/deny lists**: Use regex to control which images can be pulled from specific upstreams.\n\nThis is beta software. It works, people are using it in production, but we're still iterating based on feedback.\n\n## Share your feedback\n\nIf you're a platform engineer dealing with container registry sprawl, I'd like to understand your setup:\n\n* How many upstream registries are you managing?\n* What's your biggest pain point with the current state?\n* Would something like this help, and if not, what's missing?\n\nPlease share your experiences in the [Container Virtual Registry feedback issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/589630).\n## Related resources\n- [New GitLab metrics and registry features help reduce CI/CD bottlenecks](https://about.gitlab.com/blog/new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks/#container-virtual-registry)\n- [Container Virtual Registry documentation](https://docs.gitlab.com/user/packages/virtual_registry/container/)\n- [Container Virtual Registry API](https://docs.gitlab.com/api/container_virtual_registries/)",[23,742,729],"product",{"featured":12,"template":13,"slug":744},"using-gitlab-container-virtual-registry-with-docker-hardened-images",{"content":746,"config":755},{"title":747,"description":748,"authors":749,"heroImage":751,"date":752,"category":9,"tags":753,"body":754},"How IIT Bombay students are coding the future with GitLab","At GitLab, we often talk about how software accelerates innovation. But sometimes, you have to step away from the Zoom calls and stand in a crowded university hall to remember why we do this.",[750],"Nick Veenhof","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099013/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2814%29_6VTUA8mUhOZNDaRVNPeKwl_1750099012960.png","2026-01-08",[265,624,28],"The GitLab team recently had the privilege of judging the **iHack Hackathon** at **IIT Bombay's E-Summit**. The energy was electric, the coffee was flowing, and the talent was undeniable. But what struck us most wasn't just the code β€” it was the sheer determination of students to solve real-world problems, often overcoming significant logistical and financial hurdles to simply be in the room.\n\n\nThrough our [GitLab for Education program](https://about.gitlab.com/solutions/education/), we aim to empower the next generation of developers with tools and opportunity. Here is a look at what the students built, and how they used GitLab to bridge the gap between idea and reality.\n\n## The challenge: Build faster, build securely\n\nThe premise for the GitLab track of the hackathon was simple: Don't just show us a product; show us how you built it. We wanted to see how students utilized GitLab's platform β€” from Issue Boards to CI/CD pipelines β€” to accelerate the development lifecycle.\n\nThe results were inspiring.\n\n## The winners\n\n### 1st place: Team Decode β€” Democratizing Scientific Research\n\n**Project:** FIRE (Fast Integrated Research Environment)\n\nTeam Decode took home the top prize with a solution that warms a developer's heart: a local-first, blazing-fast data processing tool built with [Rust](https://about.gitlab.com/blog/secure-rust-development-with-gitlab/) and Tauri. They identified a massive pain point for data science students: existing tools are fragmented, slow, and expensive.\n\nTheir solution, FIRE, allows researchers to visualize complex formats (like NetCDF) instantly. What impressed the judges most was their \"hacker\" ethos. They didn't just build a tool; they built it to be open and accessible.\n\n**How they used GitLab:** Since the team lived far apart, asynchronous communication was key. They utilized **GitLab Issue Boards** and **Milestones** to track progress and integrated their repo with Telegram to get real-time push notifications. As one team member noted, \"Coordinating all these technologies was really difficult, and what helped us was GitLab... the Issue Board really helped us track who was doing what.\"\n\n![Team Decode](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767380253/epqazj1jc5c7zkgqun9h.jpg)\n\n### 2nd place: Team BichdeHueDost β€” Reuniting to Solve Payments\n\n**Project:** SemiPay (RFID Cashless Payment for Schools)\n\nThe team name, BichdeHueDost, translates to \"Friends who have been set apart.\" It's a fitting name for a group of friends who went to different colleges but reunited to build this project. They tackled a unique problem: handling cash in schools for young children. Their solution used RFID cards backed by a blockchain ledger to ensure secure, cashless transactions for students.\n\n**How they used GitLab:** They utilized [GitLab CI/CD](https://about.gitlab.com/topics/ci-cd/) to automate the build process for their Flutter application (APK), ensuring that every commit resulted in a testable artifact. This allowed them to iterate quickly despite the \"flaky\" nature of cross-platform mobile development.\n\n![Team BichdeHueDost](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767380253/pkukrjgx2miukb6nrj5g.jpg)\n\n### 3rd place: Team ZenYukti β€” Agentic Repository Intelligence\n\n**Project:** RepoInsight AI (AI-powered, GitLab-native intelligence platform)\n\nTeam ZenYukti impressed us with a solution that tackles a universal developer pain point: understanding unfamiliar codebases. What stood out to the judges was the tool's practical approach to onboarding and code comprehension: RepoInsight-AI automatically generates documentation, visualizes repository structure, and even helps identify bugs, all while maintaining context about the entire codebase.\n\n**How they used GitLab:** The team built a comprehensive CI/CD pipeline that showcased GitLab's security and DevOps capabilities. They integrated [GitLab's Security Templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Security) (SAST, Dependency Scanning, and Secret Detection), and utilized [GitLab Container Registry](https://docs.gitlab.com/user/packages/container_registry/) to manage their Docker images for backend and frontend components. They created an AI auto-review bot that runs on merge requests, demonstrating an \"agentic workflow\" where AI assists in the development process itself.\n\n![Team ZenYukti](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767380253/ymlzqoruv5al1secatba.jpg)\n\n## Beyond the code: A lesson in inclusion\n\nWhile the code was impressive, the most powerful moment of the event happened away from the keyboard.\n\nDuring the feedback session, we learned about the journey Team ZenYukti took to get to Mumbai. They traveled over 24 hours, covering nearly 1,800 kilometers. Because flights were too expensive and trains were booked, they traveled in the \"General Coach,\" a non-reserved, severely overcrowded carriage.\n\nAs one student described it:\n\n*\"You cannot even imagine something like this... there are no seats... people sit on the top of the train. This is what we have endured.\"*\n\nThis hit home. [Diversity, Inclusion, and Belonging](https://handbook.gitlab.com/handbook/company/culture/inclusion/) are core values at GitLab. We realized that for these students, the barrier to entry wasn't intellect or skill, it was access.\n\nIn that moment, we decided to break that barrier. We committed to reimbursing the travel expenses for the participants who struggled to get there. It's a small step, but it underlines a massive truth: **talent is distributed equally, but opportunity is not.**\n\n![hackathon class together](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767380252/o5aqmboquz8ehusxvgom.jpg)\n\n### The future is bright (and automated)\n\nWe also saw incredible potential in teams like Prometheus, who attempted to build an autonomous patch remediation tool (DevGuardian), and Team Arrakis, who built a voice-first job portal for blue-collar workers using [GitLab Duo](https://about.gitlab.com/gitlab-duo-agent-platform/) to troubleshoot their pipelines.\n\nTo all the students who participated: You are the future. Through [GitLab for Education](https://about.gitlab.com/solutions/education/), we are committed to providing you with the top-tier tools (like GitLab Ultimate) you need to learn, collaborate, and change the world β€” whether you are coding from a dorm room, a lab, or a train carriage. **Keep shipping.**\n\n> :bulb: Learn more about the [GitLab for Education program](https://about.gitlab.com/solutions/education/).\n",{"slug":756,"featured":12,"template":13},"how-iit-bombay-students-code-future-with-gitlab",{"promotions":758},[759,773,784,796],{"id":760,"categories":761,"header":763,"text":764,"button":765,"image":770},"ai-modernization",[762],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":766,"config":767},"Get your AI maturity score",{"href":768,"dataGaName":769,"dataGaLocation":247},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":771},{"src":772},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":774,"categories":775,"header":776,"text":764,"button":777,"image":781},"devops-modernization",[742,39],"Are you just managing tools or shipping innovation?",{"text":778,"config":779},"Get your DevOps maturity score",{"href":780,"dataGaName":769,"dataGaLocation":247},"/assessments/devops-modernization-assessment/",{"config":782},{"src":783},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":785,"categories":786,"header":788,"text":764,"button":789,"image":793},"security-modernization",[787],"security","Are you trading speed for security?",{"text":790,"config":791},"Get your security maturity score",{"href":792,"dataGaName":769,"dataGaLocation":247},"/assessments/security-modernization-assessment/",{"config":794},{"src":795},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":797,"paths":798,"header":801,"text":802,"button":803,"image":808},"github-azure-migration",[799,800],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":804,"config":805},"See how GitLab compares to GitHub",{"href":806,"dataGaName":807,"dataGaLocation":247},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":809},{"src":783},{"header":811,"blurb":812,"button":813,"secondaryButton":818},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":814,"config":815},"Get your free trial",{"href":816,"dataGaName":54,"dataGaLocation":817},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":509,"config":819},{"href":58,"dataGaName":59,"dataGaLocation":817},1776442981473]