GitHub has spruced its GitHub for mobile platform with new features that it hopes will make code review easier and faster for developers.

The improvements include an overhaul of the code review experience, including the ability to toggle line wrapping on and off – this something that the community demanded.

Another improvement relates to the way code commits appear to others. Users can change an email associate with every merge, and they can also edit the commit description.

Finally, GitHub for mobile also features the ability to comment on multiple lines of code by long pressing to enable multi-select. GitHub says this makes it easier to explain how a suggestion fits in context.

A new ‘Jump To’ icon also helps to navigate reviews that span multiple files.

GitHub says these developments reflect the fact that more developers are turning to mobile apps to get their coding done.

GitHub for mobile was launched in March. Statistics show that developers have made almost 700,000 code reviews and more than 350,000 merges through the platform.

GitHub for mobile is available on the App Store and Google Cloud for individuals, Team, and Enterprise Cloud users.

GitHub is also one of three companies who have helped to teach digital skills to more than 10 million people worldwide.

Alongside Microsoft and LinkedIn, GitHub joined the digital skills initiative when it launched in June 2020.

The initiative has three aims:

(1) The use of data to identify in-demand jobs and the skills needed to fill them;
(2) Free access to learning paths and content to help people develop the skills these positions require;
(3) Low-cost certifications and free job-seeking tools to help people who develop these skills pursue new jobs.

Since then, more than 1.5 million people in Asia Pacific alone have engaged with the initiative.

Microsoft New Zealand’s national technology officer Russell Craig says, “COVID-19 has accelerated the need for upskilling and transformed the future of work for communities in New Zealand.”

“Addressing and closing the skills gap is an urgent task, key to inclusive economic recovery and digital transformation. While we are close to the halfway point of our goal to help 25 million people globally, we continue to strive in our commitment to drive societal progress and help improves lives of people in New Zealand by advancing their capabilities and expertise.”

Background: Microsoft Acquires LinkedIn

Microsoft acquired LinkedIn for approximately $26.2 billion in 2016 — one of the largest technology acquisitions in history at the time. In the years that followed, LinkedIn continued to operate with a significant degree of independence, maintaining its own engineering culture, data center infrastructure, and open-source initiatives. That arrangement eventually gave way to a major strategic shift: a full migration of LinkedIn’s workloads to Microsoft Azure.

The Decision to Move to Azure

LinkedIn’s senior VP of engineering, Mohak Shroff, announced the migration in a blog post, framing it as a response to the platform’s continued growth rather than a directive from Microsoft’s parent organization.

“Today’s technology landscape makes the need for constant reinvention paramount, especially as we look to scale our infrastructure to drive the next stage of LinkedIn’s growth. With the incredible member and business growth we’re seeing, we’ve decided to begin a multi-year migration of all LinkedIn workloads to the public cloud.”

Mohak Shroff, Senior VP of Engineering, LinkedIn

That public cloud is Azure. Shroff noted that LinkedIn had already been selectively using Azure before the full migration announcement, applying it to specific use cases such as accelerating video post-delivery, improving machine translation in the Feed, and detecting and removing inappropriate content.

On why Azure was the right choice, Shroff said: “Moving to Azure will give us access to a wide array of hardware and software innovations, and unprecedented global scale. This will position us to focus on areas where we can deliver unique value to our members and customers.”

What Happens to LinkedIn’s Data Centers?

At the time of the announcement, LinkedIn operated a corporate-owned data center in California and four leased colocation facilities in Texas, Virginia, Oregon, and Singapore. Shroff acknowledged in an interview with VentureBeat that the fate of those facilities was not yet determined:

“The exact end state for those data centers is unclear. In some cases, we will vacate them. In some cases, we may find new uses for those data centers. All of our activities that currently happen in our own native data centers will migrate into the Azure public cloud.”

Mohak Shroff, VentureBeat interview

Shroff also pushed back on the notion that the Azure migration was predetermined by the Microsoft acquisition, stating that LinkedIn’s engineering teams retained decision-making independence throughout the integration period and that the move to Azure was ultimately their own choice.

However, it is worth noting that Microsoft’s original investor slides from the 2016 acquisition did explicitly highlight that LinkedIn would benefit from “access to Microsoft’s scaled cloud infrastructure and technology stack” — suggesting the Azure migration was at least anticipated, even if not formally mandated.

LinkedIn’s Open Hardware Legacy: The Open19 Foundation

One of the more significant open questions raised by the Azure migration concerns LinkedIn’s long-standing investment in open hardware standards — particularly through the Open19 Foundation, which LinkedIn co-founded in 2016.

