Customer Terrain Mapping Engagements

Customer Terrain Mapping Engagements provide customers with the benefit of GitLab’s experience with DevOps methodologies, Git, GitLab, CI, CD and monitoring by brainstorming a high level, first draft discovery of their specific challenges that need to be addressed for success in a scoped area of DevOps (a Terrain). The need for this generally arises when the customer is getting ready to utilize technologies and/or methodologies they are less familiar with.

Terrain Mapping Design Goals

  • Focus on discovering customer concerns in a scoped area (a Terrain) to apply GitLab solutions to their specific challenges on the ground.
  • Facilitate collaboration with customers on articulating critical success factors by co-creating a first draft of a terrain map.
  • To help customers and GitLab team members understand scenarios where professional services may play a significant and direct role in ensuring customers can be more successful with implementing and gaining value from GitLab. This directly supports the publicly stated mission of GitLab Professional Services as being an extension of Customer Success.
  • Generate results rapidly and efficiently through a co-worked document outlining considerations and scope in as little as one 60 minute session.
  • To enable reuse and extension, leverage single templates that include brief embedded training and instructions.
  • To enable diversity and inclusivity of inputs by using an open collaboration event to build out the deliverable.
  • Give the customer a first draft terrain map that can be iteratively improved.
  • To exhibit transparency by articulating all the things that are required for success, regardless of whether GitLab has services to offer for the items.
  • All of the above goals work together to broaden the scope of who can facilitate the session. Facilitation generally requires a technical background, but it is not limited to any specific technical role within GitLab.

Some Qualifiers

  • Regardless of whether the customer chooses not to use professional services, the document is a high-value artifact that they can develop further.
  • The Customer Terrain Mapping activity does not include detailed design discussions nor doing the actual work to make progress on any of the identified items.
  • Generally one Customer Terrain Map is offered per SA customer engagement.
  • If the customer chooses to use an applicable professional service, the engagement document will help rapidly understand the customer perspectives to scope and price the engagement. (Efficient reuse)

Further Iterations of Customer Terrain Maps

Like anything in the handbook, it is everyone’s responsibility and prerogative to improve these materials through corrections and enhancements. At the same time, Terrain Mapping reflects adherence to specific design principles to deliver the items documented above in Customer Terrain Mapping Design Goals. For those wishing to make substantial changes or generate entirely new Terrain maps, these design principles are documented here: Terrain Mapping Overview and Design Principles (GitLab Team Members Only)

GitLab Internal Enablement and Preparation Resources

Each Terrain Mapping Engagement Template has an instructions and preparation section that helps you get up to speed as quickly as possible.

For background, please also watch the original CS Enablement session - a link and instructions are provided near the top of Terrain Mapping Overview and Design Principles (GitLab Team Members Only)

Catalog of Customer Terrain Mapping Engagements

Preparation instructions are contained in each of the below. Some items are only accessible by GitLab Team members.

Please be sure to include all the sections when updating or adding Engagements.

  1. Terrain Mapping for Self Managed Implementation Review
  2. Terrain Mapping for Developer Skill Ramping Onto GitLab CI and CD
  3. Terrain Mapping Best Practices GitLab Self Managed
  4. Terrain Mapping for GitLab Migration Review
  5. Terrain Mapping for Gitflows, Workflow, Roles and Controls for SCM, CI and CD
  6. Terrain Mapping for Implementing GitLab Secure
  7. Terrain Mapping for Customer Internal Developer Enablement for GitLab CI
  8. Terrain Mapping For Specialized or Highly Scaled GitLab Runner Implementation
  9. Terrain Mapping for Integrating GitLab with Other Systems

Terrain Mapping for Self Managed Implementation Review

Status: Ready

Common Customer Challenge

​ Implementing the Self Managed GitLab

Customer Applicability Cues

  • Volume Cue: “We have over 3000 users that will be using our self managed GitLab instance and we need to ensure that its going to scale”
  • Velocity Cue: “We would like to have GitLab installed and configured within our Production environment by the end of this QTR”
  • Complexity Cue: " Our organization requires that GitLab be deployed Highly Available and with Disaster Recovery"
  • Experienced with Consuming Professional Services Cue: “There are many components that make up GitLab and we would like your experts to set this up for us so that we get started on a solid foundation”

