Technology
›
Enterprise Software & IT
›
IT Service Management
DevOps Tools & Pipelines
Platform decisions with deep integration complexity, organizational change, and long-term data stakes.
Example organizations in this space:
GitHub
GitLab
Jenkins
CircleCI
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Pre-Sales
Qualify and diagnose before investing in a full evaluation cycle.
-
Qualification
Confirm budget, decision process, timeline, and compliance gating before committing to full enterprise discovery.
Qualification Questions
Migration and operational scale
- Roughly how many repositories do you plan to migrate to the platform in year one?
- What is your expected peak concurrent pipeline runs or jobs during your busiest hours?
Security, compliance, and integrations
- Which pipeline security capabilities must run before merge or deploy?
- Will your organization require formal compliance controls or agreements (for example PHI/HIPAA, PCI, FedRAMP, or data residency)?
- Do you need SSO, SAML/SCIM provisioning, and audit-log integration confirmed before production rollout?
Budget
- Is there an allocated budget for enterprise licensing or professional services for this rollout?
- If you can, please state an approximate budget range or procurement constraint for this engagement.
Decision authority and timeline
- Who signs the final agreement and who are the core technical and security approvers we should include in discovery?
- What is your target decision timeframe and desired rollout window?
-
Enterprise Discovery
Map stakeholders, current CI/CD toolchain constraints, migration scope, security requirements, and measurable success criteria across the buying group.
Discovery Questions
How your adoption began
- Tell me about the repository or microservice that led your team to try the platform, how it started and who first adopted it
- How many development teams are actively using the free tier or trial today
- Which environments are those teams deploying to most often, for example feature branches, staging, or production
- When did usage grow beyond the initial team, and what triggered that spread
- Who in your organization first raised the need to standardize on a single platform
- Describe a recent incident where lacking a single dashboard or integrated pipeline led to extra work or an outage
- Is there a non-negotiable adoption threshold, for example number of teams or critical services, that would make you pause standardization
Where your CI and pipelines quietly cost you time
- If a pipeline failure prevented a release during your busiest day, what immediate cost or customer impact would you expect and who would be accountable
- Walk me through a typical pipeline run for a medium-size feature, including build, security scan, and deploy steps
- How often do pipelines exceed expected runtime or timeout, and which job types are the usual offenders
- Who owns pipeline performance, and who is responsible when a repeated slow job needs remediation
- What visibility gaps exist when tracing a change from commit to production, and which artifacts are missing to make that trace reliable
- If we could demonstrate a 50 percent reduction in build time for your slowest pipeline, what would stop you from agreeing to run a pilot this quarter
When security or compliance becomes the gatekeeper
- Imagine your security team finds a critical secret or high severity vulnerability in a release, what immediate steps must happen before the release can continue
- Which security scans run in your pipelines today, for example dependency scanning, secret detection, static analysis, or container image scanning
- How do you currently surface and prioritize scan results for development teams versus security reviewers
- When a false positive pauses a release, who can triage or bypass it and how long does that usually take
- Describe which compliance frameworks you must satisfy, such as SOC 2, ISO, HIPAA, and which pipeline artifacts are required for each
- Name the single compliance requirement that, if unmet, would stop your enterprise rollout immediately
What will migration actually look and feel like
- Assuming you needed to migrate 80 percent of active repositories in six months, what would break first
- How many repositories would you include in an initial migration wave, roughly
- Point to the repository types that host regulated workloads or customer data, and note any special handling they require
- Identify the owners for those repositories and approximately what percent are engineers versus platform or operations
- What migration pattern would you prefer, for example big-bang, phased by team, or phased by service criticality
- Would a required two week trunk merge freeze be acceptable to you, and if not what length would be workable
Where risk and blockers usually hide
- Point to the operational failure that would force you to pause onboarding new teams
- How do you currently handle access requests to production environments during a rollout, and who must sign off
- Are there procurement, licensing, or legal approvals that regularly extend your timeline by more than two weeks
- List the teams that maintain your SSO, identity providers, and audit log exports, and indicate typical enablement speed
- Do existing vendor contracts prohibit data export, installations, or integrations that would block migration
- Could a read-only integration for initial pilot purposes be acceptable, or would read-only access be a non-starter
Who else you are weighing this against
- Name the single capability or outcome your current toolchain must keep delivering for you to avoid switching
- List the alternatives you are evaluating, for example extending your current toolchain, assembling point products, or building an internal solution
- Estimate the annual headcount or dollars spent maintaining cross-tool integrations today
- Has anyone proposed solving this internally, who would lead it, and what timeline did they propose
- Are you currently piloting or negotiating with any other vendor, and what differentiator would make you sign with them
- Would a perpetual internal maintenance team be preferable to a vendor with commercial support, and why or why not
Practical readiness, integrations, and timeline
- Identify the owner who will unblock API access and provide credentials when required, and state their typical response time
- Inventory the third-party systems that must integrate, for example identity provider, artifact registries, ticketing, and monitoring
- Estimate how many engineers you can dedicate to migration and integration work in the first 90 days
- Do you have a sandbox or staging environment that mirrors production where we can run an end-to-end pilot
- Specify any data residency, encryption, or retention rules that would constrain a cloud-hosted deployment versus a self-managed installation
- How quickly do you need a pilot to demonstrate measurable value to your VP of Engineering, in weeks
- Could a single SSO configuration requiring two days to enable accelerate or block your rollout
Acceptance criteria and next steps
- Describe the measurable success criteria you would use to judge a pilot, for example build time reduction, fewer failed releases, or audit readiness
- Which single metric, if achieved in the pilot, would make you recommend moving to an enterprise agreement
- Who needs to sign off for a pilot to move to a paid enterprise rollout, and what approvals are required from each
- What timeline would you commit to for a pilot decision, and what would cause you to accelerate to a production rollout within that window
- If the pilot meets the success criteria, what is the single final blocker that would prevent you from signing an enterprise agreement that month
-
-
Solution Evaluation
Run a hands-on evaluation that validates security scanning, secret detection, scale, and migration approaches against the buyer's acceptance criteria.
- success_criteria
- current_state
- decision_readiness
- stakeholders
- gaps
- desired_state
- gaps
- success_criteria
- stakeholders
- desired_state
- current_state
- decision_readiness
- stakeholders
- decision_readiness
- current_state
- desired_state
- success_criteria
- gaps
- success_criteria
- current_state
- decision_readiness
- gaps
- desired_state
- decision_readiness
- decision_readiness
- decision_readiness
-
Solution Scope
Define modules, migration boundaries, responsibilities, compliance controls, and measurable acceptance criteria for enterprise rollout.
Scope Configuration
- Provision Source Code Repositories
- Import Existing Git Repositories with History
- Configure Code Review and Merge Requests
- Enable CI Pipelines with Parallel Builds and Caching
- Migrate Pipelines to YAML Templates
- Provision Artifact and Container Registry
- Configure Deployment Targets (Cloud and On-Prem)
- Provision Self-Managed Installation
- Activate Built-In Pipeline Security Scanning
- Enable Secret Detection in Commits
- Enforce Merge Approval Policies and Branch Protection
- Configure Role-Based Access and Project Permissions
- Activate Audit Logging and Compliance Trails
- Deploy Deployment Frequency and Lead-Time Dashboard
- Configure Issue Tracking and Project Boards
Scope Questions
Provision Source Code Repositories
- How many Git repositories must be provisioned on the platform (numeric count)?
- List the required default visibility setting for new repos (Private, Internal, Public) and provide examples of repos for each setting.
- Require repository starter files for new repos (README, CODEOWNERS, .gitignore)?
- Provide the naming convention and default branch names to enforce (for example: main, develop, release/*).
- Will you need automated issue-to-commit linking from your issue tracker into new repositories?
Import Existing Git Repositories with History
- How many existing repositories require full-history migration (numeric count)?
- Identify which repositories are monorepos and which are service-specific (provide repository names).
- Are there repositories that include Git LFS objects or repositories larger than 10 GB that need special handling?
- Describe the desired commit-author handling during migration (preserve original author emails, map to SSO accounts, or other).
- Should a snapshot or point-in-time backup of each source repository be taken and stored prior to migration?
Configure Code Review and Merge Requests
- Name the merge strategies to be allowed per project (merge commit, squash, rebase) and which repos should use each.
- Is branch protection required for branch 'main' and release branches (for example: require approval and passing CI)?
- Specify required approver counts and whether approvers must belong to particular teams or code owners.
- Will you enforce CODEOWNERS-driven reviews for specific paths (for example: /infra, /services/payment)?
- Describe the blocking conditions for merge requests (for example: failing security scan, failing unit tests) and the CI job names that must pass.
Enable CI Pipelines with Parallel Builds and Caching
- List the pipelines or services that must run parallel jobs (provide pipeline filenames such as ci.yml or service names).
- Do pipelines require dependency caching between runs (for example: pip cache, Maven local repository, npm cache)?
- Provide maximum acceptable run time per critical pipeline (for example: under 15 minutes for ci.yml on branch main).
- Select the runner model for build execution: autoscaling runners tied to cloud account, fixed on-prem runner pools, or hybrid.
- Describe cache key strategy and size limits for frequent pipelines (for example: branch-specific cache keys, 1 GB max cache per job).
Migrate Pipelines to YAML Templates
- List the top five existing pipeline jobs by run frequency that should be converted to YAML templates first (provide job names).
- Do you require centralized reusable templates stored in a templates repository that projects reference?
- What acceptance criteria will confirm a migrated pipeline template is production-ready (for example: 95% successful runs on branch main across 7 consecutive days)?
- Specify how secrets and credentials should be referenced in YAML templates (for example: secret path in secret manager or environment variables).
- Will template changes require versioned releases and an approval workflow before project adoption?
Provision Artifact and Container Registry
- List the artifact formats required (container images, Maven packages, npm packages, generic archives).
- Provide the registry endpoint hostnames that CI pipelines will push to and clients will pull from (for example: registry.example.internal).
- Require image signing or content trust for container images prior to deployment?
- Specify artifact retention rules (for example: keep last 30 images or retain artifacts 90 days).
- Will CI pipelines automatically publish artifacts on successful builds (for example: push image when pipeline stage 'build' completes)?
Configure Deployment Targets (Cloud and On-Prem)
- Provide the identifiers for deployment targets to configure (Kubernetes cluster names, cloud account IDs, on-prem cluster IDs).
- Are private network requirements needed for deployments (VPC peering, VPN, private endpoints)?
- State the rollout strategy required for production (blue‑green, canary with percentage steps, or rolling) and examples per service.
- Provide whether service account credentials or kubeconfig files can be supplied for automation and their rotation policy.
- Name the allowed deployment windows for production (for example: 02:00–04:00 UTC maintenance window) and blackout periods.
Provision Self-Managed Installation
- Identify the physical or virtual environment for the self-managed install (on‑prem VM cluster, private cloud region, or managed colocation).
- Is an air‑gapped installation required or will outbound network access to update mirrors be allowed?
- What operational acceptance criteria will validate the self-managed installation (for example: average pipeline execution latency under 30s, backup restore within 4 hours, and 99.9% availability measured over 30 days)?
- Provide the external integrations to configure on the instance (SSO SAML metadata URL, LDAP endpoint, syslog destination).
- Choose the upgrade model for the self-managed instance: we perform upgrades, you perform upgrades, or we deliver runbooks and training.
Activate Built-In Pipeline Security Scanning
- List required scan types to enable in pipelines (dependency vulnerability scanning, static application security testing, container image scanning).
- Indicate the compliance standards scans must provide evidence for (SOC 2, ISO 27001, PCI DSS) and any severity thresholds for failure.
- What evidence will validate that pipeline security scanning meets your acceptance criteria (for example: zero Critical/High vulnerabilities on production images and secret detection false-positive rate below 0.1% across 30 days)?
- Should merges be blocked when scans surface vulnerabilities above a defined severity level (for example: block on Critical or High)?
- Provide the ticketing workflow for scan results (create ticket in your tracker with fields: repo, commit SHA, severity, remediation owner).
Enable Secret Detection in Commits
- List the secret types and patterns to detect (AWS access keys, Azure keys, private SSH keys, regex patterns).
- Will you require automatic remediation on detection (for example: auto-revoke key and open an incident ticket)?
- Provide the triage and notification path for detected secrets (security team email alias, Slack channel, or PagerDuty).
- Allow repository-level suppression rules for known false positives or legacy files (Yes/No)?
- Specify how long secret exposure incidents should remain in the audit trail (30, 90, 365 days, or custom).
Enforce Merge Approval Policies and Branch Protection
- Provide the exact branches that need protection and the rules per branch (for example: main requires 2 approvers and passing CI).
- Are signed commits or GPG verification required for merges into protected branches?
- Specify if approvers must come from specific teams or have certain roles for each protected branch.
- Should linear history be enforced on main via rebase-only merges?
- List the mandatory status checks (CI job names) that must pass before merges are allowed on protected branches.
Configure Role-Based Access and Project Permissions
- Provide the number and names of distinct roles required at organization and project level (for example: Developer, Maintainer, Release Manager).
- Do you require auditing and approval workflows for permission changes (record approver and timestamp)?
- Specify the mapping between IdP groups and platform teams (provide example group names from your SSO).
- Will developers need time-limited elevated access for troubleshooting (just-in-time escalation)?
- List project-level actions that should be restricted to admins (for example: manage runners, change billing, change integrations).
-
Mutual Commit
Finalize commercial terms, SLAs, licensing model, data protection requirements, and operational responsibilities.
Agreement Modules
- Subscription Agreement
- Order Form
- Service Level Agreement (SLA)
- Data Processing Agreement (DPA)
- Security and Incident Response Addendum
- Support and Operational Responsibilities Addendum
- License Usage Schedule
- Data Residency and Export Addendum
- Termination, Exit and Transfer Plan
-
Deployment
Lock readiness facts and configuration values before execution begins.
-
Pre-Deployment Readiness
Capture concrete readiness facts — owners, target environments, access requirements, and go-live windows — the deployment needs confirmed before execution.
Pre-Deployment Questions
Environment and site access
- Which target environments will receive the initial deployment? (select all that apply; answers set the deployment sequence)
- Is the production environment provisioned and accessible to the deployment team? (this determines whether we schedule cutover or allocate provisioning tasks)
- Will the rollout touch on-premises or air-gapped environments that require on-site execution, special network routes, or dedicated agents? (so we can plan travel, network changes, or agent placement)
Data and configuration
- Will repository, artifact, or pipeline-template migration be required before cutover? (select the scope so we can size migration tasks)
- If migration or mapping is required, who is the migration owner responsible for coordinating migrations and verifying integrity? (name and role)
- Who owns the pipeline templates and configuration that will be locked for deployment? (name and role — this person approves the final config lock)
People and ownership
- Who is the named deployment owner responsible for go/no‑go decisions and post-cutover validation, and who is their backup? (name and role)
- Which organizational teams must provide final sign-off before go-live? (select all that apply)
Timing and constraints
- What is the desired go-live window or target date (week of / date range)? If flexible, indicate earliest and latest acceptable dates. (so we can sequence tasks and resource allocation)
- Are there blackout windows, regulatory freezes, or sprint milestones in the next 90 days that prohibit deployment?
- If yes to blackout windows, list the blackout dates/times and time zone here. If none, enter 'None'. (we will avoid scheduling work during these windows)
- List any external dependencies that must be completed before deployment (examples: SSO enablement, firewall rules, artifact registry access). For each dependency provide the owner and expected completion date. (answers feed directly into the critical-path plan)
-
Configuration Details
Lock exact configuration values the deployment team will use — integration credentials, pipeline YAML parameters, repository mappings, and registry endpoints.
Configuration Details
ENVIRONMENTS & ENDPOINTS
- Primary deployment environment name (single token used in pipeline YAML and environment labels — Default: production)
- Platform runner/controller URL to target for deployments (enter full HTTPS URL; format: https://runner.example.com). This value is consumed by the deployment step that registers and targets runners.
- Container registry endpoint for production images (enter host or full URL; examples: registry.example.com or https://registry.example.com). Default: registry.example.com — used by image push/pull steps.
EXECUTION & FEATURES
- Build execution region/zone (enter exact region/zone code the deployment should schedule runners in — Default: us-east-1; example codes: us-east-1, eu-central-1)
- Concurrent pipeline runners limit per organization (integer). Default is 10 — the deployment will configure autoscaling/quotas to enforce this limit.
- Enable built-in security scanning in CI pipelines? (enables vulnerability scanning, static analysis, and secret detection stages used during pipeline execution)
- Secrets storage option for pipeline runtime (select one — the deployment will configure connectors for the chosen option)
- Enter the non-secret identifier/name of the external secrets manager to use (only if you selected 'External secrets manager' above). Example formats: vault-prod-cluster, keyring-teamA. DO NOT paste secrets or tokens here — this is an identifier only.
MAPPINGS & AUTH POLICIES
- Repository mapping manifest path in source control (path the deployment will read to map repositories to pipeline templates — Default: .ci/repo-mapping.yaml)
- Source control read-only auth method for mapping imports (select one — deployment will expect the corresponding non-secret identifier next)
- Enter the non-secret identifier for the selected source control auth method (e.g., deploy-key filename, OAuth client ID, or service account name). DO NOT paste secrets, tokens, or private keys.
-
Deployment
Execute rollout with sequenced tasks, owners, rollback strategy, verification checkpoints, and stakeholder communications.
-
-
Success
Validate outcomes against success criteria, capture learnings, and maintain a shared channel for issues and enhancement requests.
Success Reviews
- Go-live Health Check (weeks 1-4)
- First Measurement Review (weeks 4-10)
- Acceptance Gate — Outcome Ratification (around day 90)
- 30-Day Post-Acceptance Remediation Review
- Quarterly Success Review (ongoing)
Issues & Enhancements
- Close remediation tasks with evidence or update them with revised timelines and owners.
- Publish the formal acceptance record with pass/fail status per criterion and the captured named signatory.
- Open remediation tasks for failed criteria with milestones and final verification dates.
- Document the incumbent decommissioning decision, archive/migration evidence, and any contract termination actions required.
- Status of remediation items
- All remediation items from the acceptance gate are either closed with evidence or have revised, owner-committed timelines.
- Pipeline failure rate and weekly active teams are documented and show progress consistent with the agreed remediation outcomes, or a corrective plan is in place.
- Operational runbooks and escalation paths are confirmed and accessible to the operations team.
- Re-confirm success criteria and owners
- Publish updated metric trend report for pipeline failure rate and weekly active teams and circulate to stakeholders.
- Ensure the shared issue and enhancement channel has an initial triage workflow and documented SLAs.
- Outcomes dashboard review
- Confirm whether deployment frequency and mean time to recovery are meeting the pace expected against the Solution Scope targets or document required corrective work.
- Agree a short list of persistent issues to address this quarter with owners and target resolution dates.
- Ensure the enhancement request channel is producing a prioritized backlog that will be re-evaluated at the next quarterly review.
- Publish the quarterly outcomes dashboard showing deployment frequency and mean time to recovery versus Solution Scope targets.
- Open corrective work items for persistent issues with owners and target completion dates.
- Maintain the enhancement backlog and circulate the prioritized list ahead of the next quarterly review.
- All Solution Scope success criteria are read back and an owner is recorded for each criterion.
- A prioritized list of immediate blockers is agreed with remediation target dates.
- Baseline telemetry collection is enabled for the metrics that will be measured at first review.
- Publish the confirmed owner list for each acceptance criterion recorded in the Solution Scope stage.
- Open remediation tasks for high-priority blockers with target completion dates.
- Enable and validate collection of telemetry required for the first measurement meeting.
- Present first-data against named metrics
- Determine whether active team count and median CI build time are trending toward Solution Scope targets, or document why not.
- Agree a concrete corrective action plan for each metric gap with target dates to bring metrics into acceptance range before the gate.
- Confirm the acceptance gate date and any dependencies needed to meet it.
- Publish the metric comparison report (active teams, median CI build time, security scan pass rate) versus the targets recorded in the Solution Scope stage.
- Create remediation tasks addressing performance and onboarding blockers with completion dates prior to acceptance gate.
- Enable additional monitoring or instrumentation where data gaps prevent clear diagnosis.
- Restate acceptance criteria and numeric targets
- Produce a documented pass/fail decision for each acceptance criterion recorded in the Solution Scope stage and capture the named signatory for enterprise acceptance.
- For any failed criteria, agree remediation actions with target dates and a final verification step.
- Confirm the incumbent system decommissioning approach and record archival/contract status.
- Metric progress check
- Persistent issues and risk review
- Present outcome data per criterion
- Diagnose root causes for gaps
- Deployment and migration validation
- Operational readiness handover
- Document formal acceptance decision
- Enhancement request triage
- Agree corrective actions and timelines
- Early adoption signals and usage patterns
- Action plan and next checkpoints
- Open issues and blockers
- Confirm readiness to proceed to acceptance gate
- Open issues and enhancement request channel review
- Remediation plan for failed criteria
- Agree immediate remediation actions
- Incumbent system wind-down confirmation