Author: Aditya Kulkarni

Recently, GPT-4o Copilot is introduced for Visual Studio Code (VS Code) users. This AI model is built upon the GPT-4o mini foundation and includes extensive training from over 275,000 high-quality public repositories across more than 30 widely used programming languages. The enhanced training is expected to provide more accurate and contextually relevant code suggestions, with improved performance, boosting developer productivity and aiding the coding process.

This announcement was made through a changelog post on the GitHub blog. The GPT-4o Copilot model differentiates itself through some key enhancements. Utilizing a vast dataset of high-quality code offers more precise and contextually relevant code completions. Its architecture and training also enable faster and more efficient code suggestion generation. The model can support various development projects with training across over 30 programming languages.

To integrate GPT-4o Copilot into VS Code, users can access the Copilot menu in the VS Code title bar, select Configure Code Completions, and then choose Change Completions Model. Alternatively, users can choose the Command Palette by opening it and selecting GitHub Copilot: Change Completions Model. Once in the model selection menu, users can choose the GPT-4o Copilot model from the available options.

For Copilot Business and Enterprise users, administrators must first enable Editor preview features within the Copilot policy settings on github.com to grant users access to the new model. Meanwhile, for Copilot Free users, using this model will count toward their 2,000 free monthly completions. The model will soon be available to Copilot users in all JetBrains Integrated Development Environments (IDEs), further expanding its reach across different platforms.

In JetBrains IDEs, users can click the icon in the status bar, navigate to the settings dialog box for Languages & Frameworks > GitHub Copilot, and select the preferred model from the dropdown menu.

Covering this announcement as a part of the Tech Insights 2025 Week 9 newsletter, Johan Sanneblad, CEO & co-founder at ToeknTek, said,

GitHub Copilot is quickly catching up to Cursor IDE which is already packed with custom models. From what I can see there are just two main features missing in Copilot: Prompt caching for performance and a local model for code merging. Once it gets those two features I think I would feel equally at home in Visual Studio Code + Copilot as with Cursor. And for all you Java and C# users, this is the update you have been waiting for. We finally have a good code completion model with good support for C++, C# and Java.

GitHub Copilot was also in the news as it introduced Next Edit Suggestions, which can predict and suggest logical edits based on the context of ongoing changes in the code. It can identify potential modifications across an entire file, offering suggestions for insertions, deletions, and replacements. Developers can navigate through these suggestions using the Tab key, streamlining the editing process and potentially saving significant time

It’s important to note that switching the AI model does not affect the model used by Copilot Chat. The data collection and usage policy remains unchanged regardless of the chosen model, and the setting to enable or disable suggestions that match public code applies regardless of the chosen model.

User feedback is essential for refining and enhancing the GPT-4o Copilot model. Developers are encouraged to share their experiences to help improve the model’s performance and usability for all Copilot users.

GitHub recently announced the public preview of Linux arm64 hosted runners for GitHub Actions. Free for public repositories, this update provides developers with more efficient tools for building and testing software on Arm-based architectures.

A changelog post on GitHub Blog summarised the announcement. Arm64 runners are hosted environments that enable developers to execute workflows, eliminating the need for cross-compilation or emulation. These 4 vCPU runners, using Cobalt 100 processors, can provide up to a 40% CPU performance increase compared to the previous generation of Microsoft Azure’s Arm-based virtual machines.

The addition of arm64 runners aligns with the increasing demand for arm-based computing, driven by the energy efficiency and performance advantages of the architecture.

Native arm64 execution provides benefits such as faster build times and more reliable testing outcomes compared to emulated environments. At the time of arm64 release on GitHub Actions in June 2024, GitHub had supported Ubuntu and Windows VM images for these runners, enabling a straightforward start for users building on Arm. However, back in June, these runners were available to GitHub Team and Enterprise Cloud Plans customers only.

To use the arm64 hosted runners, include these labels in your workflow files within public repositories: ubuntu-24.04-arm and ubuntu-22.04-arm. These labels are only functional in public repositories; workflows in private repositories using these labels will fail.