Open19 was created to accelerate innovation and standardization around the 19-inch server rack form factor, a specification that is ubiquitous in enterprise and colocation environments. LinkedIn was consistently the Foundation’s most active contributor and advocate.

Open19 vs. Open Compute Project (OCP)

Open19 is distinct from the Open Compute Project (OCP), which was originally backed by Facebook and initially focused on a less common 21-inch rack specification. Over time, the two groups moved closer together:

• In 2018, LinkedIn became a Platinum member of OCP.
• In 2019, LinkedIn announced that its Open19 technology specifications would be contributed to OCP.
• Despite the closer relationship, the Open19 Foundation remained legally and operationally independent from OCP.

LinkedIn’s head of infrastructure engineering, Zaid Ali Kahn, described the OCP contribution as an opportunity to share engineering learnings and find convergence opportunities between the two communities.

Open19’s Edge Push and Broader Adoption

Around the same time as the Azure migration announcement, Open19 was actively expanding its scope to include edge computing deployments. Yuval Bachar, Open19 Foundation president and LinkedIn’s principal engineer of global data center infrastructure architecture, indicated at the Foundation’s May 2019 summit that two major data center operators were evaluating Open19 technology — a significant milestone for the initiative.

Whether Azure would adopt Open19 hardware at scale remained an open question. Microsoft is not a member of the Open19 Foundation, though it has been a Platinum member of OCP since 2014.

Microsoft’s Own Open Hardware Contributions: Project Olympus

Microsoft has a substantial history with open hardware through OCP. In 2016, the company disclosed that approximately 90 percent of servers it procured were based on OCP-contributed specifications. That same year, at a Data Center Dynamics event in London, Microsoft unveiled Project Olympus — a hyperscale server hardware blueprint developed in collaboration with the OCP community.

Project Olympus was notable for being released at an earlier-than-usual design stage, allowing the open source community to participate in shaping the hardware before it was finalized. The project was later contributed to the Open19 initiative as well, with LinkedIn’s Kahn noting: “The combination of Open19 and Project Olympus allows data centers of any scale to enjoy high efficiency and advanced open standards with their existing EIA19 racks.”

Key Takeaways for DevOps and Infrastructure Engineers

• Large-scale migrations take years: Even a well-resourced organization like LinkedIn committed to a multi-year timeline, reflecting the complexity of migrating custom-built, on-premises infrastructure to public cloud.
• Hybrid use before full migration: LinkedIn used Azure selectively for specific high-value workloads before committing to a full migration — a practical pattern for de-risking large cloud transitions.
• Open hardware contributions don’t automatically follow ownership: LinkedIn’s significant investment in Open19 does not guarantee that Azure will adopt those same hardware standards at scale, highlighting the risk of tying organizational open-source contributions to infrastructure decisions.
• Acquisition goals and operational independence can coexist — up to a point: LinkedIn maintained engineering autonomy for several years post-acquisition, but eventually aligned its infrastructure strategy with its parent company’s cloud platform.

The traditional industries are going through digital transformation and job roles have evolved to the extent that as many as 62% professionals feel ‘daunted’ by the rapid pace of changing skills, a LinkedIn report says.

The traditional industries are going through digital transformation and job roles have evolved to the extent that as many as 62% professionals feel ‘daunted’ by the rapid pace of changing skills, a LinkedIn report says. The skills needed to succeed are changing rapidly and demand for talent with rising skills is three-times that of the rest of the talent base, according to LinkedIn’s ‘Future of Skills 2019’ report, released on Thursday. The research was commissioned by LinkedIn and conducted by ACA Research between March 13 and April 15, 2019.

To determine the top rising skills, LinkedIn analysed skills data listed by members on its platform in the last five years and identified those skills that have experienced exponential growth. The report finds some interesting facts like top skills, Thoughts of Indian professionals on growing dependency on technology and changing job segments. Here are some highlights of the report:

1. The LinkedIn study surveyed 4,136 employees and 844 learning and development (L&D) professionals across countries like Australia, India, Japan, and Singapore, noted that 82 per cent Indian professionals feel that the skills needed to succeed are changing rapidly and 62 per cent feel daunted by the pace of change.

The following four steps provide a practical framework for that review, whether you run it once a year or once a quarter.

Step 1: Refresh Roles and Responsibilities