Customers Transitions That Indicate a Potential Need For This

  • Initial Purchase of Self Managed

Existing Professional Services That May Help

Preparation Materials

​ Preparation materials (GitLab Team Members Only)

Outline: Terrain Mapping for Self Managed Implementation Review

  1. Project Overview
  2. Architecture Approach and Rationale
  3. Right sizing the implementation
  4. Architecture Tradeoffs
  5. Risk/issues and Mitigations
  6. Solution Alternatives
  7. Key Decision Points
  8. Concerns
  9. Key Assumptions

Terrain Mapping for Developer Skill Ramping Onto GitLab CI and CD

Status: Ready

Common Customer Challenge

​ Making Teams Productive on GitLab (Learning)

Customer Applicability Cues

  • Volume Cue: “We have about 300 people that would need to learn how to be productive on this new system”
  • Velocity Cue: “If we don’t get everyone up to speed before the 4th QTR starts, then we will have to wait until next year”
  • Complexity Cue: “GitLab has a lot of moving parts and understanding how to best manage and operate this platform is going to be difficult”
  • Experienced with Consuming Professional Services Cue: “Training is essential to success when adopting any solution within our organization and we hope that GitLab can provide educational services”

Customers Transitions That Indicate a Potential Need For This

  • Initial Purchase
  • Renewal
  • CI Stage Adoption

Existing Professional Services That May Help

Preparation Materials

​ Preparation materials (GitLab Team Members Only)

Outline: Terrain Mapping for Developer Skill Ramping Onto GitLab CI and CD

  1. Teams and Users

  2. Developer Focus

  3. Project Manager / Scrum Master Focus

  4. CI / CD Scope

  5. Shifting Security Left

  6. CI Coding Skills

  7. Simultaneous Changes

  8. Workflow / Change Gate Refactoring

  9. Integrations and Webhooks

  10. Encouraging Engagement and Completion

  11. Timeline

Terrain Mapping Best Practices GitLab Self Managed

Status: Ready

Common Customer Challenge

​ How to ensure GitLab is run as a production grade internal service when self managed.

Customer Applicability Cues

  • Complexity Cues: “How do we backup the new instance and how do we test our disaster recovery ability?"
    “How do we assign permissions to the many runners we will have?”
  • Experienced with Consuming Professional Services Cue: “Do you have documentation on all the activities we will need to undertake to manage our self-managed instance similar to how you run GitLab.com?”

Customers Transitions That Indicate a Potential Need For This

  • Initial Purchase of Self-Managed
  • Re-Platforming Existing GitLab Installation
  • Moving to from GitLab SaaS to Self-Managed
  • Stabilty Issues / Version Stagnation of Existing Self Managed GitLab Instance

Existing Professional Services That May Help

Preparation Materials

​ Preparation materials (GitLab Team Members Only)

Outline: Terrain Mapping Best Practices

For Operating Self Managed GitLab as a Production-Grade Internal Service

  1. Teams and Users
  2. Existing Pipeline Code Analysis
  3. Existing Pipeline 3rd Party Integrations
  4. Developer Enablement (templating for rapid onboarding)
  5. Shifting Security Left
  6. CI / CD Scaling Requirements
  7. New Integrations and Webhooks
  8. What Specific Existing Pipeline Features Should be Templatized
  9. Tool Retirements / Consolidation
  10. What Deployment Environments Need to Be Supported
  11. Timeline

Terrain Mapping for GitLab Migration Review

Status: Ready

Common Customer Challenge

​ Data and/or Integrated Systems Cutover Into GitLab (All at once migration)

Customer Applicability Cues

  • Volume Cue: “We will be migrating over 300 projects/repos (GIT) from our previous SCM that needs to be migrated over to GitLab”
  • Velocity Cue: “We need to migrate/transcribe over 500 pipelines from our previous CI/CD tool before we can even begin to use GitLab”
  • Complexity Cue: " We are new to GIT and would need our current codebase converted from SVN/TFS/CVS to GIT in order to use GitLab”
  • Experienced with Consuming Professional Services Cue: “We have many repos that need to be migrated or converted to GIT and we don’t have the time or resources to do it ourselves and require your services”