Standard runners usage limits, including maximum concurrency based on your plan, apply to all runs in public repositories. Developers are advised to expect potentially longer queue times during peak hours while the arm64 runners are in public preview.

The tech community on Hacker News welcomed this development as we saw interesting discussion threads. One user highlighted how this feature could encourage a broader shift toward ARM-based cloud workflows, mentioning the cost-effectiveness of arm CPUs compared to x64.

Another thread enquired about pricing differences between arm64 and x64 instances. One HN user agartner also provided an example of how to use the native GitHub Actions arm runners to accelerate docker builds.

This capability is particularly beneficial for projects targeting arm devices, such as IoT applications, mobile platforms, and cloud-native services. GitHub has encouraged users to share their experiences and suggestions by joining the community discussion.

For further details, interested readers can visit the documentation and also view a list of VM images from GitHub partners.

Slack recently integrated automated accessibility testing into its software development lifecycle to improve user experience for individuals with disabilities.

Natalie Stormann, Software Engineer at Slack, detailed the journey in Slack’s engineering blog, communicating the company’s ongoing adherence to Web Content Accessibility Guidelines (WCAG).

Slack has internal standards and the company further collaborates with external accessibility testers as well. These standards align with WCAG, an internationally recognized benchmark for web accessibility. While manual testing remains important for identifying nuanced accessibility issues, Slack recognized the need to augment these efforts with automation.

In 2022, Slack started incorporating automated tests into its development workflow to proactively address accessibility violations. The company chose Axe, a widely-used accessibility testing tool, for its flexibility and WCAG alignment. Integrating Axe into Slack’s existing test frameworks presented some challenges. Embedding Axe checks directly into React Testing Library (RTL) and Jest created conflicts, further complicating the development process.

Slack accessibility team envisioned using Playwright, a testing framework compatible with Axe via the @axe-core/playwright package. However, integrating Axe checks into Playwright’s Locator object posed its own set of challenges. To overcome these hurdles, Slack adopted a customized approach, strategically adding accessibility checks in Playwright tests after key user interactions to ensure content was fully rendered. Slack also customized Axe checks by filtering out irrelevant rules and focusing initially on critical violations. The checks were integrated into Playwright’s fixture model, and developers were given a custom function runAxeAndSaveViolations to trigger checks within test specifications.

The tech community on Hacker News took notice of this blog. One of the maintainers of axe accessibility testing engine with HN username dbjorge commented on the post,

It’s awesome to see such a detailed writeup of how folks are building on our team’s work…. It’s very enlightening to see which features the Slack folks prioritized for their setup and to see some of the stuff they were able to do by going deep on integration with Playwright specifically. It’s not often you are lucky enough to get feedback as strong as “we cared about enough to invest a bunch of engineering time into it.

To improve reporting, Slack included violation details and screenshots using Playwright’s HTML Reporter and customized error messages. Their testing strategy involved a non-blocking test suite mirroring critical functionality tests, with accessibility checks added to avoid redundancy. Developers can run tests locally, schedule periodic runs, or integrate them into continuous integration (CI) pipelines. The accessibility team further collaborates with developers to triage automated violations, using a Jira workflow for tracking.

Regular audits ensure coverage and prevent duplicate checks, with Slack exploring AI-driven solutions to automate this process.

Slack aims to continue balancing automation and manual testing. Future plans include developing blocking tests for core functionalities such as keyboard navigation, and using AI to refine test results and automate the placement of accessibility checks.

Git 2.48 now supports the Meson build system, a modern alternative to the existing Makefile, Autoconf, and CMake-based systems. This change addresses limitations in IDE support and maintenance issues with older systems.

According to Christian Couder, GitLab’s Git Expert, Meson offers several key advantages over previous build systems in Git 2.48. These include a user-friendly syntax, broad compatibility, support for modern features, and easy access to build options. The Meson build process involves setting up a build directory, compiling, testing, and installing using straightforward commands.