DevOps combines development and operations under a shared delivery goal, but the organizational reality is messier. Developers frequently absorb tasks once owned exclusively by testers or operations engineers — writing infrastructure-as-code, instrumenting observability, triaging production incidents. Managers often underestimate how disorienting these shifting responsibilities can be for individuals who were hired under a different job description.

Before introducing new tooling or processes, make sure every person on every team has a clear, current picture of what is expected of them. Concretely, that means:

• Schedule role-clarity conversations. Hold structured one-on-ones and team sessions that map current responsibilities to updated job descriptions. Surface conflicts early — for example, a developer who is now expected to own monitoring but has never configured an alerting rule.
• Document the SDLC ownership model. Create a living document (a RACI matrix or equivalent) that shows who is responsible, accountable, consulted, and informed at each stage: planning, development, testing, release, and operations.
• Align managers and individual contributors. Misaligned expectations between a team lead and their reports are a common source of friction. A shared artifact removes ambiguity.

Skipping this step and jumping straight to tooling is one of the most common reasons DevOps transformations stall. Culture and clarity come before automation.

Step 2: Shrink the Skills Gap

Expanding role definitions collide with a real-world skills shortage. Software engineers increasingly operate as full-stack contributors, yet many have minimal exposure to continuous testing, security scanning, or infrastructure provisioning. Left unaddressed, this gap creates bottlenecks: developers write code they cannot confidently test, and quality suffers.

Three practical approaches can help close the gap:

• Secure leadership buy-in. Training and mentorship programs require time and budget. Build a concise business case for senior stakeholders that connects skill investment to measurable outcomes — reduced defect escape rate, faster mean time to recovery, fewer rollbacks. Approval becomes easier when the ask is framed in delivery risk terms rather than learning-and-development terms.
• Run peer coaching and mentorship programs. Pair engineers of different experience levels on real in-flight work. A senior engineer who has written end-to-end tests for years can accelerate a junior developer’s understanding far faster than a formal course. Rotate pairs periodically so knowledge spreads across the team rather than concentrating in a few individuals.
• Adopt practices that embed quality into delivery. Acceptance test-driven development (ATDD) and behavior-driven development (BDD) are two methodologies that make expected behavior explicit before code is written. This reduces misunderstandings across developer, tester, and product personas and creates a shared vocabulary that narrows the skills gap over time.

Step 3: Improve Productivity with Better Processes

As release velocity increases, so does the risk of bottlenecks multiplying. Multiple feature teams simultaneously building, testing, and merging code can create integration chaos if ground rules are absent. The spring-cleaning moment is a good time to audit your continuous integration process end to end.

Key areas to examine:

• Identify CI pipeline bottlenecks. Map the average time each stage of the pipeline takes — build, unit test, integration test, static analysis, artifact publication. Stages that consistently exceed their budget are candidates for parallelization, caching, or pruning.
• Establish and publish coding and testing standards. Common culprits that derail a sprint include test code that blocks the CI integration step, memory leaks introduced by inadequate code review, and inconsistent branching strategies. Written standards, enforced by automated linting and code review checklists, reduce the frequency of these incidents.
• Make progress visible with shared dashboards. Every team should be able to see build health, test pass rates, deployment frequency, and change failure rate in real time. When a team is struggling, visibility allows others to offer help or adjust planning before the problem compounds. Agree on a canonical set of metrics and a single dashboard surface so everyone is looking at the same data.

Visibility and standardization are not bureaucracy — they are the foundation that lets autonomous teams move fast without stepping on each other.

Step 4: Audit and Update Your Technology Stack

People and process improvements are the highest-leverage work, but technology deserves a periodic review too. Tool sprawl, orphaned integrations, and outdated framework versions quietly erode pipeline reliability.

Review Lab and Test Environments

Test environments are the backbone of continuous integration. An environment that is flaky, frequently unavailable, or under-provisioned for the load imposed by parallel test runs will degrade the entire pipeline. Audit environment uptime and flakiness metrics. Where environments are managed manually, evaluate whether infrastructure-as-code tooling can make provisioning and teardown repeatable and fast.

Evaluate Integration Points and APIs

There is no universal DevOps toolchain. Organizations assemble pipelines from many vendors and open-source projects, and the mix changes as requirements evolve. Review which integrations are actively used and which are abandoned. Where gaps exist, consider whether a new API or webhook can connect tools that currently require manual handoffs. The goal is a coherent, automatable flow — not the maximum number of tools.

Match Testing Frameworks to Personas

Different engineering roles have different testing needs, and forcing everyone into one framework creates friction. As a practical example:

