GitHub

Challenge

Shopify faced a critical inflection point as it scaled beyond 3,000 developers working across a massive Ruby on Rails monolith and an expanding ecosystem of microservices. The existing development workflow relied on fragmented tooling with inconsistent code review practices, making cross-team collaboration extremely difficult. Teams operated in silos, with limited visibility into what other groups were building. This led to widespread code duplication, where multiple teams independently built similar solutions to the same problems. The lack of a unified platform meant that onboarding new developers took weeks, as they had to learn multiple tools and workflows. Knowledge sharing was ad hoc, happening through Slack messages and tribal knowledge rather than structured processes. The company needed a way to break down organizational barriers and enable any developer to contribute to any codebase while maintaining quality standards and security controls across hundreds of active repositories.

Solution

Shopify adopted GitHub Enterprise Cloud as its unified development platform and built a comprehensive InnerSource program on top of it. The migration involved consolidating repositories from multiple source control systems into GitHub, standardizing branch protection rules, and establishing organization-wide templates for pull requests and issues. They implemented a tiered InnerSource model: Tier 1 repositories were fully open for contributions from any developer, Tier 2 required team approval but welcomed external pull requests, and Tier 3 remained restricted to specific teams for security-sensitive code. GitHub Actions became the backbone of their CI/CD pipeline, running over 50,000 workflow executions daily across the organization. They leveraged CODEOWNERS files extensively to ensure the right reviewers were automatically assigned, reducing review bottlenecks. Custom GitHub Apps were developed to automate contributor license agreements, enforce coding standards, and track InnerSource metrics. The team also built an internal developer portal that surfaced GitHub repository health metrics, documentation completeness scores, and contribution activity dashboards, making it easy for developers to discover and contribute to projects across the organization.

Outcome

40% reduction in duplicate code across the organization, developer onboarding time cut from 3 weeks to 5 days, 60% increase in cross-team contributions within the first year

Scale

3,000+ developers, 2,500+ repositories, 50,000+ CI workflow runs per day, 15,000+ pull requests merged monthly

Key Learnings

• InnerSource requires executive sponsorship and dedicated community managers to sustain momentum beyond initial adoption
• CODEOWNERS files and automated review assignment are essential for scaling code review without creating bottlenecks
• Measuring and publicly sharing InnerSource contribution metrics drives organic adoption across engineering teams

Challenge

Mercedes-Benz was undergoing a fundamental transformation from a traditional automaker to a software-defined vehicle company. The engineering organization needed to manage software for next-generation vehicles that contained over 100 million lines of code across embedded systems, infotainment platforms, autonomous driving modules, and connected car services. Development teams were distributed across Germany, the United States, India, and China, operating on different toolchains with varying compliance requirements. The existing development infrastructure relied on legacy version control systems that could not handle the scale of binary assets, hardware description files, and embedded firmware alongside traditional application code. Regulatory requirements from automotive safety standards like ISO 26262 demanded complete traceability from requirements to code changes to test results, which was nearly impossible to achieve with their fragmented tooling landscape. Collaboration between hardware and software teams was particularly challenging, as they operated on different release cycles and used incompatible development workflows.

Solution

Mercedes-Benz deployed GitHub Enterprise Server across its global development centers, creating a unified platform for over 5,000 software engineers. The implementation was carefully designed to meet automotive industry compliance requirements, with GitHub Enterprise Server instances hosted in Mercedes-Benz's own data centers in Stuttgart and Atlanta to satisfy data residency requirements. They developed a custom integration layer between GitHub and their existing automotive toolchain, including connections to IBM DOORS for requirements traceability, Vector CANoe for hardware-in-the-loop testing, and their proprietary vehicle simulation platform. GitHub Actions runners were deployed on dedicated bare-metal servers to handle the computational demands of compiling embedded firmware and running automotive simulation test suites. The team implemented a sophisticated branching strategy that aligned with the automotive V-model development process, where feature branches mapped to specific ECU software versions and release branches corresponded to vehicle production milestones. Pull request templates were customized to include mandatory fields for safety impact assessment, affected ECU modules, and links to requirements in DOORS. They also built a compliance dashboard using the GitHub API that automatically generated audit reports showing the complete chain from requirement to merged code to test execution for ISO 26262 certification.