Git 2.48 has achieved a major milestone: it is now free of memory leaks, as exercised by its test suite. Previously, 223 test files had memory leaks, which were reduced to 60 by Git 2.47 and are now resolved. This accomplishment is aligned with the goal of “libifying” Git’s internal components (turning them into libraries) and optimizing memory usage. Unless exceptional justification is provided, new tests must now be leak-free by default.

Similar to regular fetches, fetches using bundle URIs can now undergo comprehensive validation using the fsck mechanism. This enhancement provides granular control over what issues are accepted or rejected based on severity levels. Previously unavailable for bundle fetches, this feature improves repository safety and usability.

In Git 2.48, work on reference consistency checks has progressed further. The git-fsck command can now detect issues such as invalid reference content or symbolic references pointing to non-existent targets. These checks were integrated into git-fsck after being developed as part of the Google Summer of Code (GSoC) 2024.

The tech communities on Lobster and Reddit engaged in discussions and shared their opinions on the announcement. This conversation thread on Lobsters noted that Git and GitHub still rely on SHA-1, despite known vulnerabilities. While Git includes safety measures, concerns exist about interoperability issues and the potential for accidental triggering of collision detection mechanisms.

Furthermore, Reftables, introduced in Git 2.45 as a backend for storing references (e.g., branches and tags), have seen performance improvements through iterator reuse. Previously, reading references required creating new iterators for each operation, which was inefficient for repeated reads. Now, a single iterator can be reused across multiple reads, resulting in a 7% speedup in creating references during transactions with random reads and the potential for further optimizations by reusing more states within iterators.

Git 2.48 has also added support for migrating reflogs between backends using the git refs migrate command. Previously, reflogs could not be converted between file-based and reftables backends during migration efforts introduced in Git 2.46. While this tool still cannot handle repositories with multiple worktrees, it removes a critical limitation for users adopting reftables in their repositories.

The ref-filter subsystem, used by commands like git branch, git tag, and git for-each-ref, has been optimized to improve performance when processing large numbers of references in repositories.

The original announcement blog highlights a number of contributors for their efforts and a complete list of contributors can be found in the project release notes.

Thoughtworks recently published their Technology Radar Volume 31, providing an opinionated guide to the current technology landscape.

As per the Technology Radar, Generative AI and Large Language Models (LLMs) dominate, with a focus on their responsible use in software development. AI-powered coding tools are evolving, necessitating a balance between AI assistance and human expertise.

Rust is gaining prominence in systems programming, with many new tools being written in it. WebAssembly (WASM) 1.0’s support by major browsers is opening new possibilities for cross-platform development. The report also notes rapid growth in the ecosystem of tools supporting language models, including guardrails, evaluation frameworks, and vector databases.

In the Techniques quadrant, notable items in the Adopt ring include 1% canary releases, component testing, continuous deployment, and retrieval-augmented generation (RAG). The Radar stresses the need to balance AI innovation with proven engineering practices, maintaining crucial software development techniques like unit testing and architectural fitness functions.

For Platforms, the Radar highlights tools like Databricks Unity Catalog, FastChat, and GCP Vertex AI Agent Builder in the Trial ring. It also assesses emerging platforms such as Azure AI Search, large vision model platforms such as V7, Nvidia Deepstream SDK and Roboflow, along with SpinKube. This quadrant highlights the rapid growth in tools supporting language models, including those for guardrails, evaluations, agent building, and vector databases, indicating a significant shift towards AI-centric platform development.

The Tools section underscores the importance of having a robust toolkit that combines AI capabilities with reliable software development utilities. The Radar recommends adopting Bruno, K9s, and visual regression testing tools like BackstopJS. It suggests trialing AWS Control Tower, ClickHouse, and pgvector, among others, reflecting a focus on cloud management, data processing, and AI-related database technologies.

