[{"data":1,"prerenderedAt":819},["ShallowReactive",2],{"/en-us/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment":3,"navigation-en-us":44,"banner-en-us":453,"footer-en-us":463,"blog-post-authors-en-us-Itzik Gan Baruch":701,"blog-related-posts-en-us-jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment":715,"blog-promotions-en-us":757,"next-steps-en-us":809},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":28,"externalUrl":29,"featured":14,"heroImage":19,"isFeatured":14,"meta":30,"navigation":31,"path":32,"publishedDate":20,"rawbody":33,"seo":34,"slug":13,"stem":38,"tagSlugs":39,"tags":42,"template":15,"updatedDate":29,"__hash__":43},"blogPosts/en-us/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment.yml","Jenkins to GitLab: The ultimate guide to modernizing your CI/CD environment",[7],"itzik-gan-baruch",[9],"Itzik Gan Baruch","\nIn today's dynamic landscape of software development, certain requirements have become paramount for delivering high-quality software rapidly. These requirements include the need for cloud compatibility, faster development cycles, improved collaboration, containerization, enhanced development experiences, and the integration of AI-driven capabilities for better efficiency and speed. Jenkins, a longstanding and respected continuous integration (CI) tool, has admirably played a role in many teams' software development for years. However, as more teams adopt DevOps/DevSecOps strategies for their software delivery, leveraging the integrated CI that is available in a DevSecOps platform like GitLab can provide benefits that Jenkins does not. \n\nSome organizations find themselves hesitating to migrate, not because they doubt the benefits of a top-tier [CI/CD](https://about.gitlab.com/topics/ci-cd/) solution such as GitLab, but due to the complexities of their existing Jenkins implementations. It's understandable that such a transition can seem daunting. \n\nIn this blog, you'll find several migration strategies to help transition from Jenkins to GitLab and make the process smoother and more manageable.\n\n## Migrating to GitLab\nIt's become evident that for organizations seeking a CI/CD solution that can seamlessly support their evolving demands, GitLab emerges as a powerful game-changer. Let's explore why transitioning to this advanced platform is transformative for Jenkins users.\n\n### Why migrate to GitLab \nBefore we delve into the migration approaches, let's take a moment to understand GitLab CI and what makes it a compelling choice for modern CI/CD needs.\n\n> Try GitLab CI/CD today with [a free trial of Ultimate](https://gitlab.com/-/trials/new).\n\n### GitLab CI overview\nGitLab CI is an integral part of the GitLab [AI-powered](https://about.gitlab.com/gitlab-duo-agent-platform/) DevSecOps Platform, which offers a comprehensive and unified solution for DevSecOps and CI/CD. GitLab's design revolves around streamlining development workflows, fostering collaboration, enhancing security, and ensuring scalability.\n\n### Key features of GitLab CI\nThese are the key features of GitLab CI:\n- **Unified platform:** GitLab CI is more than just a CI/CD tool; it's part of a broader ecosystem that includes source code management, project management, security features, analytics and more. This unified platform streamlines workflows and enhances collaboration among development teams.\n- **Containerization and orchestration:** GitLab CI/CD is designed with containerization in mind, offering native support for Docker and Kubernetes. This enables seamless integration of container technologies into your CI/CD pipelines.\n- **Security by design:** Security is a top priority, and GitLab CI incorporates features such as static code analysis and vulnerability scanning to help teams identify and address security issues early in the development process.\n- **GitOps principles:** GitLab CI aligns with [GitOps principles](https://about.gitlab.com/blog/the-ultimate-guide-to-gitops-with-gitlab/), emphasizing version-controlled, declarative configurations for infrastructure and application deployments. This approach enhances the reliability and repeatability of deployments.\n\nGet familiar with GitLab CI with this tutorial:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/WKR-7clknsA?si=T21Fe10Oa0rQ0SGB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWith that understanding of GitLab CI's capabilities, let's explore the migration steps and strategies for Jenkins users looking to leverage the benefits of GitLab CI.\n\n## A recommended step-by-step Jenkins-to-GitLab CI migration\nWhen considering a migration from Jenkins to GitLab CI, we strongly recommend following a well-structured, step-by-step approach to ensure a seamless transition. Here's our recommended process:\n1. **Pipeline assessment:** Start by conducting a comprehensive inventory of all your existing pipelines in Jenkins. This initial step will help you gain a clear understanding of the scope and complexity of the migration.\n2. **Parallel migration:** Begin the migration process by selecting individual pipelines and moving them to GitLab CI one at a time. Continue to maintain the use of Jenkins for your ongoing work during this transition to minimize disruptions.\n3. **Code verification:** We advise beginning with verification checks in CI. Run both the Jenkins and GitLab CI pipelines in parallel. This dual approach allows you to directly compare the two workflows and identify any issues in the new GitLab workflows. During this phase, keep the GitLab workflow as an optional choice while Jenkins remains required.\n4. **Continuous validation:** After running both pipelines in parallel for a full iteration, thoroughly evaluate the outcomes from each pipeline. This evaluation should consider various factors, including status codes, logs, and performance. \n5. **GitLab CI transition:** As you gain confidence in the reliability and effectiveness of GitLab CI through the parallel runs, make the transition to the GitLab CI workflow as the required standard while Jenkins continues to operate in the background.\n6. **Jenkins phaseout:** After a second iteration, when you are confident in the performance and stability of GitLab CI, you can begin to remove the Jenkins job from your code verification pipeline. This successful transition will enable you to retire Jenkins from this particular aspect of your CI/CD process.\n\nThis recommended approach ensures that your migration is a gradual evolution, allowing you to identify and address any issues or discrepancies before fully committing to GitLab CI. Running Jenkins and GitLab CI pipelines in parallel provides valuable insights and ensures the effective streamlining of your CI/CD processes.\n\n## Preparing for migration: Training and communication\nTo ensure a smooth and successful migration from Jenkins to GitLab CI, follow these essential steps:\n- **Stakeholder communication:** Start by announcing your migration plans and timelines to all relevant stakeholders. This includes DevOps teams, developers, and QA engineers. Transparency in communication is crucial to ensure that everyone understands the objectives and expectations of the migration.\n- **Knowledge-level training:** Conduct knowledge-level training sessions for your teams to promote GitLab CI adoption.\nCover topics such as using GitLab CI, understanding the YAML syntax, and how to create a basic pipeline.\nProvide team members with the knowledge and skills necessary to navigate the new GitLab CI environment effectively.\n- **Hands-on learning:** Encourage hands-on learning by pairing up developers.\nCreate opportunities for them to learn from each other's experiences throughout the migration process.\n\nBy following these instructions for training and communication, you'll build a strong foundation for a successful migration, empowering your teams to adapt and thrive in the new environment.\n\n## 3 Jenkins-to-GitLab CI migration strategies\nThere are different strategies to consider. These three strategies offer flexibility, allowing organizations to choose the path that best aligns with their specific needs and resources. Let's explore these strategies in detail to help you make an informed decision about which one suits your organization best.\n\n### Migration Strategy 1: Using GitLab CI for new projects\nThe first migration strategy involves a gradual transition. While you maintain your existing Jenkins infrastructure for ongoing projects, you introduce GitLab CI for new projects. This approach allows you to harness the modern features of GitLab CI without disrupting your current work.\n\n#### Benefits of Migration Strategy 1\nThe benefits of this approach include the following:\n- New projects can leverage GitLab CI's advanced features right from the start. \n- This strategy minimizes the risk of disrupting existing workflows, as your existing Jenkins setup remains intact.\n- Your team can gradually adapt to GitLab CI, building confidence and expertise without the pressure of an immediate full-scale migration.\n\n#### Challenges of Migration Strategy 1\nThe challenges of this approach include the following:\n- Operating two CI/CD platforms simultaneously can introduce complexity, especially in terms of integration and team collaboration.\n- Managing projects on different platforms may require careful coordination to ensure consistency in processes and security practices.\n\nThis strategy offers a smooth and manageable transition by allowing you to harness GitLab CI's strengths for new projects, while your existing Jenkins infrastructure continues to support ongoing work.\n\n### Migration Strategy 2: Migrating only strategic projects\nIn this strategy, you identify specific projects within your organization that stand to benefit the most from the capabilities of GitLab CI. Instead of preparing for a wholesale migration, you start by focusing your efforts on migrating these strategically selected projects first.\n\n#### Benefits of Migration Strategy 2\nThe benefits of this approach include the following:\n- By concentrating on key projects, you can realize significant improvements in those areas where GitLab CI aligns with specific needs.\n- This approach reduces the complexity of migrating everything at once, minimizing the potential for disruptions.\n- You can gradually build confidence with GitLab CI and its benefits before considering further migrations.\n\n#### Challenges of Migration Strategy 2\nThe challenges of this approach include the following:\n- Even though you're not migrating all projects, the chosen projects' migration can still be intricate and require careful planning.\n- Ensuring seamless collaboration between projects on different platforms may require additional attention.\n\nThis strategy allows you to maximize the impact of GitLab CI by focusing on strategic areas, minimizing risk, and gradually gaining experience with the new tool.\n\n### Migration Strategy 3: Migrating everything\nThe third strategy is a comprehensive migration where you commit to moving all your CI/CD processes, projects, and workflows to GitLab CI. This approach aims for uniformity and simplification of CI/CD across all projects. This strategy can benefit from taking an iterative approach. Consider starting with new projects, followed by migrating strategic projects, and then leverage your growing knowledge and experience with GitLab CI to complete the migration of remaining projects. \n\n#### Benefits of Migration Strategy 3\nThe benefits of this approach include the following:\n- Uniform CI/CD processes across all projects can streamline administration and maintenance, reducing complexity.\n- You can take full advantage of GitLab CI's modern capabilities, from Infrastructure as Code to enhanced security features.\n- As your projects grow, GitLab CI is designed to handle increased demands, ensuring long-term scalability.\n\n#### Challenges of Migration Strategy 3\nThe challenges of this approach include the following:\n- A full-scale migration can be intricate, requiring meticulous planning and implementation.\n- The transition may disrupt ongoing projects and require a significant time investment.\n- Investment in training and potential tool migration expenses should be considered.\n\nOpt for this approach if uniformity and consolidation of CI/CD processes are a high priority, and you have the resources to execute a full migration.\n\nThe migration strategy you select should align with your organization's specific needs and circumstances. In all cases, the ultimate goal is to enhance your development process with modern CI/CD tools like GitLab CI, which offers scalability, infrastructure automation, security, and collaboration features that align with today's development needs.\n\n## Technical insights: How the migration works\nMoving your CI/CD workflows from Jenkins to GitLab CI is a transformative journey, and understanding how it works is vital for a successful transition.\n\n### Understanding the configurations: Jenkinsfile vs. .gitlab-ci.yml\nThe heart of your CI/CD pipeline lies in the configurations defined in your Jenkinsfile (for Jenkins) and .gitlab-ci.yml (for GitLab CI). While there are some similarities between these configuration files, there are notable differences as well.\n\n#### Similarities\n- Both files define the stages, jobs, and steps of your CI/CD process.\n- You specify the desired build, test, and deployment steps in both files.\n- Environment variables and settings can be configured in either file.\n\n#### Differences\n- Jenkinsfile uses Groovy for scripting, while .gitlab-ci.yml uses YAML. This change in language affects the way you write and structure your configurations.\n- The process of defining pipelines is more intuitive in .gitlab-ci.yml, with a cleaner, more human-readable syntax.\n- GitLab CI provides a wide range of built-in templates and predefined jobs, simplifying configuration and reducing the need for custom scripting.\n\n### Manually converting the pipeline configuration\nCurrently, migrating your existing Jenkins pipelines to GitLab CI is typically done manually. This means analyzing your Jenkinsfile and re-creating the equivalent configurations in .gitlab-ci.yml. While there are similarities in the concepts and structure, the differences in syntax and the specific capabilities of each platform require careful consideration during the migration.\n\n## Strategic planning for a smooth transition\nMigrating from Jenkins to GitLab CI requires meticulous planning to ensure a seamless transition. It's crucial to assess the disparities between the two systems and evaluate their impact on your workflow, considering aspects like security, cost, time, and capacity.\n\nOnce you've identified these differences and devised your migration strategy, break down the migration into key steps. These include setting up GitLab CI pipelines, securely transferring data from Jenkins to GitLab CI, and integrating GitLab CI into your existing tools and processes. \n\n## Case study: A seamless transition for Lockheed Martin\nLet's look at a real-world case study to illustrate the effectiveness of the \"Migrate Everything\" strategy. [Lockheed Martin](https://about.gitlab.com/customers/lockheed-martin/), the world’s largest defense contractor, had been using Jenkins for several years. As their project portfolio expanded, they realized that their Jenkins implementation with a wide variety of DevOps tools was becoming increasingly complex to manage. They were also eager to adopt modern CI/CD capabilities that Jenkins struggled to provide.\n\nIn collaboration with GitLab, Lockheed Martin decided to undertake a comprehensive migration to GitLab CI. Their goals included achieving consistency in their CI/CD processes, simplifying administration and maintenance, and taking full advantage of The GitLab Platform’s robust features.\n\nThe comprehensive migration strategy proved to be a resounding success for Lockheed Martin. With GitLab CI, they not only streamlined their CI/CD processes but achieved remarkable results. **They managed to run CI pipeline builds a staggering 80 times faster, retired thousands of Jenkins servers, and reduced the time spent on system maintenance by a staggering 90%. This monumental shift resulted in a significant increase in efficiency and productivity for Lockheed Martin.**\n\nThis case study showcases how a comprehensive migration strategy can be effective for organizations looking to leverage GitLab capabilities across all their projects.\n\nFor more in-depth insights into Lockheed Martin's successful transition to GitLab and how it streamlined their software development processes, check out [the detailed case study](https://about.gitlab.com/customers/lockheed-martin/).\n\n## GitLab documentation and support\nFor those embarking on this migration journey, GitLab offers documentation to guide you through the process. You can find valuable resources in GitLab's [official documentation](https://docs.gitlab.com/ci/migration/jenkins/).\n\nIn addition to documentation, GitLab's Professional Services team is available to assist organizations in their migrations. They bring expertise and experience to ensure a smooth transition. Whether it's understanding the nuances of Jenkinsfile to .gitlab-ci.yml conversion or optimizing your CI/CD workflows, their support can be invaluable.\n\n> Try GitLab CI/CD today with [a free trial of Ultimate](https://gitlab.com/-/trials/new).\n","devsecops",{"slug":13,"featured":14,"template":15},"jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment",false,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21},"Learn how to migrate from Jenkins to the integrated CI/CD of the GitLab DevSecOps Platform to deliver high-quality software rapidly.",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","2023-11-01",[22,23,24,25,26,27],"tutorial","events","AI/ML","integrations","DevSecOps","DevOps","yml",null,{},true,"/en-us/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment","seo:\n  title: 'Jenkins to GitLab: The ultimate guide to modernizing your CI/CD environment'\n  description: >-\n    Learn how to migrate from Jenkins to the integrated CI/CD of the GitLab\n    DevSecOps Platform to deliver high-quality software rapidly.\n  ogTitle: 'Jenkins to GitLab: The ultimate guide to modernizing your CI/CD environment'\n  ogDescription: >-\n    Learn how to migrate from Jenkins to the integrated CI/CD of the GitLab\n    DevSecOps Platform to deliver high-quality software rapidly.\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png\n  ogUrl: >-\n    https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: >-\n    https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment\ncontent:\n  title: 'Jenkins to GitLab: The ultimate guide to modernizing your CI/CD environment'\n  description: >-\n    Learn how to migrate from Jenkins to the integrated CI/CD of the GitLab\n    DevSecOps Platform to deliver high-quality software rapidly.\n  authors:\n    - Itzik Gan Baruch\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png\n  date: '2023-11-01'\n  body: >\n\n    In today's dynamic landscape of software development, certain requirements\n    have become paramount for delivering high-quality software rapidly. These\n    requirements include the need for cloud compatibility, faster development\n    cycles, improved collaboration, containerization, enhanced development\n    experiences, and the integration of AI-driven capabilities for better\n    efficiency and speed. Jenkins, a longstanding and respected continuous\n    integration (CI) tool, has admirably played a role in many teams' software\n    development for years. However, as more teams adopt DevOps/DevSecOps\n    strategies for their software delivery, leveraging the integrated CI that is\n    available in a DevSecOps platform like GitLab can provide benefits that\n    Jenkins does not. \n\n\n    Some organizations find themselves hesitating to migrate, not because they\n    doubt the benefits of a top-tier\n    [CI/CD](https://about.gitlab.com/topics/ci-cd/) solution such as GitLab, but\n    due to the complexities of their existing Jenkins implementations. It's\n    understandable that such a transition can seem daunting. \n\n\n    In this blog, you'll find several migration strategies to help transition\n    from Jenkins to GitLab and make the process smoother and more manageable.\n\n\n    ## Migrating to GitLab\n\n    It's become evident that for organizations seeking a CI/CD solution that can\n    seamlessly support their evolving demands, GitLab emerges as a powerful\n    game-changer. Let's explore why transitioning to this advanced platform is\n    transformative for Jenkins users.\n\n\n    ### Why migrate to GitLab \n\n    Before we delve into the migration approaches, let's take a moment to\n    understand GitLab CI and what makes it a compelling choice for modern CI/CD\n    needs.\n\n\n    > Try GitLab CI/CD today with [a free trial of\n    Ultimate](https://gitlab.com/-/trials/new).\n\n\n    ### GitLab CI overview\n\n    GitLab CI is an integral part of the GitLab\n    [AI-powered](https://about.gitlab.com/gitlab-duo-agent-platform/) DevSecOps Platform, which\n    offers a comprehensive and unified solution for DevSecOps and CI/CD.\n    GitLab's design revolves around streamlining development workflows,\n    fostering collaboration, enhancing security, and ensuring scalability.\n\n\n    ### Key features of GitLab CI\n\n    These are the key features of GitLab CI:\n\n    - **Unified platform:** GitLab CI is more than just a CI/CD tool; it's part\n    of a broader ecosystem that includes source code management, project\n    management, security features, analytics and more. This unified platform\n    streamlines workflows and enhances collaboration among development teams.\n\n    - **Containerization and orchestration:** GitLab CI/CD is designed with\n    containerization in mind, offering native support for Docker and Kubernetes.\n    This enables seamless integration of container technologies into your CI/CD\n    pipelines.\n\n    - **Security by design:** Security is a top priority, and GitLab CI\n    incorporates features such as static code analysis and vulnerability\n    scanning to help teams identify and address security issues early in the\n    development process.\n\n    - **GitOps principles:** GitLab CI aligns with [GitOps\n    principles](https://about.gitlab.com/blog/the-ultimate-guide-to-gitops-with-gitlab/),\n    emphasizing version-controlled, declarative configurations for\n    infrastructure and application deployments. This approach enhances the\n    reliability and repeatability of deployments.\n\n\n    Get familiar with GitLab CI with this tutorial:\n\n\n    \u003C!-- blank line -->\n\n    \u003Cfigure class=\"video_container\">\n      \u003Ciframe src=\"https://www.youtube.com/embed/WKR-7clknsA?si=T21Fe10Oa0rQ0SGB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n    \u003C/figure>\n\n    \u003C!-- blank line -->\n\n\n    With that understanding of GitLab CI's capabilities, let's explore the\n    migration steps and strategies for Jenkins users looking to leverage the\n    benefits of GitLab CI.\n\n\n    ## A recommended step-by-step Jenkins-to-GitLab CI migration\n\n    When considering a migration from Jenkins to GitLab CI, we strongly\n    recommend following a well-structured, step-by-step approach to ensure a\n    seamless transition. Here's our recommended process:\n\n    1. **Pipeline assessment:** Start by conducting a comprehensive inventory of\n    all your existing pipelines in Jenkins. This initial step will help you gain\n    a clear understanding of the scope and complexity of the migration.\n\n    2. **Parallel migration:** Begin the migration process by selecting\n    individual pipelines and moving them to GitLab CI one at a time. Continue to\n    maintain the use of Jenkins for your ongoing work during this transition to\n    minimize disruptions.\n\n    3. **Code verification:** We advise beginning with verification checks in\n    CI. Run both the Jenkins and GitLab CI pipelines in parallel. This dual\n    approach allows you to directly compare the two workflows and identify any\n    issues in the new GitLab workflows. During this phase, keep the GitLab\n    workflow as an optional choice while Jenkins remains required.\n\n    4. **Continuous validation:** After running both pipelines in parallel for a\n    full iteration, thoroughly evaluate the outcomes from each pipeline. This\n    evaluation should consider various factors, including status codes, logs,\n    and performance. \n\n    5. **GitLab CI transition:** As you gain confidence in the reliability and\n    effectiveness of GitLab CI through the parallel runs, make the transition to\n    the GitLab CI workflow as the required standard while Jenkins continues to\n    operate in the background.\n\n    6. **Jenkins phaseout:** After a second iteration, when you are confident in\n    the performance and stability of GitLab CI, you can begin to remove the\n    Jenkins job from your code verification pipeline. This successful transition\n    will enable you to retire Jenkins from this particular aspect of your CI/CD\n    process.\n\n\n    This recommended approach ensures that your migration is a gradual\n    evolution, allowing you to identify and address any issues or discrepancies\n    before fully committing to GitLab CI. Running Jenkins and GitLab CI\n    pipelines in parallel provides valuable insights and ensures the effective\n    streamlining of your CI/CD processes.\n\n\n    ## Preparing for migration: Training and communication\n\n    To ensure a smooth and successful migration from Jenkins to GitLab CI,\n    follow these essential steps:\n\n    - **Stakeholder communication:** Start by announcing your migration plans\n    and timelines to all relevant stakeholders. This includes DevOps teams,\n    developers, and QA engineers. Transparency in communication is crucial to\n    ensure that everyone understands the objectives and expectations of the\n    migration.\n\n    - **Knowledge-level training:** Conduct knowledge-level training sessions\n    for your teams to promote GitLab CI adoption.\n\n    Cover topics such as using GitLab CI, understanding the YAML syntax, and how\n    to create a basic pipeline.\n\n    Provide team members with the knowledge and skills necessary to navigate the\n    new GitLab CI environment effectively.\n\n    - **Hands-on learning:** Encourage hands-on learning by pairing up\n    developers.\n\n    Create opportunities for them to learn from each other's experiences\n    throughout the migration process.\n\n\n    By following these instructions for training and communication, you'll build\n    a strong foundation for a successful migration, empowering your teams to\n    adapt and thrive in the new environment.\n\n\n    ## 3 Jenkins-to-GitLab CI migration strategies\n\n    There are different strategies to consider. These three strategies offer\n    flexibility, allowing organizations to choose the path that best aligns with\n    their specific needs and resources. Let's explore these strategies in detail\n    to help you make an informed decision about which one suits your\n    organization best.\n\n\n    ### Migration Strategy 1: Using GitLab CI for new projects\n\n    The first migration strategy involves a gradual transition. While you\n    maintain your existing Jenkins infrastructure for ongoing projects, you\n    introduce GitLab CI for new projects. This approach allows you to harness\n    the modern features of GitLab CI without disrupting your current work.\n\n\n    #### Benefits of Migration Strategy 1\n\n    The benefits of this approach include the following:\n\n    - New projects can leverage GitLab CI's advanced features right from the\n    start. \n\n    - This strategy minimizes the risk of disrupting existing workflows, as your\n    existing Jenkins setup remains intact.\n\n    - Your team can gradually adapt to GitLab CI, building confidence and\n    expertise without the pressure of an immediate full-scale migration.\n\n\n    #### Challenges of Migration Strategy 1\n\n    The challenges of this approach include the following:\n\n    - Operating two CI/CD platforms simultaneously can introduce complexity,\n    especially in terms of integration and team collaboration.\n\n    - Managing projects on different platforms may require careful coordination\n    to ensure consistency in processes and security practices.\n\n\n    This strategy offers a smooth and manageable transition by allowing you to\n    harness GitLab CI's strengths for new projects, while your existing Jenkins\n    infrastructure continues to support ongoing work.\n\n\n    ### Migration Strategy 2: Migrating only strategic projects\n\n    In this strategy, you identify specific projects within your organization\n    that stand to benefit the most from the capabilities of GitLab CI. Instead\n    of preparing for a wholesale migration, you start by focusing your efforts\n    on migrating these strategically selected projects first.\n\n\n    #### Benefits of Migration Strategy 2\n\n    The benefits of this approach include the following:\n\n    - By concentrating on key projects, you can realize significant improvements\n    in those areas where GitLab CI aligns with specific needs.\n\n    - This approach reduces the complexity of migrating everything at once,\n    minimizing the potential for disruptions.\n\n    - You can gradually build confidence with GitLab CI and its benefits before\n    considering further migrations.\n\n\n    #### Challenges of Migration Strategy 2\n\n    The challenges of this approach include the following:\n\n    - Even though you're not migrating all projects, the chosen projects'\n    migration can still be intricate and require careful planning.\n\n    - Ensuring seamless collaboration between projects on different platforms\n    may require additional attention.\n\n\n    This strategy allows you to maximize the impact of GitLab CI by focusing on\n    strategic areas, minimizing risk, and gradually gaining experience with the\n    new tool.\n\n\n    ### Migration Strategy 3: Migrating everything\n\n    The third strategy is a comprehensive migration where you commit to moving\n    all your CI/CD processes, projects, and workflows to GitLab CI. This\n    approach aims for uniformity and simplification of CI/CD across all\n    projects. This strategy can benefit from taking an iterative approach.\n    Consider starting with new projects, followed by migrating strategic\n    projects, and then leverage your growing knowledge and experience with\n    GitLab CI to complete the migration of remaining projects. \n\n\n    #### Benefits of Migration Strategy 3\n\n    The benefits of this approach include the following:\n\n    - Uniform CI/CD processes across all projects can streamline administration\n    and maintenance, reducing complexity.\n\n    - You can take full advantage of GitLab CI's modern capabilities, from\n    Infrastructure as Code to enhanced security features.\n\n    - As your projects grow, GitLab CI is designed to handle increased demands,\n    ensuring long-term scalability.\n\n\n    #### Challenges of Migration Strategy 3\n\n    The challenges of this approach include the following:\n\n    - A full-scale migration can be intricate, requiring meticulous planning and\n    implementation.\n\n    - The transition may disrupt ongoing projects and require a significant time\n    investment.\n\n    - Investment in training and potential tool migration expenses should be\n    considered.\n\n\n    Opt for this approach if uniformity and consolidation of CI/CD processes are\n    a high priority, and you have the resources to execute a full migration.\n\n\n    The migration strategy you select should align with your organization's\n    specific needs and circumstances. In all cases, the ultimate goal is to\n    enhance your development process with modern CI/CD tools like GitLab CI,\n    which offers scalability, infrastructure automation, security, and\n    collaboration features that align with today's development needs.\n\n\n    ## Technical insights: How the migration works\n\n    Moving your CI/CD workflows from Jenkins to GitLab CI is a transformative\n    journey, and understanding how it works is vital for a successful\n    transition.\n\n\n    ### Understanding the configurations: Jenkinsfile vs. .gitlab-ci.yml\n\n    The heart of your CI/CD pipeline lies in the configurations defined in your\n    Jenkinsfile (for Jenkins) and .gitlab-ci.yml (for GitLab CI). While there\n    are some similarities between these configuration files, there are notable\n    differences as well.\n\n\n    #### Similarities\n\n    - Both files define the stages, jobs, and steps of your CI/CD process.\n\n    - You specify the desired build, test, and deployment steps in both files.\n\n    - Environment variables and settings can be configured in either file.\n\n\n    #### Differences\n\n    - Jenkinsfile uses Groovy for scripting, while .gitlab-ci.yml uses YAML.\n    This change in language affects the way you write and structure your\n    configurations.\n\n    - The process of defining pipelines is more intuitive in .gitlab-ci.yml,\n    with a cleaner, more human-readable syntax.\n\n    - GitLab CI provides a wide range of built-in templates and predefined jobs,\n    simplifying configuration and reducing the need for custom scripting.\n\n\n    ### Manually converting the pipeline configuration\n\n    Currently, migrating your existing Jenkins pipelines to GitLab CI is\n    typically done manually. This means analyzing your Jenkinsfile and\n    re-creating the equivalent configurations in .gitlab-ci.yml. While there are\n    similarities in the concepts and structure, the differences in syntax and\n    the specific capabilities of each platform require careful consideration\n    during the migration.\n\n\n    ## Strategic planning for a smooth transition\n\n    Migrating from Jenkins to GitLab CI requires meticulous planning to ensure a\n    seamless transition. It's crucial to assess the disparities between the two\n    systems and evaluate their impact on your workflow, considering aspects like\n    security, cost, time, and capacity.\n\n\n    Once you've identified these differences and devised your migration\n    strategy, break down the migration into key steps. These include setting up\n    GitLab CI pipelines, securely transferring data from Jenkins to GitLab CI,\n    and integrating GitLab CI into your existing tools and processes. \n\n\n    ## Case study: A seamless transition for Lockheed Martin\n\n    Let's look at a real-world case study to illustrate the effectiveness of the\n    \"Migrate Everything\" strategy. [Lockheed\n    Martin](https://about.gitlab.com/customers/lockheed-martin/), the world’s\n    largest defense contractor, had been using Jenkins for several years. As\n    their project portfolio expanded, they realized that their Jenkins\n    implementation with a wide variety of DevOps tools was becoming increasingly\n    complex to manage. They were also eager to adopt modern CI/CD capabilities\n    that Jenkins struggled to provide.\n\n\n    In collaboration with GitLab, Lockheed Martin decided to undertake a\n    comprehensive migration to GitLab CI. Their goals included achieving\n    consistency in their CI/CD processes, simplifying administration and\n    maintenance, and taking full advantage of The GitLab Platform’s robust\n    features.\n\n\n    The comprehensive migration strategy proved to be a resounding success for\n    Lockheed Martin. With GitLab CI, they not only streamlined their CI/CD\n    processes but achieved remarkable results. **They managed to run CI pipeline\n    builds a staggering 80 times faster, retired thousands of Jenkins servers,\n    and reduced the time spent on system maintenance by a staggering 90%. This\n    monumental shift resulted in a significant increase in efficiency and\n    productivity for Lockheed Martin.**\n\n\n    This case study showcases how a comprehensive migration strategy can be\n    effective for organizations looking to leverage GitLab capabilities across\n    all their projects.\n\n\n    For more in-depth insights into Lockheed Martin's successful transition to\n    GitLab and how it streamlined their software development processes, check\n    out [the detailed case\n    study](https://about.gitlab.com/customers/lockheed-martin/).\n\n\n    ## GitLab documentation and support\n\n    For those embarking on this migration journey, GitLab offers documentation\n    to guide you through the process. You can find valuable resources in\n    GitLab's [official\n    documentation](https://docs.gitlab.com/ci/migration/jenkins/).\n\n\n    In addition to documentation, GitLab's Professional Services team is\n    available to assist organizations in their migrations. They bring expertise\n    and experience to ensure a smooth transition. Whether it's understanding the\n    nuances of Jenkinsfile to .gitlab-ci.yml conversion or optimizing your CI/CD\n    workflows, their support can be invaluable.\n\n\n    > Try GitLab CI/CD today with [a free trial of\n    Ultimate](https://gitlab.com/-/trials/new).\n  category: devsecops\n  tags:\n    - tutorial\n    - events\n    - AI/ML\n    - integrations\n    - DevSecOps\n    - DevOps\nconfig:\n  slug: jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment\n  featured: false\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":14,"ogImage":19,"ogUrl":35,"ogSiteName":36,"ogType":37,"canonicalUrls":35},"https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment","https://about.gitlab.com","article","en-us/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment",[22,23,40,25,11,41],"aiml","devops",[22,23,24,25,26,27],"4iiDKheE243d2AP7971aVj2tLfFO-kr06DByorU9NAo",{"data":45},{"logo":46,"freeTrial":51,"sales":56,"login":61,"items":66,"search":373,"minimal":404,"duo":423,"switchNav":432,"pricingDeployment":443},{"config":47},{"href":48,"dataGaName":49,"dataGaLocation":50},"/","gitlab logo","header",{"text":52,"config":53},"Get free trial",{"href":54,"dataGaName":55,"dataGaLocation":50},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":57,"config":58},"Talk to sales",{"href":59,"dataGaName":60,"dataGaLocation":50},"/sales/","sales",{"text":62,"config":63},"Sign in",{"href":64,"dataGaName":65,"dataGaLocation":50},"https://gitlab.com/users/sign_in/","sign in",[67,94,189,194,294,354],{"text":68,"config":69,"cards":71},"Platform",{"dataNavLevelOne":70},"platform",[72,78,86],{"title":68,"description":73,"link":74},"The intelligent orchestration platform for DevSecOps",{"text":75,"config":76},"Explore our Platform",{"href":77,"dataGaName":70,"dataGaLocation":50},"/platform/",{"title":79,"description":80,"link":81},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":82,"config":83},"Meet GitLab Duo",{"href":84,"dataGaName":85,"dataGaLocation":50},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":87,"description":88,"link":89},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":90,"config":91},"Learn more",{"href":92,"dataGaName":93,"dataGaLocation":50},"/why-gitlab/","why gitlab",{"text":95,"left":31,"config":96,"link":98,"lists":102,"footer":171},"Product",{"dataNavLevelOne":97},"solutions",{"text":99,"config":100},"View all Solutions",{"href":101,"dataGaName":97,"dataGaLocation":50},"/solutions/",[103,127,150],{"title":104,"description":105,"link":106,"items":111},"Automation","CI/CD and automation to accelerate deployment",{"config":107},{"icon":108,"href":109,"dataGaName":110,"dataGaLocation":50},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[112,116,119,123],{"text":113,"config":114},"CI/CD",{"href":115,"dataGaLocation":50,"dataGaName":113},"/solutions/continuous-integration/",{"text":79,"config":117},{"href":84,"dataGaLocation":50,"dataGaName":118},"gitlab duo agent platform - product menu",{"text":120,"config":121},"Source Code Management",{"href":122,"dataGaLocation":50,"dataGaName":120},"/solutions/source-code-management/",{"text":124,"config":125},"Automated Software Delivery",{"href":109,"dataGaLocation":50,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Security","Deliver code faster without compromising security",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":50,"icon":134},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"Application Security Testing",{"href":132,"dataGaName":139,"dataGaLocation":50},"Application security testing",{"text":141,"config":142},"Software Supply Chain Security",{"href":143,"dataGaLocation":50,"dataGaName":144},"/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software Compliance",{"href":148,"dataGaName":149,"dataGaLocation":50},"/solutions/software-compliance/","software compliance",{"title":151,"link":152,"items":157},"Measurement",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":50},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[158,162,166],{"text":159,"config":160},"Visibility & Measurement",{"href":155,"dataGaLocation":50,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"Value Stream Management",{"href":165,"dataGaLocation":50,"dataGaName":163},"/solutions/value-stream-management/",{"text":167,"config":168},"Analytics & Insights",{"href":169,"dataGaLocation":50,"dataGaName":170},"/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab for",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":50,"dataGaName":178},"/enterprise/","enterprise",{"text":180,"config":181},"Small Business",{"href":182,"dataGaLocation":50,"dataGaName":183},"/small-business/","small business",{"text":185,"config":186},"Public Sector",{"href":187,"dataGaLocation":50,"dataGaName":188},"/solutions/public-sector/","public sector",{"text":190,"config":191},"Pricing",{"href":192,"dataGaName":193,"dataGaLocation":50,"dataNavLevelOne":193},"/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":285},"Resources",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"View all resources",{"href":201,"dataGaName":197,"dataGaLocation":50},"/resources/",[203,235,258],{"title":204,"items":205},"Getting started",[206,211,216,221,226,231],{"text":207,"config":208},"Install",{"href":209,"dataGaName":210,"dataGaLocation":50},"/install/","install",{"text":212,"config":213},"Quick start guides",{"href":214,"dataGaName":215,"dataGaLocation":50},"/get-started/","quick setup checklists",{"text":217,"config":218},"Learn",{"href":219,"dataGaLocation":50,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Product documentation",{"href":224,"dataGaName":225,"dataGaLocation":50},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Best practice videos",{"href":229,"dataGaName":230,"dataGaLocation":50},"/getting-started-videos/","best practice videos",{"text":232,"config":233},"Integrations",{"href":234,"dataGaName":25,"dataGaLocation":50},"/integrations/",{"title":236,"items":237},"Discover",[238,243,248,253],{"text":239,"config":240},"Customer success stories",{"href":241,"dataGaName":242,"dataGaLocation":50},"/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":50},"/blog/","blog",{"text":249,"config":250},"The Source",{"href":251,"dataGaName":252,"dataGaLocation":50},"/the-source/","the source",{"text":254,"config":255},"Remote",{"href":256,"dataGaName":257,"dataGaLocation":50},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":259,"items":260},"Connect",[261,266,271,276,280],{"text":262,"config":263},"GitLab Services",{"href":264,"dataGaName":265,"dataGaLocation":50},"/services/","services",{"text":267,"config":268},"Community",{"href":269,"dataGaName":270,"dataGaLocation":50},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":50},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Events",{"href":279,"dataGaName":23,"dataGaLocation":50},"/events/",{"text":281,"config":282},"Partners",{"href":283,"dataGaName":284,"dataGaLocation":50},"/partners/","partners",{"textColor":286,"title":287,"text":288,"link":289},"#000","What’s new in GitLab","Stay updated with our latest features and improvements.",{"text":290,"config":291},"Read the latest",{"href":292,"dataGaName":293,"dataGaLocation":50},"/releases/whats-new/","whats new",{"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":50},"/company/","about",{"text":307,"config":308,"footerGa":311},"Jobs",{"href":309,"dataGaName":310,"dataGaLocation":50},"/jobs/","jobs",{"dataGaName":310},{"text":277,"config":313},{"href":279,"dataGaName":23,"dataGaLocation":50},{"text":315,"config":316},"Leadership",{"href":317,"dataGaName":318,"dataGaLocation":50},"/company/team/e-group/","leadership",{"text":320,"config":321},"Team",{"href":322,"dataGaName":323,"dataGaLocation":50},"/company/team/","team",{"text":325,"config":326},"Handbook",{"href":327,"dataGaName":328,"dataGaLocation":50},"https://handbook.gitlab.com/","handbook",{"text":330,"config":331},"Investor relations",{"href":332,"dataGaName":333,"dataGaLocation":50},"https://ir.gitlab.com/","investor relations",{"text":335,"config":336},"Trust Center",{"href":337,"dataGaName":338,"dataGaLocation":50},"/security/","trust center",{"text":340,"config":341},"AI Transparency Center",{"href":342,"dataGaName":343,"dataGaLocation":50},"/ai-transparency-center/","ai transparency center",{"text":345,"config":346},"Newsletter",{"href":347,"dataGaName":348,"dataGaLocation":50},"/company/contact/#contact-forms","newsletter",{"text":350,"config":351},"Press",{"href":352,"dataGaName":353,"dataGaLocation":50},"/press/","press",{"text":355,"config":356,"lists":357},"Contact us",{"dataNavLevelOne":297},[358],{"items":359},[360,363,368],{"text":57,"config":361},{"href":59,"dataGaName":362,"dataGaLocation":50},"talk to sales",{"text":364,"config":365},"Support portal",{"href":366,"dataGaName":367,"dataGaLocation":50},"https://support.gitlab.com","support portal",{"text":369,"config":370},"Customer portal",{"href":371,"dataGaName":372,"dataGaLocation":50},"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":64,"dataGaName":380,"dataGaLocation":381},"search login","search",{"text":383,"default":384},"Suggestions",[385,387,391,393,397,401],{"text":79,"config":386},{"href":84,"dataGaName":79,"dataGaLocation":381},{"text":388,"config":389},"Code Suggestions (AI)",{"href":390,"dataGaName":388,"dataGaLocation":381},"/solutions/code-suggestions/",{"text":113,"config":392},{"href":115,"dataGaName":113,"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":92,"dataGaName":402,"dataGaLocation":381},{"freeTrial":405,"mobileIcon":410,"desktopIcon":415,"secondaryButton":418},{"text":406,"config":407},"Start free trial",{"href":408,"dataGaName":55,"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":84,"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":192,"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":50},"/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":690},"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,585,629,656],{"title":190,"links":489,"subMenu":504},[490,494,499],{"text":491,"config":492},"View plans",{"href":192,"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":59,"dataGaName":60,"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":95,"links":536,"subMenu":545},[537,541],{"text":538,"config":539},"DevSecOps platform",{"href":77,"dataGaName":540,"dataGaLocation":471},"devsecops platform",{"text":542,"config":543},"AI-Assisted Development",{"href":84,"dataGaName":544,"dataGaLocation":471},"ai-assisted development",[546],{"title":547,"links":548},"Topics",[549,554,559,562,567,570,575,580],{"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":27,"config":560},{"href":561,"dataGaName":41,"dataGaLocation":471},"/topics/devops/",{"text":563,"config":564},"Version Control",{"href":565,"dataGaName":566,"dataGaLocation":471},"/topics/version-control/","version control",{"text":26,"config":568},{"href":569,"dataGaName":11,"dataGaLocation":471},"/topics/devsecops/",{"text":571,"config":572},"Cloud Native",{"href":573,"dataGaName":574,"dataGaLocation":471},"/topics/cloud-native/","cloud native",{"text":576,"config":577},"AI for Coding",{"href":578,"dataGaName":579,"dataGaLocation":471},"/topics/devops/ai-for-coding/","ai for coding",{"text":581,"config":582},"Agentic AI",{"href":583,"dataGaName":584,"dataGaLocation":471},"/topics/agentic-ai/","agentic ai",{"title":586,"links":587},"Solutions",[588,590,592,597,601,604,608,611,613,616,619,624],{"text":137,"config":589},{"href":132,"dataGaName":137,"dataGaLocation":471},{"text":126,"config":591},{"href":109,"dataGaName":110,"dataGaLocation":471},{"text":593,"config":594},"Agile development",{"href":595,"dataGaName":596,"dataGaLocation":471},"/solutions/agile-delivery/","agile delivery",{"text":598,"config":599},"SCM",{"href":122,"dataGaName":600,"dataGaLocation":471},"source code management",{"text":550,"config":602},{"href":115,"dataGaName":603,"dataGaLocation":471},"continuous integration & delivery",{"text":605,"config":606},"Value stream management",{"href":165,"dataGaName":607,"dataGaLocation":471},"value stream management",{"text":555,"config":609},{"href":610,"dataGaName":558,"dataGaLocation":471},"/solutions/gitops/",{"text":175,"config":612},{"href":177,"dataGaName":178,"dataGaLocation":471},{"text":614,"config":615},"Small business",{"href":182,"dataGaName":183,"dataGaLocation":471},{"text":617,"config":618},"Public sector",{"href":187,"dataGaName":188,"dataGaLocation":471},{"text":620,"config":621},"Education",{"href":622,"dataGaName":623,"dataGaLocation":471},"/solutions/education/","education",{"text":625,"config":626},"Financial services",{"href":627,"dataGaName":628,"dataGaLocation":471},"/solutions/finance/","financial services",{"title":195,"links":630},[631,633,635,637,640,642,644,646,648,650,652,654],{"text":207,"config":632},{"href":209,"dataGaName":210,"dataGaLocation":471},{"text":212,"config":634},{"href":214,"dataGaName":215,"dataGaLocation":471},{"text":217,"config":636},{"href":219,"dataGaName":220,"dataGaLocation":471},{"text":222,"config":638},{"href":224,"dataGaName":639,"dataGaLocation":471},"docs",{"text":244,"config":641},{"href":246,"dataGaName":247,"dataGaLocation":471},{"text":239,"config":643},{"href":241,"dataGaName":242,"dataGaLocation":471},{"text":254,"config":645},{"href":256,"dataGaName":257,"dataGaLocation":471},{"text":262,"config":647},{"href":264,"dataGaName":265,"dataGaLocation":471},{"text":267,"config":649},{"href":269,"dataGaName":270,"dataGaLocation":471},{"text":272,"config":651},{"href":274,"dataGaName":275,"dataGaLocation":471},{"text":277,"config":653},{"href":279,"dataGaName":23,"dataGaLocation":471},{"text":281,"config":655},{"href":283,"dataGaName":284,"dataGaLocation":471},{"title":295,"links":657},[658,660,662,664,666,668,670,674,679,681,683,685],{"text":302,"config":659},{"href":304,"dataGaName":297,"dataGaLocation":471},{"text":307,"config":661},{"href":309,"dataGaName":310,"dataGaLocation":471},{"text":315,"config":663},{"href":317,"dataGaName":318,"dataGaLocation":471},{"text":320,"config":665},{"href":322,"dataGaName":323,"dataGaLocation":471},{"text":325,"config":667},{"href":327,"dataGaName":328,"dataGaLocation":471},{"text":330,"config":669},{"href":332,"dataGaName":333,"dataGaLocation":471},{"text":671,"config":672},"Sustainability",{"href":673,"dataGaName":671,"dataGaLocation":471},"/sustainability/",{"text":675,"config":676},"Diversity, inclusion and belonging (DIB)",{"href":677,"dataGaName":678,"dataGaLocation":471},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":335,"config":680},{"href":337,"dataGaName":338,"dataGaLocation":471},{"text":345,"config":682},{"href":347,"dataGaName":348,"dataGaLocation":471},{"text":350,"config":684},{"href":352,"dataGaName":353,"dataGaLocation":471},{"text":686,"config":687},"Modern Slavery Transparency Statement",{"href":688,"dataGaName":689,"dataGaLocation":471},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":691},[692,695,698],{"text":693,"config":694},"Terms",{"href":523,"dataGaName":524,"dataGaLocation":471},{"text":696,"config":697},"Cookies",{"dataGaName":533,"dataGaLocation":471,"id":534,"isOneTrustButton":31},{"text":699,"config":700},"Privacy",{"href":528,"dataGaName":529,"dataGaLocation":471},[702],{"id":703,"title":9,"body":29,"config":704,"content":706,"description":29,"extension":28,"meta":710,"navigation":31,"path":711,"seo":712,"stem":713,"__hash__":714},"blogAuthors/en-us/blog/authors/itzik-gan-baruch.yml",{"template":705},"BlogAuthor",{"name":9,"config":707},{"headshot":708,"ctfId":709},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658921/Blog/Author%20Headshots/iganbaruch-headshot.jpg","iganbaruch",{},"/en-us/blog/authors/itzik-gan-baruch",{},"en-us/blog/authors/itzik-gan-baruch","bz9VMiTQ1ixvnoxUFk0jiUcnLG3oQsymgXNCqyRqfsk",[716,729,743],{"content":717,"config":727},{"title":718,"description":719,"authors":720,"heroImage":722,"date":723,"body":724,"category":11,"tags":725},"Teaching software development the easy way using GitLab","Learn how University of Washington lecturer Stephen G. Dame uses GitLab for Education to manage student assignments, distribute course materials, and provide inline code feedback at scale.\n",[721],"Rod Burns","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659537/Blog/Hero%20Images/display-article-image-0679-1800x945-fy26.png","2026-04-29","For instructors teaching software development, one of the biggest logistical challenges is assignment distribution and feedback at scale. How do you give large groups of students access to course materials, keep solution code private, and still deliver meaningful, contextual feedback without lots of administrative overhead?\n\nThe **[GitLab for Education program](https://about.gitlab.com/solutions/education/)** provides qualifying institutions with free access to **GitLab Ultimate**, enabling instructors to build professional-grade workflows that mirror real-world software development environments. In this article, you'll learn how Stephen G. Dame, a lecturer in the Computing and Software Systems department at the University of Washington, Bothell, uses simple workflows in GitLab to manage everything from course materials to student feedback across multiple classes.\n\n## From aerospace to academia: Bringing GitLab to the classroom\n\nDame came to academia with years of experience as a chief software engineer at Boeing Commercial Airplanes, where GitLab was used for aerospace projects. As an adjunct professor, he became an early advocate for GitLab within the university, joining the GitLab for Education program to access the full feature set needed to run structured, scalable course workflows.\n\n> **\"GitLab provides the greatest way to organize multiple classes, student assignments, lectures, and code samples through the use of Groups and Subgroups, which I found to be unique to GitLab compared to other repository platforms.\"**\n>\n> - Stephen G. Dame, University of Washington, Bothell\n\n## Set up groups: Build the right structure before writing a line of code\n\nThe foundation of an effective GitLab-based course is a well-planned group hierarchy. GitLab's **[Groups and Subgroups](https://docs.gitlab.com/tutorials/manage_user/#create-the-organization-parent-group-and-subgroups)** allow instructors to model the natural structure of a university department institution, course, and role with precise, inheritable permissions at every level.\n\nDame's structure places the university at the root (`UWTeaching`), with each course occupying its own subgroup (e.g. `css430`). Within each course sit repositories for `lecture-materials` and `code`, alongside dedicated Subgroups for `students` and `graders`. Instructor materials remain private, while student and grader subgroups are configured with controlled permissions so that assignment briefs and solutions are visible only to the right people.\n\n![Screenshot of GitLab group hierarchy — institution, course subgroup, and per-student subgroups](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777463673/dpxfnitv76pdmvcqtgag.png)\n\nPermissions cascade downward through the hierarchy via **Manage > Members**, allowing Dame to add students to a course's `students` subgroup with `Reporter` access and an expiration date tied to the end of the academic quarter. Students can clone and pull from assignment repositories but cannot push — keeping solution code firmly under instructor control.\n\nStudents are guided to set up SSH keys across all their working environments (local machines, cloud shells, virtual machines) so they can clone repositories and receive weekly updates via `git pull`. They copy relevant code into their own private repositories to manage their own version history.\n\n**Tip for large classes:** For larger cohorts, adding students by hand is impractical. GitLab's REST API lets you automate subgroup creation and membership from a list of usernames. Below is a sample Python script that handles this:\n\n```python\n    import gitlab\n    from datetime import datetime\n\n    # Connect to your GitLab instance\n    gl = gitlab.Gitlab('https://gitlab.com', private_token='YOUR_PRIVATE_TOKEN')\n\n    # Target parent group ID (e.g., the ID for \"css430 > students\")\n    parent_group_id = 12345678\n\n    # Set expiration: typically the beginning of the next month after quarter end\n    expiry_date = '2025-01-01'\n\n    # List of collected student usernames\n    student_list = ['alice_css430', 'bob_css430', 'carol_css430', 'dave_css430', 'eve_css430']\n\n    for username in student_list:\n        try:\n            # 1. Create a personal subgroup for the student\n            subgroup = gl.groups.create({\n                'name': username,\n                'path': username,\n                'parent_id': parent_group_id,\n                'visibility': 'private'\n            })\n\n            # 2. Add student to the new subgroup with Expiration\n            user = gl.users.list(username=username)[0]\n            subgroup.members.create({\n                'user_id': user.id,\n                'access_level': gitlab.const.REPORTER_ACCESS,\n                'expires_at': expiry_date\n            })\n            print(f\"Success: Subgroup created and student added for {username}\")\n        except Exception as e:\n            print(f\"Error processing {username}: {e}\")\n```\nThere is also an [open source project that automates class management](https://gitlab.com/edu-docs/class-management-automation) published by GitLab that provides additional tooling for this workflow.\n## Give feedback where the work actually lives\n\nOnce the structure is in place, the feedback workflow is where GitLab's value becomes most apparent to students. Dame asks students to submit assignments by opening a **[merge request](https://docs.gitlab.com/user/project/merge_requests/)** in their repository. This gives instructors an immediate, clean diff of everything the student has written.\n![A GitLab merge request showing inline code comment function for an instructor](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777467468/icclzyglbkwlvfysggbi.png)\nInstructors can click any line of code and leave an **inline comment** — not just flagging what is wrong, but explaining why, and pointing to what to look at next. Students receive this feedback in direct context with their code, which is far more actionable than a comment at the bottom of a submitted document.\n\n## Join GitLab for Education\n\nSetting up your first GitLab assignment takes some initial effort, but once the structure is in place it largely runs itself. The real payoff goes beyond organization: Students graduate having worked daily in an environment that mirrors professional software development, building habits around [version control](https://about.gitlab.com/topics/version-control/) and [code review](https://docs.gitlab.com/development/code_review/) rather than learning them as abstract concepts.\n\nIf you are just getting started, keep it simple. Begin with a single course group, one assignment template, and a basic pipeline. The structure will grow naturally alongside your confidence with the platform.\n\nMake sure to **[sign up for GitLab for Education](https://about.gitlab.com/solutions/education/join/)** so that you and your students can access all top-tier features, including unlimited reviewers on merge requests, additional compute minutes, and expanded storage.\n\n> [Apply to the GitLab for Education program today](https://about.gitlab.com/solutions/education/join/).",[623,726],"open source",{"featured":14,"template":15,"slug":728},"teaching-software-development-the-easy-way-using-gitlab",{"content":730,"config":741},{"description":731,"authors":732,"heroImage":734,"date":735,"title":736,"body":737,"category":11,"tags":738},"AI-generated code is 34% of development work. Discover how to balance productivity gains with quality, reliability, and security.",[733],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1767982271/e9ogyosmuummq7j65zqg.png","2026-01-08","AI is reshaping DevSecOps: Attend GitLab Transcend to see what’s next","AI promises a step change in innovation velocity, but most software teams are hitting a wall. According to our latest [Global DevSecOps Report](https://about.gitlab.com/developer-survey/), AI-generated code now accounts for 34% of all development work. Yet 70% of DevSecOps professionals report that AI is making compliance management more difficult, and 76% say agentic AI will create unprecedented security challenges.\n\nThis is the AI paradox: AI accelerates coding, but software delivery slows down as teams struggle to test, secure, and deploy all that code.\n\n## Productivity gains meet workflow bottlenecks\nThe problem isn't AI itself. It's how software gets built today. The traditional DevSecOps lifecycle contains hundreds of small tasks that developers must navigate manually: updating tickets, running tests, requesting reviews, waiting for approvals, fixing merge conflicts, addressing security findings. These tasks drain an average of seven hours per week from every team member, according to our research.\n\nDevelopment teams are producing code faster than ever, but that code still crawls through fragmented toolchains, manual handoffs, and disconnected processes. In fact, 60% of DevSecOps teams use more than five tools for software development overall, and 49% use more than five AI tools. This fragmentation creates collaboration barriers, with 94% of DevSecOps professionals experiencing factors that limit collaboration in the software development lifecycle.\n\nThe answer isn't more tools. It's intelligent orchestration that brings software teams and their AI agents together across projects and release cycles, with enterprise-grade security, governance, and compliance built in.\n\n## Seeking deeper human-AI partnerships\nDevSecOps professionals don't want AI to take over — they want reliable partnerships. The vast majority (82%) say using agentic AI would increase their job satisfaction, and 43% envision an ideal future with a 50/50 split between human and AI contributions. They're ready to trust AI with 37% of their daily tasks without human review, particularly for documentation, test writing, and code reviews.\n\nWhat we heard resoundingly from DevSecOps professionals is that AI won't replace them; rather, it will fundamentally reshape their roles. 83% of DevSecOps professionals believe AI will significantly change their work within five years, and notably, 76% think this will create more engineering jobs, not fewer. As coding becomes easier with AI, engineers who can architect systems, ensure quality, and apply business context will be in high demand.\n\nCritically, 88% agree there are essential human qualities that AI will never fully replace, including creativity, innovation, collaboration, and strategic vision.\n\nSo how can organizations bridge the gap between AI’s promise and the reality of fragmented workflows?\n\n## Join us at GitLab Transcend: Explore how to drive real value with agentic AI\nOn February 10, 2026, GitLab will be hosting Transcend, where we'll reveal how intelligent orchestration transforms AI-powered software development. You'll get a first look at GitLab's upcoming product roadmap and learn how teams are solving real-world challenges by modernizing development workflows with AI.\n\nOrganizations winning in this new era balance AI adoption with security, compliance, and platform consolidation. AI offers genuine productivity gains when implemented thoughtfully — not by replacing human developers, but by freeing DevSecOps professionals to focus on strategic thinking and creative innovation.\n\n[Register for Transcend today](https://about.gitlab.com/events/transcend/virtual/) to secure your spot and discover how intelligent orchestration can help your software teams stay in flow.",[24,739,740],"DevOps platform","security",{"featured":31,"template":15,"slug":742},"ai-is-reshaping-devsecops-attend-gitlab-transcend-to-see-whats-next",{"content":744,"config":755},{"title":745,"description":746,"authors":747,"heroImage":749,"date":750,"body":751,"category":11,"tags":752},"Atlassian ending Data Center as GitLab maintains deployment choice","As Atlassian transitions Data Center customers to cloud-only, GitLab presents a menu of deployment choices that map to business needs.",[748],"Emilio Salvador","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2025-10-07","Change is never easy, especially when it's not your choice. Atlassian's announcement that [all Data Center products will reach end-of-life by March 28, 2029](https://www.atlassian.com/blog/announcements/atlassian-ascend), means thousands of organizations must now reconsider their DevSecOps deployment and infrastructure. But you don't have to settle for deployment options that don't fit your needs. GitLab maintains your freedom to choose — whether you need self-managed for compliance, cloud for convenience, or hybrid for flexibility — all within a single AI-powered DevSecOps platform that respects your requirements.\n\nWhile other vendors force migrations to cloud-only architectures, GitLab remains committed to supporting the deployment choices that match your business needs. Whether you're managing sensitive government data, operating in air-gapped environments, or simply prefer the control of self-managed deployments, we understand that one size doesn't fit all.\n\n## The cloud isn't the answer for everyone\n\nFor the many companies that invested millions of dollars in Data Center deployments, including those that migrated to Data Center [after its Server products were discontinued](https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/), this announcement represents more than a product sunset. It signals a fundamental shift away from customer-centric architecture choices, forcing enterprises into difficult positions: accept a deployment model that doesn't fit their needs, or find a vendor that respects their requirements.\n\nMany of the organizations requiring self-managed deployments represent some of the world's most important organizations: healthcare systems protecting patient data, financial institutions managing trillions in assets, government agencies safeguarding national security, and defense contractors operating in air-gapped environments.\n\nThese organizations don't choose self-managed deployments for convenience; they choose them for compliance, security, and sovereignty requirements that cloud-only architectures simply cannot meet. Organizations operating in closed environments with restricted or no internet access aren't exceptions — they represent a significant portion of enterprise customers across various industries.\n\n![GitLab vs. Atlassian comparison table](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759928476/ynl7wwmkh5xyqhszv46m.jpg)\n\n## The real cost of forced cloud migration goes beyond dollars\n\nWhile cloud-only vendors frame mandatory migrations as \"upgrades,\" organizations face substantial challenges beyond simple financial costs:\n\n* **Lost integration capabilities:** Years of custom integrations with legacy systems, carefully crafted workflows, and enterprise-specific automations become obsolete. Organizations with deep integrations to legacy systems often find cloud migration technically infeasible.\n\n* **Regulatory constraints:** For organizations in regulated industries, cloud migration isn't just complex — it's often not permitted. Data residency requirements, air-gapped environments, and strict regulatory frameworks don't bend to vendor preferences. The absence of single-tenant solutions in many cloud-only approaches creates insurmountable compliance barriers.\n\n* **Productivity impacts:** Cloud-only architectures often require juggling multiple products: separate tools for planning, code management, CI/CD, and documentation. Each tool means another context switch, another integration to maintain, another potential point of failure. GitLab research shows [30% of developers spend at least 50% of their job maintaining and/or integrating their DevSecOps toolchain](https://about.gitlab.com/developer-survey/). Fragmented architectures exacerbate this challenge rather than solving it.\n\n## GitLab offers choice, commitment, and consolidation\n\nEnterprise customers deserve a trustworthy technology partner. That's why we've committed to supporting a range of deployment options — whether you need on-premises for compliance, hybrid for flexibility, or cloud for convenience, the choice remains yours. That commitment continues with [GitLab Duo](https://about.gitlab.com/gitlab-duo-agent-platform/), our AI solution that supports developers at every stage of their workflow.\n\nBut we offer more than just deployment flexibility. While other vendors might force you to cobble together their products into a fragmented toolchain, GitLab provides everything in a **comprehensive AI-native DevSecOps platform**. Source code management, CI/CD, security scanning, Agile planning, and documentation are all managed within a single application and a single vendor relationship.\n\nThis isn't theoretical. When Airbus and [Iron Mountain](https://about.gitlab.com/customers/iron-mountain/) evaluated their existing fragmented toolchains, they consistently identified challenges: poor user experience, missing functionalities like built-in security scanning and review apps, and management complexity from plugin troubleshooting. **These aren't minor challenges; they're major blockers for modern software delivery.**\n\n## Your migration path: Simpler than you think\n\nWe've helped thousands of organizations migrate from other vendors, and we've built the tools and expertise to make your transition smooth:\n\n* **Automated migration tools:** Our [Bitbucket Server importer](https://docs.gitlab.com/user/import/bitbucket_server/) brings over repositories, pull requests, comments, and even Large File Storage (LFS) objects. For Jira, our [built-in importer](https://docs.gitlab.com/user/project/import/jira/) handles issues, descriptions, and labels, with professional services available for complex migrations.\n\n* **Proven at scale:** A 500 GiB repository with 13,000 pull requests, 10,000 branches, and 7,000 tags is likely to [take just 8 hours to migrate](https://docs.gitlab.com/user/import/bitbucket_server/) from Bitbucket to GitLab using parallel processing.\n\n* **Immediate ROI:** A [Forrester Consulting Total Economic Impact™ study commissioned by GitLab](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/) found that investing in GitLab Ultimate confirms these benefits translate to real bottom-line impact, with a three-year 483% ROI, 5x time saved in security related activities, and 25% savings in software toolchain costs.\n\n## Start your journey to a unified DevSecOps platform\n\nForward-thinking organizations aren't waiting for vendor-mandated deadlines. They're evaluating alternatives now, while they have time to migrate thoughtfully to platforms that protect their investments and deliver on promises.\n\nOrganizations invest in self-managed deployments because they need control, compliance, and customization. When vendors deprecate these capabilities, they remove not just features but the fundamental ability to choose environments matching business requirements.\n\nModern DevSecOps platforms should offer complete functionality that respects deployment needs, consolidates toolchains, and accelerates software delivery, without forcing compromises on security or data sovereignty.\n\n[Talk to our sales team](https://about.gitlab.com/sales/) today about your migration options, or explore our [comprehensive migration resources](https://about.gitlab.com/move-to-gitlab-from-atlassian/) to see how thousands of organizations have already made the switch.\n\nYou also can [try GitLab Ultimate with GitLab Duo Enterprise](https://about.gitlab.com/free-trial/devsecops/) for free for 30 days to see what a unified DevSecOps platform can do for your organization.",[574,26,753,754],"product","features",{"featured":31,"template":15,"slug":756},"atlassian-ending-data-center-as-gitlab-maintains-deployment-choice",{"promotions":758},[759,773,784,795],{"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",[753,11],"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":787,"text":764,"button":788,"image":792},"security-modernization",[740],"Are you trading speed for security?",{"text":789,"config":790},"Get your security maturity score",{"href":791,"dataGaName":769,"dataGaLocation":247},"/assessments/security-modernization-assessment/",{"config":793},{"src":794},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":796,"paths":797,"header":800,"text":801,"button":802,"image":807},"github-azure-migration",[798,799],"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":803,"config":804},"See how GitLab compares to GitHub",{"href":805,"dataGaName":806,"dataGaLocation":247},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":808},{"src":783},{"header":810,"blurb":811,"button":812,"secondaryButton":817},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":813,"config":814},"Get your free trial",{"href":815,"dataGaName":55,"dataGaLocation":816},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":509,"config":818},{"href":59,"dataGaName":60,"dataGaLocation":816},1777493600920]