Outcome

Software integration cycle reduced from 6 weeks to 2 weeks, 70% reduction in audit preparation time for ISO 26262 compliance, cross-site collaboration increased by 3x

Scale

5,000+ developers across 4 countries, 1,800+ repositories, 100M+ lines of vehicle software code, 200+ CI/CD pipelines for different ECU targets

Key Learnings

• Automotive compliance requirements like ISO 26262 traceability can be effectively addressed through GitHub API integrations with existing requirements management tools
• Self-hosted GitHub Enterprise Server is essential for automotive companies with strict data residency and air-gapped network requirements
• Bridging hardware and software development workflows requires custom branching strategies that map to physical production milestones

Challenge

Stripe operates one of the world's most critical payment processing infrastructures, handling billions of dollars in transactions annually. Their API-first architecture demanded an exceptionally rigorous CI/CD pipeline that could validate every change against strict backward compatibility requirements, security standards, and regulatory compliance mandates including PCI DSS Level 1. The engineering team faced the challenge of maintaining API stability across hundreds of API versions while shipping new features multiple times per day. Every code change to the payment processing pipeline required exhaustive testing against real-world transaction patterns, fraud detection models, and integration scenarios with thousands of merchant configurations. The existing CI infrastructure struggled with test execution times that exceeded 45 minutes for the full suite, creating a bottleneck that slowed developer velocity. Additionally, the security team required cryptographic verification of every artifact deployed to production, with a complete audit trail from commit to deployment that could withstand regulatory examination.

Solution

Stripe built a sophisticated CI/CD platform on GitHub Actions that incorporated their unique requirements for API versioning, security, and compliance. The pipeline architecture used a multi-stage approach: the first stage ran fast unit tests and API compatibility checks within minutes, providing immediate feedback to developers. The second stage executed integration tests against a sandboxed payment processing environment that simulated real merchant configurations and transaction flows. The third stage performed security scanning, including static analysis for common vulnerability patterns in payment code, secrets detection, and cryptographic signing of build artifacts. They developed custom GitHub Actions that automated API version compatibility testing by replaying recorded production API calls against the new code to detect breaking changes. Reusable workflow templates were created for different service types including API gateways, background workers, and data pipeline services, ensuring consistent CI/CD practices across the organization. GitHub Actions environments were configured with required reviewers for production deployments, creating a human-in-the-loop approval gate. They implemented a canary deployment workflow that automatically promoted changes through staging, canary at 1% traffic, canary at 10% traffic, and full production rollout, with automated rollback triggers based on error rate thresholds monitored through their observability stack.

Outcome

CI feedback time reduced from 45 minutes to 12 minutes for primary test suite, deployment frequency increased by 3x, zero PCI DSS audit findings related to deployment pipeline controls

Scale

1,500+ engineers, 3,000+ repositories, 100,000+ CI workflow runs per week, 50+ deployments to production per day

Key Learnings

• API backward compatibility testing must be automated as a CI gate using recorded production traffic patterns to catch breaking changes before merge
• Multi-stage CI pipelines with fast-fail stages significantly improve developer productivity by providing quick feedback on common issues
• GitHub Actions environments with required reviewers provide an effective human-in-the-loop approval mechanism for regulated deployment workflows

Challenge