For Languages and Frameworks, dbt and Testcontainers are recommended for adoption. The Trial ring includes CAP, CARLA, and LlamaIndex, reflecting the growing interest in AI and machine learning frameworks.

The Technology Radar also highlighted the growing interest in small language models (SLMs) as an alternative to large language models (LLMs) for certain applications, noting their potential for better performance in specific contexts and their ability to run on edge devices. This edition drew a parallel between the current rapid growth of AI technologies and the explosive expansion of the JavaScript ecosystem around 2015.

Overall, the Technology Radar Vol 31 reflects a technology landscape heavily influenced by AI and machine learning advancements, while also emphasizing the continued importance of solid software engineering practices. Created by Thoughtworks’ Technology Advisory Board, the technology Radar provides valuable insights twice-yearly for developers, architects, and technology leaders navigating the rapidly evolving tech ecosystem, offering guidance on which technologies to adopt, trial, assess, or approach with caution.

The Thoughtworks Technology Radar is available in two formats for readers: an interactive online version accessible through the website, and a downloadable PDF document.

Recently, AWS CodeBuild introduced support for managed GitLab self-hosted runners, towards advancement in continuous integration and continuous delivery (CI/CD) capabilities. This new feature allows customers to configure their CodeBuild projects to receive and execute GitLab CI/CD job events directly on CodeBuild’s ephemeral hosts.

The integration offers several key benefits including Native AWS Integration, Compute Flexibility and Global Availability. GitLab jobs can now seamlessly integrate with AWS services, leveraging features such as IAM, AWS Secrets Manager, AWS CloudTrail, and Amazon VPC. This integration enhances security and convenience for the users.

Furthermore, customers gain access to all compute platforms offered by CodeBuild, including Lambda functions, GPU-enhanced instances, and Arm-based instances. This flexibility allows for optimized resource allocation based on specific job requirements.The integration is available in all regions where CodeBuild is offered.

To implement this feature, users need to set up webhooks in their CodeBuild projects and update their GitLab CI YAML files to utilize self-managed runners hosted on CodeBuild machines.

The setup process involves connecting CodeBuild to GitLab using OAuth, which requires additional permissions such as create_runner and manage_runner.

It’s important to note that CodeBuild will only process GitLab CI/CD pipeline job events if a webhook has filter groups containing the WORKFLOW_JOB_QUEUED event filter. The buildspec in CodeBuild projects will be ignored unless buildspec-override:true is added as a label, as CodeBuild overrides it to set up the self-managed runner.

When a GitLab CI/CD pipeline run occurs, CodeBuild receives the job events through the webhook and starts a build to run an ephemeral GitLab runner for each job in the pipeline. Once the job is completed, the runner and associated build process are immediately terminated.

As a side, GitLab has been in the news since earlier this year as they planned to introduce CI Steps, which are reusable and composable pieces of a job that can be referenced in pipeline configurations. These steps will be integrated into the CI/CD Catalog, allowing users to publish, unpublish, search, and consume steps similarly to how they use components.

Moreover, GitLab is working on providing users with better visibility into component usage across various project pipelines. This will help users identify outdated versions and take prompt corrective actions, promoting better version control and project alignment.

AWS CodeBuild has been in the news as well, as they added support for Mac Builds. Engineers can build artifacts on managed Apple M2 instances that run on macOS 14 Sonoma. Few weeks ago, AWS CodeBuild enabled customers to configure automatic retries for their builds, reducing manual intervention upon build failures. They have also added support for building Windows docker images in reserved fleets.

Such developments demonstrate the ongoing evolution of CI/CD tools and practices, with a focus on improving integration, flexibility, and ease of use for DevOps teams.

The Kubernetes project has recently announced the release of version 1.31, codenamed “Elli”. This version incorporates 45 enhancements, with 11 features reaching Stable status, 22 moving to Beta, and 12 new Alpha features introduced. Key features in this release include enhanced container security with AppArmor, improved reliability for load balancers, insights into PersistentVolume phase transitions, and support for OCI image volumes.