• Developers running fast unit and component tests for mobile applications may prefer lightweight, IDE-integrated frameworks such as Espresso (Android) or XCUITest (iOS).
• Test engineers responsible for end-to-end functional coverage across platforms typically need more capable frameworks such as Appium (mobile) or Selenium/WebDriver (web).

Audit whether each role has access to the frameworks that match their workflow. Unnecessary friction in the testing step is a common, invisible drain on delivery speed.

Putting It Together

A DevOps spring cleaning is not a one-time event. The most effective engineering organizations build regular retrospective cycles — at minimum annual, ideally quarterly — that revisit role clarity, skill development, process efficiency, and toolchain fitness. The four steps above provide a repeatable checklist for those sessions.

Start with people and process before reaching for new tools. Align on responsibilities, invest in skills, make work visible, then tune the technology that supports it all. Teams that run this cycle consistently are better positioned to sustain faster release cadences without accumulating the organizational and technical debt that eventually forces an unplanned, painful cleanup.

The 3×3 Release Challenge

LinkedIn operates on what it calls a 3×3 mobile release schedule: three releases per day, with a goal of never allowing code to sit uncommitted for more than three hours. At the scale LinkedIn operates, that cadence demands that every stage of the pipeline — including automated testing — runs fast, reliably, and without human bottlenecks.

For most engineering teams, continuous integration pipelines already feel stretched when pushing one release per day. Tripling that frequency requires rethinking not just deployment, but every upstream gate, particularly automated UI testing on mobile.

Where iOS UI Testing Became the Bottleneck

Automated iOS UI testing is notoriously slow. Running a full UI test suite sequentially on a single simulator can take far longer than the three-hour window LinkedIn had set for its release cycle. Off-the-shelf solutions available at the time could not adequately parallelize iOS simulator runs to fit within that window, and LinkedIn’s engineering team found themselves at a wall: without faster test execution, the 3×3 schedule simply was not achievable.

The options were limited. Compromise the release cadence, accept reduced test coverage, or build something new.

The Solution: Bluepill — An Open-Source Parallel iOS Test Runner

LinkedIn’s engineering team chose to build their own tool. Named Bluepill — a nod to The Matrix — it is an open-source iOS test runner designed to execute tests across multiple simulators in parallel. Key capabilities include:

• Parallel simulator execution: Bluepill spawns multiple iOS simulators simultaneously, distributing the test suite across them to cut overall wall-clock execution time.
• Intelligent test packing: Tests are grouped into balanced batches so that simulators finish at roughly the same time, avoiding idle resources waiting on a slow final batch.
• JUnit report output: After each run, Bluepill produces a standard JUnit XML report, making it straightforward to integrate with existing CI dashboards and reporting tools.

LinkedIn open-sourced Bluepill in January 2017. Full details are available on the LinkedIn Engineering Blog.

How Long Did It Take to Build?

LinkedIn engineer Oscar Bonilla described the development timeline directly:

“The first commit happened on Aug. 12 and we had it working on the LinkedIn Continuous Integration system by Nov. 1. From there we continued to polish the project and address a few bugs. So in total it took about 10 weeks to build Bluepill and another 10 to refine it.”

— Oscar Bonilla, LinkedIn Engineering

That is roughly five months from initial commit to a production-hardened open-source release — a reasonable timeline for a tool that reportedly saved LinkedIn thousands of developer hours.

Lessons for DevOps and Mobile Engineering Teams

The Bluepill story illustrates several principles relevant to any team dealing with CI bottlenecks at scale:

• Identify the constraint precisely. LinkedIn did not try to speed up their entire pipeline at once. They identified iOS UI testing as the specific gate blocking their release cadence and focused engineering effort there.
• Evaluate build-vs-buy honestly. Off-the-shelf tools failed to meet the requirement. Rather than forcing an inadequate tool into production, the team invested roughly ten weeks to build a fit-for-purpose solution.
• Parallelisation is often the right lever for test speed. Distributing a test suite across multiple simulators or machines is frequently more practical than trying to make individual tests faster.
• Open-sourcing internal tooling creates compounding value. By releasing Bluepill publicly, LinkedIn benefited from external contributions and bug reports while giving the broader iOS community a tool to address a common pain point.
• Standard output formats matter. JUnit XML is a lingua franca for CI test results. Tools that produce it integrate immediately with Jenkins, CircleCI, GitHub Actions, and most other CI systems without custom parsing.

Further Reading

For the full technical details of Bluepill’s architecture and configuration options, see the original announcement on the LinkedIn Engineering Blog.