Spotify's engineering organization operated one of the largest microservices architectures in the industry, with hundreds of autonomous squads each owning and deploying independent services. This decentralized model, while enabling rapid innovation, created significant challenges in repository management, dependency tracking, and engineering standards enforcement. With over 1,600 active repositories containing microservices written in Java, Python, Go, and TypeScript, the platform engineering team struggled to maintain visibility into the health and compliance status of the overall system. Dependency vulnerabilities could lurk unpatched in repositories that hadn't been actively maintained, creating security risks across the interconnected service mesh. There was no standardized way for squads to discover existing services or libraries, leading to significant duplication of effort. The lack of consistent CI/CD configurations across repositories meant that deployment practices varied wildly between squads, from fully automated canary deployments to manual SSH-based releases, creating operational risk and making incident response difficult.

Solution

Spotify built their internal developer platform, Backstage, with deep GitHub integration to manage their microservices ecosystem at scale. The platform treated GitHub repositories as the source of truth for service ownership, documentation, and operational metadata through standardized catalog-info.yaml files checked into every repository. They developed a GitHub App called ServiceBot that automatically enforced organizational standards by scanning repositories for required files including CI configurations, Dockerfiles, ownership declarations, and runbook links. Repositories that fell below compliance thresholds were automatically flagged in Backstage dashboards and their owning squads received notifications. GitHub Actions became the standardized CI/CD platform, replacing a patchwork of Jenkins instances, custom scripts, and manual processes. The platform team published a library of reusable GitHub Actions workflows as organization-level workflow templates, covering common patterns like Java service builds, Python library publishing, Docker image scanning, and Kubernetes deployments. Dependabot was configured organization-wide with custom grouping rules that batched related dependency updates together, reducing the pull request noise that had previously caused squads to ignore security updates. They also implemented a sophisticated repository creation workflow through Backstage software templates that generated new repositories with all required configurations pre-applied, ensuring compliance from day one rather than retrofitting standards after the fact.

Outcome

95% of repositories achieved compliance with organizational standards within 6 months, dependency vulnerability remediation time reduced from 30 days to 5 days average, new service creation time reduced from 2 days to 30 minutes

Scale

1,600+ microservice repositories, 2,000+ engineers across 400+ squads, 800+ Backstage software components, 25,000+ GitHub Actions workflow runs per day

Key Learnings

• Treating GitHub repositories as the source of truth for service metadata via catalog files enables powerful developer platform integrations
• Organization-level reusable GitHub Actions workflows are critical for maintaining CI/CD consistency across hundreds of autonomous teams
• Automated compliance scanning with clear remediation paths is more effective than manual enforcement of engineering standards

Challenge

NASA's Jet Propulsion Laboratory develops some of the most sophisticated software in existence, powering Mars rovers, deep space probes, and Earth observation satellites. Historically, this software was developed behind closed doors with restricted access, limiting collaboration with the broader scientific and engineering community. JPL recognized that open-sourcing their software could accelerate innovation, improve code quality through external review, and enable academic researchers and other space agencies to build upon their work. However, releasing government-funded software as open source presented unique challenges around export control regulations (ITAR and EAR), intellectual property management, and ensuring that sensitive mission-critical systems were properly separated from publicly releasable code. The existing internal development workflows were built around legacy tools and processes designed for classified or restricted environments, making the transition to a public-facing platform culturally and technically challenging. Additionally, JPL needed to maintain the ability to accept external contributions while ensuring that contributed code met the rigorous quality and safety standards required for flight software.

Solution

NASA JPL established a comprehensive open source program office that used GitHub as its primary platform for publishing and collaborating on space software projects. The program created a structured review and release process where internal projects could be evaluated for open source eligibility, checked against export control regulations, and published to GitHub with appropriate licensing. They deployed a dual-repository strategy where mission-critical flight software continued to be developed on internal systems, while derived tools, libraries, simulation frameworks, and data processing pipelines were published on GitHub under the nasa and NASA-JPL organizations. The open source program published over 100 repositories covering projects like F Prime, a flight software framework used on Mars Helicopter Ingenuity; SPICE, the spacecraft navigation toolkit; and various data processing tools for Earth science missions. GitHub Issues and Discussions became the primary channels for community engagement, allowing external researchers to report bugs, request features, and propose enhancements. Pull request workflows were configured with required reviews from JPL engineers who held appropriate clearances and technical expertise. The team implemented comprehensive CI pipelines using GitHub Actions that ran automated tests, static analysis, and code quality checks on every contribution, ensuring that external code met JPL's coding standards before review. They also used GitHub Pages to host documentation for each project, making it easier for the community to adopt and contribute to JPL's tools.

