devopsy.kinsta.cloud

Author: Mike Vizard

  • GitLab Adds More AI and Cybersecurity Capabilities to CI/CD Platform

    GitLab Adds More AI and Cybersecurity Capabilities to CI/CD Platform

    GitLab this week delivered an update to its continuous integration/continuous delivery (CI/CD) platform that adds additional generative artificial intelligence (AI) and cybersecurity capabilities.

    The GitLab 16 release included cybersecurity capabilities such as centralized policy management, expanded compliance reports and controls, compliance dashboards and default Level 3 attestation for the supply-chain levels for software artifacts (SLSA) framework.

    At the same time, GitLab this week also made available an emergency patch for two modules that have a path traversal flaw, tracked as CVE-2023-2825, that could allow unauthenticated users to read arbitrary files on the server under certain circumstances.

    In terms of generative AI, GitLab 16 added a value stream forecasting capability that automatically generates workflow summaries for senior managers. GitLab is also adding a code refactoring capability and the ability to automatically resolve vulnerabilities to an update to GitLab 16. Previously, GitLab made available a ‘suggested reviewers’ features, an ‘explain this code’ and an ‘explain this vulnerability’ capability that are all enabled by large language models (LLMs) developed by Google. GitLab has also partnered with Oracle to provide additional AI capabilities enabled by machine learning algorithms. In 2021, GitLab acquired UnReview, a provider of a tool that uses AI to identify which expert code reviewers to assign to a project based on the quality of their previous efforts and current workloads.

    David DeSanto, chief product officer at GitLab, said with 10 AI capabilities GitLab is providing more of these types of capabilities than any other DevOps platform provider. In addition, those capabilities are distributed across the entire software development life cycle rather than being focused solely on making developers more productive, he noted.

    That’s critical, because if AI capabilities are only focused on developer productivity, an imbalance is created; DevOps workflows will not be able to absorb the increased amount of code that will soon be moving simultaneously through pipelines, DeSanto added.

    AI will also further fuel adoption of platform engineering as a means for centralizing DevOps management. It’s becoming more apparent that infusing these types of capabilities into DevOps platforms built and maintained by an internal IT team is going to be a major challenge, he added.

    There is no doubt that generative AI capabilities will soon become widely integrated across DevOps workflows. That will enable developers to build more secure code faster while at the same time making it simpler for software engineers to maintain large codebases. Just about every job function imaginable will be impacted to varying degrees. In the case of DevOps teams, the ultimate impact should involve less drudgery as many of the manual tasks that conspire to make managing DevOps workflows tedious are eliminated. In fact, AI may ultimately make DevOps, as a methodology for managing IT, more accessible to a much wider range of organizations.

    As AI advances, there should still be plenty of demand for human expertise. For better or worse, the nature of the expertise required, however, will undoubtedly be at a much higher level than it has previously been as more low-level tasks are automated. The challenge is determining how and where to refocus the efforts of the DevOps teams to add higher value.

  • The Metrics Disconnect Between Developers and IT Leaders

    The Metrics Disconnect Between Developers and IT Leaders

    A survey of 350 software developers found a majority (91%) of respondents are unhappy with the actual metrics leadership teams are measuring.

    The survey, conducted by Atomik Research on behalf of Uplevel, an enterprise intelligence platform provider, found the top metrics developers say should be tracked include hours worked (52%), work allocation (49%) and the amount of time they have to focus on writing code (46%).

    Unfortunately, the survey also revealed more than half of respondents (56%) reported that the CTOs that lead software development efforts make significant strategic decisions without realizing the negative impact on their team. They also often move people around on projects or tasks without knowing the full implications (51%) and overwork developers (44%).

    Just under a third (30%) noted their engineering leaders rely solely on gut feelings to measure the effectiveness of their teams, while a third of respondents observed most engineering roadblocks go unnoticed by leadership.

    Additionally, 96% noted that not knowing what their own leadership team is working on is detrimental to the larger team.

    Christina Forney, vice president of product management for Uplevel, said many CTOs clearly need to be more engaged. Developers don’t mind being measured, but they clearly want to be evaluated based on metrics that matter, she added.

    Managing software development teams has become a lot more challenging in an era where many developers are working remotely. IT leaders can no longer manage by walking around as easily as they once did, said Forney. Aligning workflows across a highly distributed team of developers is a challenge no matter how many communications platforms are used.

    Surprisingly, the Uplevel survey found more than half of respondents (54%) said they feel more productive in the office. More than a third (35%) also said they preferred some form of synchronous communication to engage with other members of their team versus 27% that preferred some form of asynchronous communication. A total of 38% said they preferred a mix.

    It’s no secret that despite long-standing commitments to automation, there are still a lot of manual processes in DevOps workflows that create bottlenecks. In an uncertain economy, however, there’s a lot more focus on developer productivity, so eliminating DevOps bottlenecks has become a major priority. The challenge is those bottlenecks are not as apparent to senior IT leaders, many of whom may have simply become inured to them over time.

    Regardless of how bottlenecks occurred, DevOps teams would be well-advised to reevaluate the metrics they track. Mean-time-to-recovery (MTTR), for example, is not as important a metric to the business as the amount of quality code that finds its way into a production environment.

    In theory, all the data required to track more meaningful metrics that could improve productivity already exists in the tools and platforms DevOps teams use to build and deploy an application. The challenge has been finding a way to automatically surface that data without adding yet another bottleneck to a DevOps workflow.

  • Dell Looks to Expand Pool of Available DevOps Expertise

    Dell Looks to Expand Pool of Available DevOps Expertise

    Dell Technologies has quietly launched a training and education initiative to significantly expand the number of IT professionals that have DevOps skills.

    Brad Maltz, senior director for DevOps and developer relations ecosystems for Dell, said the next era of IT will require IT professionals that understand how to automate the management of application development and deployment. Given its long infrastructure history, Dell is especially interested in helping IT teams to use a mix of graphical tools and command line interfaces (CLIs) to programmatically deploy software at much faster rates and at scale, he added.

    Dell has already hired more than 200 specialists to provide that training as part of a DevOps Transformation Services consulting services engagement, said Maltz. The primary area of focus will be working with IT organizations that are embracing platform engineering to centralize the management of DevOps and GitOps workflows, he noted. Many of those teams are now relying on declarative automation tools that ultimately make DevOps more accessible to a wider range of IT professionals, added Maltz.

    The number of IT professionals that employ graphical tools based on IT management frameworks such as ITIL still far outnumber the number of IT professionals that have DevOps skills. The ongoing debate between these two camps essentially comes down to the need to be able to consistently manage IT at scale versus being able to adroitly keep pace with the needs of organizations that are increasingly dependent on software. In the digital transformation era, it’s become clear that more of the organizations that hire IT professionals are placing a higher value on agility, said Maltz.

    Bridging the divide between ITIL and DevOps to address that requirement is largely a psychological challenge that requires IT teams to address a range of cultural issues in addition to mastering different types of tooling, he added.

    Regardless of whether organizations continue to manage IT infrastructure internally or rely more heavily on managed services provided by Dell, the need to continuously deliver secure software faster has become a business issue. The trouble is the level of DevOps expertise within organizations tends to vary widely. A recent survey published by the Continuous Delivery (CD) Foundation found only 22% of respondents are using both continuous integration (CI) and continuous delivery (CD) to automate all building, testing and deployment of code in a production environment. Most organizations that have adopted DevOps make extensive use of CI to build applications, but CD has proven to be more challenging to master. In fact, the CD Foundation survey found only 7% of respondents described themselves as DevOps engineers or specialists.

    The bulk of the managed services that Dell provides are focused on managing infrastructure rather than deploying software, but the company does have a managed DevOps offering based on the application development and deployment platform that an internal Dell DevOps team built to construct and deploy applications. Naturally, Dell has a vested interest in accelerating the rate at which software can be deployed on IT infrastructure it provides and manages.

    It may be a while before the overall size of the DevOps community expands, but the training initiatives such as the one launched by Dell will help. However, it may become a lot easier to find and retain that talent in the months and years ahead. In the meantime, organizations would be well-advised to invest in upskilling their own IT teams. After all, it’s less expensive to train someone that already works within an IT organization than it is to compete against thousands of other organizations willing to pay top dollar for the best DevOps expertise money can buy.

  • Microsoft Adds Slew of Developer Tools to Azure

    Microsoft Adds Slew of Developer Tools to Azure

    At its Build 2023 conference this week, Microsoft announced general availability of an Azure Deployment Environment service that provides developers with a portal through which they can employ infrastructure-as-a-code (IaC) templates based on Terraform or Azure Resource Management files.

    In addition, Microsoft has enhanced Microsoft Dev Box, a workstation environment for developers that run Azure, to include a portal through which they can manage multiple environments.

    Scheduled to be generally available in July, Microsoft Dev Box is also previewing a capability that makes it possible to customize environments using configuration-as-code files stored in a Git repository. Microsoft is also previewing tighter integration between Dev Box and its Visual Studio integrated development environment (IDE) and Windows to further customize developers’ environments.

    Scott Guthrie, executive vice president of the cloud and artificial intelligence (AI) group at Microsoft, told conference attendees these and other tools for building cloud-native applications, along with GitHub Actions, make it simpler than ever to build applications in an Azure cloud service that includes an integrated continuous integration/continuous delivery (CI/CD) platform.

    Microsoft is also previewing GitHub Advanced Security for Azure DevOps that natively embeds automated security checks using scanning tools into the Azure DevOps platform.

    Other additions to the Azure environment include tools for centralizing the management of application programming interfaces (APIs) using an Azure API Center service that is available in preview.

    The Azure Event Grid has also been updated to enable it to use HTTP to pull delivery of discrete events in addition to pushing them.

    Finally, Microsoft is also previewing generative artificial intelligence (AI) capabilities to make it simpler to manage cloud costs by, for example, using prompts to summarize invoices or breakdown costs.

    Microsoft, along with its GitHub subsidiary, is at the forefront of applying generative AI to application development using tools like GitHub Copilot that developers can use to write better code faster. That copilot capability is now being disseminated across the portfolio of applications and services that Microsoft provides.

    It’s not yet clear what the downstream impact of such tools are just yet, but the overall quality of the applications being built should improve as, for example, fewer mistakes are made that can lead to vulnerabilities.

    Obviously, the way application software is built, constructed and secured is about to change in the generative AI era. Thanks to its alliance with OpenAI, Microsoft has a significant head start on rivals building generative AI platforms that can similarly be applied to improve developer productivity.

    In the meantime, DevOps teams should assume the volume of code simultaneously moving through pipelines is about to dramatically increase as developers become more productive. There will inevitably be more opportunities to apply multiple forms of AI to reduce any DevOps bottlenecks that might arise, but it’s clear most of the immediate benefits are being provided to developers.

    One way or another, however, the overall rate at which applications are built and deployed is about to change drastically. The issue is understanding how those advances will impact downstream DevOps workflows that were constructed for a different era of application development.

  • Red Hat Adds Generative AI and Event-Driven Capabilities to Ansible

    Red Hat Adds Generative AI and Event-Driven Capabilities to Ansible

    Red Hat today unveiled a technical preview of Ansible Lightspeed with IBM Watson Code Assistant, a generative artificial intelligence (AI) service specifically trained on domain-specific data collected via the Ansible automation platform.

    At the same time, Red Hat is also making available an event-driven capability within version 2.4 of the Ansible platform that enables runbooks and other tasks to automatically execute when received from a third-party tool or application.

    Both capabilities were announced at the Red Hat Summit and are part of an ongoing Red Hat effort to democratize IT automation.

    First previewed within the Project Wisdom initiative launched by Red Hat and IBM Research last year, Ansible Lightspeed IBM Watson Code Assistant is based on a large language model (LLM) that was developed using Ansible data. Watson Code Assistant, currently in technical preview, is a service that automatically generates suggestions to improve code as developers create an application. IBM promised to make IBM Watson Code Assistant available later this year.

    Red Hat is now applying that generative AI capability to the YAML code that DevOps teams need to create Ansible playbooks. IT teams can create a simple natural language prompt that will translate their domain expertise into YAML code for creating or editing Ansible Playbooks. Red Hat and IBM, however, will not automatically use the code from an organization to fine-tune their AI model without express consent.

    Rich Henshall, director of product management for Red Hat Ansible, said as IT environments become more complex, it’s clear many are hitting a ceiling in terms of what can be automated using legacy custom scripts. Ansible Lightspeed IBM Watson Code Assistant, along with an event-driven capability, will make it much simpler to automate the management of IT environments at scale using a declarative framework, he added.

    Ansible, for example, can now receive events from third-party tools, determine next steps and consistently initiate an automated response using Ansible playbooks. Ansible can also consume events from third-party monitoring, observability and IT analytics tools from providers such as Cisco ThousandEyes, CyberArk, Dynatrace, F5, IBM Instana, IBM Turbonomic, Palo Alto Networks and Zabbix with more to come, noted Henshall. Red Hat is also making available supplementary content for Red Hat OpenShift, Red Hat Insights, Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform and ServiceNow, in addition to enabling IT teams to create their own custom integrations.

    At this juncture, it’s not clear why more IT processes have not been automated using Ansible or other frameworks. Many DevOps teams continue to rely on custom scripts that typically don’t scale and are generally poorly documented. Any time the individual who wrote those scripts leaves an organization, it’s incredibly difficult—if not impossible—for the original scripts to be maintained, noted Henshall.

    One way or another, it’s clear that a more scalable approach to IT automation is required, especially with the rise of more complex cloud-native application environments. It’s no longer economically viable for most organizations to rely on legacy processes that require a small army of IT professionals to maintain.

  • Red Hat Moves to Secure Software Supply Chains

    Red Hat Moves to Secure Software Supply Chains

    Red Hat today announced a portfolio of cloud services designed to better secure software supply chains. The expanded portfolio includes Red Hat Trusted Application Pipeline to secure continuous integration/continuous delivery (CI/CD) workflows and Red Hat Trusted Content offerings to better secure software components.

    Announced at the Red Hat Summit, the Red Hat Trusted Software Supply Chain combines a suite of curated open source tools into a cloud service managed by Red Hat. The Red Hat Trusted Application Pipeline service is based on sigstore, an emerging de facto standard for cryptographically signing code to ensure immutability that Red Hat helped drive, while Red Hat Trusted Content provides access to a set of software components that Red Hat has vetted.

    Red Hat Trusted Software Supply Chain also provides access to existing tools such as Quay, a registry for containers, and the Advanced Cluster Security (ACS) platform for securing Kubernetes clusters.

    Red Hat Trusted Software Supply Chain is scheduled to be made available in preview in the next few weeks, and will also track the provenance of components. In addition, the service will monitor emerging threats to software components and alert users of new and emerging risks. The service will also surface recommendations for remediating vulnerabilities it identifies based on best practices defined by Red Hat.

    Finally, Red Hat Trusted Application Pipeline also promises to make it simpler to automate the deployment of secure code with a few clicks within the context of an integrated continuous integration/continuous delivery (CI/CD) pipeline. DevOps team can also import Git repositories and configure container-native continuous build, test and deployment pipelines, inspect source code and transitive dependencies, autogenerate software bill of materials (SBOMs) within builds and verify and promote container images. An enterprise contract policy engine can consistently enforce compliance with the Supply Chain Levels for Software Artifacts (SLSA) framework.

    Finding ways to implement DevSecOps workflows is a major challenge for any organization. Red Hat is making a case for a managed cloud service based on a collection of security software and services that a DevOps team would otherwise have to implement themselves.

    Tasked with securing increasingly complex software development environments, it’s not clear whether DevOps teams will opt to rely on a cloud service, but given the general lack of security expertise among software development teams, the fastest way to secure a software supply chain for most organizations is to rely on a service.

    Regardless of approach, of course, DevSecOps will soon become a standard element of application development workflows. Once that occurs, it’s not clear whether DevOps will simply become DevSecOps or whether security will be assumed to be an integrated element of any set of DevOps best practices.

    Sarwar Raza, vice president and general manager for cloud services at Red Hat, said regardless of approach, it’s clear that implicit trust is no longer good enough. Organizations of all sizes will need to be able to demonstrate that they have maintained a chain of custody for the software components used to build an application, he noted.

    One way or another, the overall security of downstream applications should eventually improve as the processes used to construct software are increasingly locked down.

  • Dell Extends Reach of Managed IT Infrastructure Service Portfolio

    Dell Extends Reach of Managed IT Infrastructure Service Portfolio

    Dell Technologies today expanded the scope of its APEX managed cloud offerings to include integration with the Microsoft Arc hybrid cloud computing framework. In addition, Dell is fulfilling a commitment to deliver block and file storage services on the Microsoft Azure and Amazon Web Services (AWS) cloud platforms.

    The announcements were made at the Dell Technologies World conference where Dell also announced it is extending existing support for managed APEX instances of VMware that include storage services.

    Dell is also making available a bare metal edition of the service, dubbed Dell APEX Compute, that provides IT teams with the option to deploy any virtual machine or Kubernetes cluster of their choice.

    Finally, Dell is also making available an instance of an APEX managed service that supports Red Hat OpenShift, an application development and deployment platform based on Kubernetes.

    Overall, Dell is promising that IT teams will soon be able to move data seamlessly between on-premises environments and Dell APEX Block Storage for Public Cloud. This capability will first be available for AWS and, later this year, Microsoft Azure. As part of that effort, Dell is also launching Dell Navigator, a software-as-a-service (SaaS) platform for managing services such as data replication that includes an edition for Kubernetes clusters. In addition, Dell announced a partnership with Databricks to integrate on-premises storage systems from Dell with the Databricks Lakehouse Platform cloud service.

    Caitlyn Gordon, vice president of multi-cloud product management for Dell Technologies, also claimed that file services running on public clouds using Dell software will be four times faster processing writes than any rival offering.

    The Dell APEX portfolio, at its core, is based on a suite of fully integrated turnkey servers, storage systems, and now, PCs, all managed by Dell on behalf of organizations that subscribe to the APEX service. Dell is now extending the reach of those services into cloud computing environments to make it simpler to deploy workloads everywhere from the network edge to the cloud, said Gordon.

    Most IT organizations today are managing multiple clouds by default. The Dell APEX services simplify the management of those environments by employing the same type of operating model to manage on-premises IT environments, she added.

    Dell is betting that as organizations deploy more complex cloud-native applications, many of them will opt to rely more on external services to manage the underlying infrastructure those applications depend upon. That approach is intended to enable IT organizations to devote more resources to building and deploying applications.

    It’s not clear whether organizations will prefer to rely on Dell to manage their IT, continue to manage it themselves or rely on a third-party IT services provider. Of course, many internal IT organizations are not inclined to cede control over IT infrastructure and applications to a single IT vendor, especially if they use IT infrastructure that has been provided by multiple vendors.

    Regardless of approach, there are now more organizations that prefer to treat IT as an operational expense. In effect, Dell is enabling a cloud operating model to be applied to all IT infrastructure, regardless of where applications are deployed.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    Samsung Electronics America
    Mountain View, California
    Lead Site Reliability Engineer (SRE) – DevOps Specialist
    $180,000 to $210,000

    Indeed.com

    Federal Reserve Bank of New York
    New York, New York
    DevOps Engineer
    $178,100 to $207,900

    CareerBuilder.com

    SAIC
    Chantilly, Virginia
    DevOps Advisor
    $130,000 to $200,000

    Dice.com

    Saicon Consultants
    Alpharetta, Georgia
    DevOps Engineer
    $110,000 to $140,000

    Simply Hired.com

    Hewlett-Packard Enterprise
    Fort Collins, Colorado
    DevOps Automation Engineer
    $109,400 – $251,500

  • Despite DevOps, Software Supply Chain Security Challenges Persist

    Despite DevOps, Software Supply Chain Security Challenges Persist

    A survey of 397 IT, cybersecurity and application development professionals conducted by Enterprise Strategy Group (ESG) found that while most respondents work for organizations that have adopted DevOps practices, multiple software supply chain security issues and DevSecOps concerns have yet to be addressed.

    The survey, conducted on behalf of Data Theorem, a provider of a platform for securing application programming interfaces (APIs), the survey also found 82% of respondents have adopted DevOps, with 51% reporting they make extensive use of DevOps workflows (51%). Nearly three-quarters (73%) are deploying code weekly and 31% are deploying code daily.

    However, securing DevOps workflows remains a work in progress, with 41% reporting security teams lack visibility and control of development processes. Other issues include new builds deployed to production with misconfigurations, vulnerabilities and other security issues (40%), developers skipping security processes (39%), software released without going through security checks and/or testing (38%), lack of security process consistency across different development teams (38%), security team can’t keep pace with release cadences (34%) and developers’ reluctance to work with security (29%).

    API security is also becoming especially challenging, with 92% of respondents dealing with at least one API security incident in the last 12 months. Well over half (57%) have dealt with multiple API security issues in the last 12 months.

    On the plus side, the survey also found that more than half (54%) of teams responsible for securing APIs are involved with development as soon as or before the APIs are published. A full 97% said developers either have a good (22%) or high level (71%) of API security knowledge. A total of 89% reported their organization provides formal API security training to their development teams. More than three-quarters (78%) can remediate an API vulnerability within a day, and 39% reported they can do so within hours. A total of 60% reported a dedicated budget has been specifically allocated to API security, with another 30% identifying it as a discrete item within their cybersecurity budget. Two-thirds (66%) said spending on API security would significantly increase in the next 12 to 18 months.

    The use of APIs is only going to increase in the months and years ahead. Well over one-third (36%) of respondents are using APIs across all their applications, with 50% expecting this to be the case in two years. Another 44% reported most of their applications are using APIs., with 32% expecting this to be the case in two years. More than three-quarters (76%) of organizations reported that they have an average of 26 APIs per application and 53% have more than a quarter of their APIs facing the internet.

    More than a third (35%) are updating APIs daily while another 40% do so weekly. A full 61% are using APIs to connect microservices.

    Data Theorem COO Doug Dooley said those APIs are now being targeted by cybercriminals that routinely test the weaknesses of every API after each deployment and update. The most common types of API attacks reported by survey respondents included exposure of data (32%), account takeover (31%), denial of service (DoS) attack (31%), attack on misconfigured API (30%), fake account creation (28%), API injection attack (28%), ransomware (27%), data breach (26%) and content scraping (26%).

    Despite these issues, however, nearly three-quarters (74%) of survey respondents said they believe their organizations have a robust API security program in place, with 22% reporting they have some process in place. Organizations are using a mix of approaches including API security tools (59%), web application firewalls (WAFs) (57%) and API gateways (50%), distributed DoS mitigation (48%) and bot management solutions (42%).

    Challenges included managing multiple tools (29%), visibility into and control of APIs (28%), inventorying APIs (27%), inconsistent adoption of APIs (27%), API security testing (27%), data governance/exposure (26%), discovering and remediating misconfigured APIs (26%), keeping pace with threats (26%) and accurately tracking API usage (25%).

    Significant API security concerns included API authentication issues (41%), account takeovers (39%), identifying and tracking third-party APIs (38%), using tools not purpose-built for security (38%), shadow/undiscovered APIs (38%), abusive behavior bypassing app security tools (38%), denial of service attacks (38%), data governance and/or data exposure issues as a result of insecure APIs (37%), abusive behavior bypassing bot management (37%) and outdated/unneeded APIs, also known as zombie APIs. (33%).

    The type of vulnerabilities that are of the greatest concern are sensitive data exposure (34%), access control vulnerabilities (31%), API business logic flaws (31%) and DDoS attacks (30%).

    More than 79% of respondents, however, are relying on manual testing and review processes to ensure APIs don’t expose sensitive data (79%), with 63% having automated alerting capability for when sensitive data is exposed.

    Overall, it’s apparent that more resources as being applied to securing software supply chains in general and APIs specifically. However, given the amount of software being built and deployed, it may be a while before organizations see the return on those investments.

  • GitHub Adds Accessibility Improvements for Developers With Disabilities

    GitHub Adds Accessibility Improvements for Developers With Disabilities

    GitHub today revealed it added several capabilities to make it easier for developers with disabilities to access its code repository platform. The new capabilities were announced to coincide with Global Accessibility Awareness Day.

    Capabilities highlighted include a navigation tool and a search tool that can be used with a screen reader that GitHub provides.

    In addition, GitHub’s contribution graph has been updated to remove barriers for keyboard-only and screen reader users.

    Finally, GitHub has made site-wide color contrast improvements to the light and dark themes presented by Primer, the GitHub Design System.

    Ed Summers, head of accessibility for GitHub, said there are more than 1.3 billion individuals with a wide variety of disabilities that could, with access to the right tools, write code. That community today, however, is underrepresented as a percentage of the larger IT community, he noted.

    However, as tools such as GitHub Copilot—a generative artificial intelligence (AI) tool that helps developers write better, more secure code—is paired with GitHub Copilot Voice—a speech interface for GitHub Copilot that is available in technical preview—the GitHub platform becomes more accessible to developers with disabilities, he said.

    Generative AI coupled with a speech interface that eliminates the need for a keyboard is lowering the barrier for entry for every potential developer. But for individuals with disabilities, it represents a tremendous advance, noted Summers. Anyone who understands how code should be constructed can build an application, he added.

    It’s not clear what impact generative AI will have on the global shortage of developer talent that has persisted for decades but it’s clear the pace at which applications can be developed is about to dramatically increase. In addition, many organizations have embraced working from home in the wake of the COVID-19 pandemic. That shift makes it easier for many individuals with disabilities to become part of the workforce because they no longer need to commute to an office.

    Generative AI platforms are fundamentally changing the way humans interact with machines. Instead of requiring a developer to create a level of abstraction to communicate with a machine, it’s now possible for machines to understand the language humans use to communicate with each other. Via a natural language interface, developers will soon be asking generative AI platforms to not only surface suggestions but also debug applications and write the code used to create an application.

    At this point, like it or not, the generative AI genie is out of the proverbial bottle. Just about every job function imaginable will be impacted to varying degrees. In the case of DevOps teams, the ultimate impact should involve less drudgery as many of the manual tasks that conspire to make managing DevOps workflows tedious are eliminated.

    It may be a while before the impact of generative AI is fully appreciated, and there will certainly be more advances to come that will be applicable to individuals with disabilities. In the meantime, however, many members of a DevOps team may not even realize a member of the team has a disability as the writing of code continues to be increasingly automated.