Customers Transitions That Indicate a Potential Need For This

  • Initial Purchase

Existing Professional Services That May Help

Preparation Materials

​ Preparation materials (GitLab Team Members Only)

Outline: GitLab Migration Review

  1. Business Background

  2. Scope & Approach

  3. Migration Complexity Questions

  4. Risk/issues and Mitigations

  5. Team App Feature Delivery Velocity Allocation

  6. Timeline

Terrain Mapping for Gitflows, Workflow, Roles and Controls for SCM, CI and CD

Status: Ready

Common Customer Challenge

​ Creating a GitFlow / GitLab Flow for Code and Possibly Deployment Including Workflow Controls

Customer Applicability Cues

  • Volume Cue: “We need all 83 of our development teams to be using the same GitFlow processes and it seems like it will be difficult to reculture one team at a time.”
  • Velocity Cue: “We want developers to be upgrading their workflow control game as they onboard to the new GitLab based DevOps services we are defining.”
  • Complexity Cue: “There are so many settings and possibilities for GitLab Workflow that our developers are struggling to understand what to configure to both to adapt and improve our current process when moving to GitLab.”
  • Experienced with Consuming Professional Services Cue: “Can you provide professional services to help us come up with a new model of our code quality and deployment workflows?”

Customers Transitions That Indicate a Potential Need For This

  • Initial Purchase
  • CI Stage Adoption
  • CD Stage Adoption

Existing Professional Services That May Help

Preparation Materials

​ Preparation materials (GitLab Team Members Only)

Outline: Terrain Mapping for Gitflows, Workflow, Roles and Controls for SCM, CI and CD

  1. Teams and Users

  2. Code Integrity

  3. Who Should Be Involved in Code Review

  4. What Should Merge Approvals Look Like

  5. What Should Branch Protections Look Like

  6. Critical Files / Directories To Protect

  7. Separation of Duties

  8. Protected Branches, Tags, Environments and Runners

  9. Compliance Requirements

  10. Microservices Workflows

  11. Who Should Be Involved in Deployment Approval

  12. Deployment Complexity

  13. User Specific Group Hierarchy

  14. Repository Group Hierarchy

  15. Audit Activities and Roles

  16. Timeline

Terrain Mapping for Implementing GitLab Secure

Status: Ready

Common Customer Challenge

​ Helping customers plan for successful implementation of GitLab Secure

Customer Applicability Cues

  • Volume Cue: “We need all 52 of our development teams to be up their DevSecOps game as soon as possible.”
  • Velocity Cue: “We want all developers to be leveraging GitLab Secure features within two quarters of purchasing it.”
  • Complexity Cue: “We loved the demos, but we have to admit we are a bit overwhelmed by exactly what configuration should be implemented to ensure we are leveraging the full Secure feature set.”
  • Experienced with Consuming Professional Services Cue: “Can your professional services area work with us to define and build a working example project that leverages all of the GitLab Secure capabilities we need?”

Customers Transitions That Indicate a Potential Need For This

  • Initial Purchase
  • CI Stage Adoption
  • GitLab Secure Adoption

Existing Professional Services That May Help

Preparation Materials

​ Preparation materials (GitLab Team Members Only)

Outline: Terrain Mapping for Implementing GitLab Secure

  1. Terrain Mapping for Implementing GitLab Secure

  2. Teams and Users

  3. Development Build & Test Workflows (Development Remediation)

    1. Code Integrity
    2. Code Quality
    3. Security Scanning
    4. Security Findings Practices
    5. Merge Approvals
    6. Issue Creation

  4. Sprint Planned Remediation

    1. Creation of Issues

  5. Defend Workflows

    1. Kubernetes
    2. Scheduled Scanning / DAST

  6. Security Audits

  7. Licenses Audits

  8. Timeline

Terrain Mapping for Customer Internal Developer Enablement for GitLab CI

Status: Ready

Common Customer Challenge

​ Helping customers understand and configure parts of GitLab that create internal enablement for their Development Teams