Outcome

F Prime framework adopted by 10+ university CubeSat missions, 300% increase in external bug reports leading to improved software quality, significant reduction in duplicated effort across NASA centers

Scale

100+ open source repositories, 400+ contributors from external organizations, 15,000+ GitHub stars across projects, used by 50+ space agencies and research institutions worldwide

Key Learnings

• A structured open source review process that includes export control and IP evaluation is essential for government research organizations releasing code publicly
• Dual-repository strategies effectively separate mission-critical code from publicly releasable components while enabling community collaboration
• GitHub Actions CI pipelines for open source projects must enforce the same quality standards as internal development to maintain trust in external contributions

Challenge

Capital One, one of the largest banks in the United States, faced the complex challenge of modernizing its software development practices while operating under some of the most stringent regulatory frameworks in any industry. Federal banking regulations from the OCC, FDIC, and Federal Reserve required comprehensive audit trails for every code change, strict separation of duties between developers and deployers, and evidence of security controls at every stage of the software delivery lifecycle. The bank's previous development infrastructure involved a patchwork of tools that made it difficult to produce the consolidated compliance evidence required during regulatory examinations. Auditors needed to verify that no single individual could both write and deploy code to production, that all changes were peer-reviewed, that security scanning was performed before deployment, and that there was an immutable record of who changed what and when. Manual compliance processes consumed thousands of engineering hours annually, with teams spending more time documenting their work for auditors than actually building software. The challenge was amplified by Capital One's cloud-first strategy, which added cloud security controls to the existing regulatory compliance requirements.

Solution

Capital One implemented GitHub Enterprise Cloud as the foundation of their secure software delivery platform, integrating it deeply with their compliance and governance framework. The implementation centered on using GitHub's native features to enforce regulatory controls as automated guardrails rather than manual checkpoints. Branch protection rules were configured to enforce separation of duties: developers could create pull requests but required approval from designated reviewers who were not the code author, and deployment workflows required approval from operations team members who had no commit access to the repository. GitHub's audit log API was integrated with their SIEM platform, Splunk, to create a real-time compliance monitoring system that tracked every authentication event, permission change, repository access, and code review action. They developed a suite of required status checks using GitHub Actions that automatically ran security scanning tools including Checkmarx for SAST, Black Duck for software composition analysis, and custom policy checks for cloud infrastructure code using Open Policy Agent. Pull request templates included mandatory fields for change risk assessment, rollback procedures, and links to approved change tickets in ServiceNow. The team built a compliance-as-code framework where regulatory requirements were encoded as GitHub Actions workflows that could be version-controlled, tested, and audited just like application code. This framework generated machine-readable compliance evidence that could be automatically assembled into audit packages, dramatically reducing the manual effort required for regulatory examinations.

Outcome

Audit preparation time reduced by 75%, achieving continuous compliance evidence generation instead of quarterly manual documentation, 50% faster remediation of security findings, regulatory examination findings decreased by 60%

Scale

11,000+ engineers, 5,000+ repositories, 85,000+ pull requests per month, 200+ regulatory compliance checks automated as CI/CD gates

Key Learnings

• Encoding regulatory requirements as GitHub Actions workflows creates auditable, version-controlled compliance evidence that satisfies examiner expectations
• GitHub branch protection rules combined with CODEOWNERS effectively enforce separation of duties required by banking regulations without manual oversight
• Integrating GitHub audit logs with SIEM platforms enables real-time compliance monitoring instead of periodic manual reviews