Matteo Bianchi, Edith (Edi) Puclla, Rashan Smith and Yiğit Demirbaş from the Kubernetes Release Communications team covered this announcement in a blog post. Kubernetes v1.31 marks the first release following the project’s 10th anniversary.

Among the stable features in this release, Kubernetes now fully supports AppArmor for enhanced container security. Engineers can use the appArmorProfile.type field in the container’s securityContext for configuration. It is recommended to migrate from annotations (used before v1.30) to this new field.

Kubernetes v1.31 now also offers stable improved ingress connectivity reliability for load balancers, minimizing traffic drops during node terminations. This feature requires kube-proxy as the default service proxy and a load balancer supporting connection draining. No additional configuration is needed as it’s been enabled by default since v1.30.

The latest release introduces a new feature to track the timing of PersistentVolume phase transitions. This is achieved through the addition of a lastTransitionTime field in the PersistentVolumeStatus, which records the timestamp whenever a PersistentVolume changes its phase (e.g., from Pending to Bound).

This information is valuable for measuring the duration it takes for a PersistentVolume to become available for use, thus aiding in monitoring and improving provisioning speed.

Furthermore, this feature provides valuable data that can be utilized to set up metrics and service level objectives (SLOs) related to storage provisioning in Kubernetes.

One of the features in the release, which is now in Alpha, is support for Open Container Initiative (OCI) compatible image volumes. Kubernetes v1.31 introduces an experimental feature that allows the direct use of OCI images as volumes within pods. This helps AI/ML workflows by enabling easier access to containerized data and models.

The cloud native technology community showed particular excitement about this feature. Users of the Kubernetes subreddit took notice of the announcement post. One of the Reddit users expressed that this is a “very cool” feature, and in the same thread explained the benefits of having the model as an image.

AI & Kubernetes experts at Defense Unicors (a Medium Publication) also welcomed the use of OCI images to manage and share the AI models, making the process smoother and more integrated with other tools.

The features that graduated to Beta include nftables API, the successor to the iptables API, that delivers improved performance and scalability. Notably, the nftables proxy mode processes service endpoint changes and packets more efficiently than iptables, particularly benefiting clusters with extensive service counts.

For further engagement, users can join the Kubernetes community on Slack or Discord, or post questions on Stack Overflow. Kubernetes v1.31 is available for download from the official website or GitHub.

The Guardian’s engineering team recently shared their experience with Qubes OS, a security-focused desktop operating system. The engineering team configured the Qubes workstations utilizing SaltStack, the default management engine in the Qubes OS.

Philip McMahon, Staff Software Engineer at The Guardian, detailed the engineering team’s journey navigating the steep learning curve of Qubes OS in a blog post. Qubes OS is also being adopted by the Freedom of the Press Foundation to improve its SecureDrop whistleblower platform, making it more user-friendly and secure for journalists.

Qubes OS offers an alternative to separate air-gapped machines, utilizing offline virtual machines, or “Qubes,” to handle sensitive messages. This approach allows for secure decryption and reading of downloaded messages within a familiar chat client interface on the same machine.

McMahon stated that the team’s goal with Qubes was to create an offline, Debian 11-based Virtual Machine(VM) that could be reset to a known state after each restart, removing any generated or downloaded data. This VM would have specific packages installed from both default and custom repositories, including a custom package from a private repository hosted on Amazon S3.

Additionally, they wanted to include a Nautilus extension and a configuration file containing sensitive information that couldn’t be hard-coded into the system.

Salt configuration in Qubes begins with a .top file.

# guardian.top

base:
 dom0:
   - guardian-vms

The above top file instructs Salt to apply the guardian-vms state on dom0. The .sls state file contains the instructions for the previously mentioned guardian-vms state.

# guardian-vms.sls

create-guardian-template:
 qvm.vm:
   - name: guardian-template
   - clone:
     - source: debian-11
     - label: black
   - prefs:
     - netvm: ""