Customer Applicability Cues

  • You Are Talking to an Enablement Team Cue: “We generally make templates for the other developers.”, “Our team is responsible for all organization-wide shared development tooling”, “Our new effort will be providing many more shared and structured services for all developers.”
  • Velocity Cue: “We want all developers to be leveraging GitLab Secure features within two quarters of purchasing it.”
  • Complexity Cue: “We need our existing strongly opinionated Development / DevOps workflows to be setup in a way that developers can easily understand how to do in GitLab.”
  • Experienced with Consuming Professional Services Cue: “Can your professional services area work with us to define and build a working example project that leverages all of the GitLab Secure capabilities we need?”

Customers Transitions That Indicate a Potential Need For This

  • Initial Purchase
  • CI Stage Adoption

Existing Professional Services That May Help

Preparation Materials

​ Preparation materials (GitLab Team Members Only)

Outline: Terrain Mapping for Customer Internal Developer Enablement for GitLab CI

  1. Teams and Users

  2. Existing Pipeline Code Analysis

  3. Existing Pipeline 3rd Party Integrations

  4. Developer Enablement (templating for rapid onboarding)

  5. Shifting Security Left

  6. CI / CD Scaling Requirements

  7. New Integrations and Webhooks

  8. What Specific Existing Pipeline Features Should be Templatized

  9. Tool Retirements / Consolidation

  10. What Deployment Environments Need to Be Supported

  11. Timeline

Terrain Mapping For Specialized or Highly Scaled GitLab Runner Implementation

Status: Proposed

Common Customer Challenge

​ Help customers with specialized, complex and highly scaled self managed GitLab Runner Implementation Planning including ML Ops and Data Ops

Customer Applicability Cues

  • Volume Cue: “Every team will have a runner in each of their 3 cloud accounts - it seems like a lot to manage the initial deployments and long term maintenance.”
    • “We will be pushing ML Ops data sets for our AI project that will requires massive elastic scaling.”
  • Velocity Cue: “We need a runner per team operational on the launch of GitLab.”
  • Complexity Cue: “Our production environment cloud account is zero touch - how can GitLab runners be setup to deploy into that cloud account?”
  • Experienced with Consuming Professional Services Cue: “Can we have professional services help us design an approach to self-managed runners that will work for us?”

Customers Transitions That Indicate a Potential Need For This

  • Initial Purchase
  • CI Stage Adoption
  • ML Ops or Data Ops

Existing Professional Services That May Help

Preparation Materials

​ Preparation materials (GitLab Team Members Only)

Outline: Terrain Mapping For Specialized or Highly Scaled GitLab Runner Implementation

  1. Teams and Users
  2. Existing Pipeline Code Analysis
  3. Existing Pipeline 3rd Party Integrations
  4. Developer Enablement (templating for rapid onboarding)
  5. Shifting Security Left
  6. CI / CD Scaling Requirements
  7. ML Ops / Data Ops
  8. New Integrations and Webhooks
  9. What Specific Existing Pipeline Features Should be Templatized
  10. Tool Retirements / Consolidation
  11. What Deployment Environments Need to Be Supported
  12. Timeline

Terrain Mapping for Integrating GitLab with Other Systems

Status: Proposed

Common Customer Challenge

​ Wiring Up the Platform to Existing Systems (Integration)

Customer Applicability Cues

  • Volume Cue: “We rely/depend on too many other services as a part of our workflow that we can’t replace at this at this time (Slack, Jira, Jenkins, etc) "
  • Velocity Cue: “We need these integrations day one before we can start using GitLab”
  • Complexity Cue: " Connecting all the integrations required is going to impact developer productivity and we can’t affect our customer value/product delivery”
  • Experienced with Consuming Professional Services Cue: “Do you provide any services that could help us tie in these required components?”

Customers Transitions That Indicate a Potential Need For This

  • Initial Purchase
  • Broadening GitLab Usage To Enterprise Wide

Existing Professional Services That May Help

Preparation Materials

​ None yet

Outline: None Yet

Last modified October 18, 2024: Add heading markdownlint rule (eadd8ce9)
View page source - Edit this page - please contribute. Creative Commons License