create-app:
 qvm.vm:
   - name: app
   - present:
     - template: guardian-template
     - label: green
   - prefs:
     - template: guardian-template
     - netvm: ""

The state file accomplishes two key tasks: it creates a template virtual machine named guardian-template based on Debian 11, which operates offline. It also establishes an application virtual machine called guardian based on this template, functioning offline.

The template VM acts as a base for the app VM, containing all the necessary software. Each time the app VM restarts, its file system (except for the home folder) reverts to the template VM’s state, removing any malicious code and enhancing security. For a deeper dive into Template and App VMs, interested readers can check out the Qubes documentation.

Once the above offline VM app is created, it can be useful for some basic tasks. Installing software for viewing, editing, and sanitizing files can be done directly through a terminal in the template VM using APT. However, integrating this into the Salt configuration requires creating a new state file.

# install-packages.sls

install-packages:
 pkg.installed:
   - pkgs:
     - libreoffice
     - gedit
     - vlc

Additionally, there is a need to update the top file to instruct Qubes to apply the install-packages state to the guardian-template VM

# guardian.top

base:
 dom0:
   - guardian-vms

 guardian-template:
   - install-packages

We came across an interesting discussion on Hacker News, following the blog post by The Guardian. HN user cangeroo inquired about the acceptance of Qubes OS and airgapping in professional settings, and the use of specialized security equipment and processes. They also expressed surprise at the frequency of crypto theft and questioned the availability and adoption of airgapped solutions.

We also saw the tech community on Hacker News (HN) showing a keen interest in the latest developments of Qubes OS, initiating discussions upon the release of versions 4.2.0 and 4.2.1.

McMahon’s blog post also delves into other aspects of using Qubes OS, such as installing software not found in default repositories, avoiding network access on the template VM, utilizing disposable VMs, and customizing VMs to fit specific needs.

McMahon hopes his blog post will help others using Qubes OS and invites readers to reach out via email with any questions or feedback.

The Guardian’s engineering team recently shared their experience with Qubes OS, a security-focused desktop operating system. The engineering team configured the Qubes workstations utilizing SaltStack, the default management engine in the Qubes OS.

Philip McMahon, Staff Software Engineer at The Guardian, detailed the engineering team’s journey navigating the steep learning curve of Qubes OS in a blog post. Qubes OS is also being adopted by the Freedom of the Press Foundation to improve its SecureDrop whistleblower platform, making it more user-friendly and secure for journalists.

Qubes OS offers an alternative to separate air-gapped machines, utilizing offline virtual machines, or “Qubes,” to handle sensitive messages. This approach allows for secure decryption and reading of downloaded messages within a familiar chat client interface on the same machine.

McMahon stated that the team’s goal with Qubes was to create an offline, Debian 11-based Virtual Machine(VM) that could be reset to a known state after each restart, removing any generated or downloaded data. This VM would have specific packages installed from both default and custom repositories, including a custom package from a private repository hosted on Amazon S3.

Additionally, they wanted to include a Nautilus extension and a configuration file containing sensitive information that couldn’t be hard-coded into the system.

Salt configuration in Qubes begins with a .top file.

# guardian.top

base:
 dom0:
   - guardian-vms

The above top file instructs Salt to apply the guardian-vms state on dom0. The .sls state file contains the instructions for the previously mentioned guardian-vms state.

# guardian-vms.sls

create-guardian-template:
 qvm.vm:
   - name: guardian-template
   - clone:
     - source: debian-11
     - label: black
   - prefs:
     - netvm: ""

create-app:
 qvm.vm:
   - name: app
   - present:
     - template: guardian-template
     - label: green
   - prefs:
     - template: guardian-template
     - netvm: ""

The state file accomplishes two key tasks: it creates a template virtual machine named guardian-template based on Debian 11, which operates offline. It also establishes an application virtual machine called guardian based on this template, functioning offline.

The template VM acts as a base for the app VM, containing all the necessary software. Each time the app VM restarts, its file system (except for the home folder) reverts to the template VM’s state, removing any malicious code and enhancing security. For a deeper dive into Template and App VMs, interested readers can check out the Qubes documentation.

Once the above offline VM app is created, it can be useful for some basic tasks. Installing software for viewing, editing, and sanitizing files can be done directly through a terminal in the template VM using APT. However, integrating this into the Salt configuration requires creating a new state file.

# install-packages.sls

install-packages:
 pkg.installed:
   - pkgs:
     - libreoffice
     - gedit
     - vlc

Additionally, there is a need to update the top file to instruct Qubes to apply the install-packages state to the guardian-template VM

# guardian.top

base:
 dom0:
   - guardian-vms

 guardian-template:
   - install-packages

We came across an interesting discussion on Hacker News, following the blog post by The Guardian. HN user cangeroo inquired about the acceptance of Qubes OS and airgapping in professional settings, and the use of specialized security equipment and processes. They also expressed surprise at the frequency of crypto theft and questioned the availability and adoption of airgapped solutions.

We also saw the tech community on Hacker News (HN) showing a keen interest in the latest developments of Qubes OS, initiating discussions upon the release of versions 4.2.0 and 4.2.1.

McMahon’s blog post also delves into other aspects of using Qubes OS, such as installing software not found in default repositories, avoiding network access on the template VM, utilizing disposable VMs, and customizing VMs to fit specific needs.

McMahon hopes his blog post will help others using Qubes OS and invites readers to reach out via email with any questions or feedback.

Recently, GitHub talked about using merge queues to implement code updates. Merge queues have been developed and scaled to manage over 30,000 pull requests, alongside the corresponding 4.5 million CI executions, for GitHub.com.

The merge queue system organizes pull requests into deployable batches, initiates builds and tests through GitHub Actions, and maintains the integrity of the main branch by preventing updates with failing commits, by following branch protection regulations. Conflicting pull requests within the queue are automatically identified and excluded, with the system regrouping as necessary.

Will Smythe, staff product manager, and Lawrence Gripper, staff engineer at GitHub, elaborated on GitHub’s journey with merge queues in a blog post. Aside from increasing developer velocity, the move to merge queues was aimed at enhancing the overall experience for developers in shipping their work, preventing problematic pull requests from affecting the broader team, and ensuring a consistent and highly automated process across all services and repositories.

By mid-2021, GitHub began piloting the merge queue feature with several smaller, internal repositories. They implemented changes to the process in stages, which involved testing and reverting modifications early in the morning before the majority of developers started their workday. Over time, GitHub systematically migrated its large monorepo and all repositories linked to production services to the merge queue system by 2023.

The merge queue blends into GitHub’s existing pull request workflow, eliminating the need for developers to learn specific ChatOps commands, or to utilize labels or particular comment syntax for state management, enhancing GitHub’s developer experience. Developers can easily queue their pull requests and, if they identify any issues with their changes, exit the queue with one click.

Following the general release of the merge queue by GitHub in around Q3 2023, we stumbled upon a relevant discussion on Hacker News. The tech community participated actively in the discussion, with a user highlighting their few months-long uses of the system for monorepo pull request merges, acknowledging its substantial improvements to the process. They also praised the system’s faster ability and reliable trunk-based releases, expressing appreciation towards the team behind the feature.

Another user inquired whether merge queues would be arriving in Azure DevOps anytime soon, indicating interest in its availability. One participant responded in the thread perceiving the lack of updates in Azure Repos and pointing out its continued reliance on ssh-rsa host keys for SSH Git—a protocol deprecated by OpenSSH for several years.

Monthly, more than 500 engineers utilize merge queue to integrate 2,500 pull requests into GitHub’s large monorepo, resulting in a 33% reduction in the average time to deploy a change. In a periodic developer satisfaction survey conducted by GitHub, an engineer applauded the merge queue as “one of the most significant quality-of-life enhancements for deploying changes that I’ve witnessed at GitHub!”