-->

Azure DevOps can guide you through the entire development lifecycle and help you ship out software programs faster while maintaining high quality. Slack is deprecating the Visual Studio Teams Services (VSTS) app from its app store. This app was built by the Slack team few years ago and provides basic integration between VSTS and Slack. Slack with azure devops – Send instant messages to users or channels in Slack and Boost efficiency of your internal processes and automate your operations in Azure DevOps. Do much more by connecting Azure DevOps and Slack. Connect the azure devops and slack the way you need and trigger the action events for better collaboration with teams.

In the Sprint 155 Update of Azure DevOps, we are introducing new Azure Boards reports to make it easier for you to track important team metrics. You will see the new reports under the Analytics tab in the Boards, Backlog and Sprint hubs. These reports are fully interactive and allow you to adjust them to meet your needs.

In addition, we are excited to announce the new Azure Boards app for Slack. The app will let you monitor work item activity and create work items from your Slack channel.

Check out the Features list below for more.

What’s new in Azure DevOps

Features

General:

Azure Boards:

Azure Repos:

Azure Artifacts:

Azure Pipelines:

Multi-stage YAML pipelines

Hosted VMs

Kubernetes

Test

Azure experiences

Integrations

General

Invite GitHub collaborators into Azure DevOps

You can now invite collaborators from GitHub to Azure DevOps when you are signed in with your GitHub identity. You can search and invite other GitHub users from the Project homepage and from the Users page in the Organization settings.

This capability must be enabled for existing organizations via a setting under Policies in the Organization settings. However, it is turned on by default for organizations created by a GitHub identity.

Note

This feature is not available for non-GitHub users, even if the policy is turned on.

To learn more about inviting team members, see the documentation here. If you are having issues connecting to Azure DevOps using GitHub, see the troubleshooting authenticating & inviting GitHub users FAQs.

Azure Boards

Get insights into your team’s health with three new Azure Boards reports

You can’t fix what you can’t see. Therefore, you want to keep a close eye on the state and health of their work processes. With these reports, we are making it easier for you to track important metrics with minimal effort in Azure Boards.

The three new interactive reports are: Burndown, Cumulative Flow Diagram (CFD) and Velocity. You can see the reports in the new analytics tab.

Metrics like sprint burndown, flow of work and team velocity give you the visibility into your team's progress and help answer questions such as:

• How much work do we have left in this sprint? Are we on track to complete it?
• What step of the development process is taking the longest? Can we do something about it?
• Based on previous iterations, how much work should we plan for next the sprint?

Note

The charts previously shown in the headers have been replaced with these enhanced reports.

The new reports are fully interactive and allow you to adjust them for your needs. You can find the new reports under the Analytics tab in each hub.

• The burndown chart can be found under the Sprints hub.

• The CFD and Velocity reports can be accessed from the Analytics tab under Boards and Backlogs by clicking on the relevant card.

With the new reports you have more control and information about your team. Here are some examples:

• The Sprint Burndown and the Velocity reports can be set to use count of work items or sum of remaining work.
• You can adjust the timeframe of the sprint burndown without affecting the project dates. So, if your team usually spends the first day of each sprint planning, you can now match the chart to reflect that.
• The Burndown chart now has a watermark showing weekends.
• The CFD report lets you remove board columns like Design to gain more focus on the flow the teams have control on.

Here is an example of the CFD report showing the flow for the last 30 days of the Stories backlog.

The Velocity chart can now be tracked for all backlog levels. For example, you can now add both Features and Epics whereas before the previous chart supported only Requirements. Here is an example of a velocity report for the last 6 iterations of the Features backlog.

Azure Boards app for Slack

We're happy to announce the new Azure Boards app for Slack. With this app you can monitor work item activity and create work items from your Slack channel.

The app allows you to set up and manage event subscriptions including creation, and work item updates, and to get notifications for these events in your Slack channel. The conversations in the Slack channel can be used to create work items. ​ You will also get personal notifications when work items are assigned to you. In addition, previews for work item URLs will let you initiate discussions.

To install the Azure Boards app, click here.

Customize Taskboard columns

We're excited to announce that we added an option to let you customize the columns on the Taskboard. You can now add, remove, rename, and reorder the columns.

To configure the columns on your Taskboard, go to Column Options.

This feature was prioritized based on a suggestion from the Developer Community.

Toggle to show or hide completed child work items on the backlog

Many times, when refining the backlog, you only want to see items that have not been completed. Now, you have the ability to show or hide completed child items on the backlog.

If the toggle is on, you will see all child items in a completed state. When the toggle is off, all child items in a completed state will be hidden from the backlog.

Search for boards, backlogs, queries and sprint from the instant search box

Now you can easily access your recently visited boards, backlogs, queries and sprints from the search box by activating the search box in Azure Boards.

In addition, you can search for the boards, backlogs, queries and sprints across your project by typing the board name in the search box. Now, the boards that matter most to you are just a click away.

Most recent tags displayed when tagging a work item

When tagging a work item, the auto-complete option will now display up to five of your most recently used tags. This will make it easier to add the right information to your work items.

Azure Repos

Improved code search filtering options

Previously, code search supported 39 code search filters such as comment: and def:. Data suggested that there were many filters not being used, therefore we are removing a few filters and merging others. With this update we reduced the number of filters to 19. This will help by making code search queries more efficient and reduce clutter in the interface.

For example, now func: maps to method:, i.e. if you search for func:AccountAdmin, the results will be mapped to method:AccountAdmin. Similarly macrodef: and macroref: are mapped to macro:. On the other hand, filters such as union: and org: have been deprecated due to lack of use.

Code coverage metrics and branch policy for pull requests

You can now see code coverage metrics for changes within the pull request (PR) view. This ensures that you have adequately tested your changes through automated tests.Coverage status will appear as a comment in the PR overview. You can view details of coverage information for every code line that is changed in the file diff view.

Additionally, repo owners can now set code coverage policies and prevent large, untested changes from being merged into a branch. Desired coverage thresholds can be defined in an azurepipelines-coverage.yml settings file that is checked in at the root of the repo and coverage policy can be defined using the existing configure a branch policy for additional services capability in Azure Repos.

Filter comment notifications from pull requests

Comments in pull requests can often generate a lot of noise due to notifications. We've added a custom subscription that allows you to filter which comment notifications you subscribe to by comment age, commenter, deleted comment, mentioned users, pull request author, target branch and thread participants. You can create these notification subscriptions by clicking the user icon on the top right corner and navigating to User settings.

Service hooks for pull request comments

You can now create service hooks for comments in a pull request based on repository and target branch.

Azure Artifacts

Share your packages publicly with public feeds (preview)

You can now create and store your packages inside public feeds. Packages stored within public feeds are available to everyone on the internet without authentication, whether or not they're in your organization, or even logged into an Azure DevOps organization. Learn more about public feeds in our feeds documentation or jump right into our tutorial for sharing packages publicly.

Azure Devops Server Slack Integration

Azure Pipelines

kustomize and kompose as bake options in KubernetesManifest task

kustomize (part of Kubernetes sig-cli) let you customize raw, template-free YAML files for multiple purposes and leaves the original YAML untouched. An option for kustomize has been added under bake action of KubernetesManifest task so that any folder containing kustomization.yaml files can be used for generating the manifest files used in the deploy action of the KubernetesManifest task.

kompose will transform a Docker Compose files into a Kubernetes resource.

Support for cluster admin credentials in HelmDeploy task

Previously, the HelmDeploy task used the cluster user credentials for deployments. This resulted in interactive login prompts and failing pipelines for an Azure Active Directory based RBAC enabled cluster. To address this issue, we added a checkbox that lets you use cluster admin credentials instead of a cluster user credentials.

Manage pipeline variables in YAML editor

We updated the experience for managing pipeline variables in the YAML editor. You no longer have to go to the classic editor to add or update variables in your YAML pipelines.

New predefined variables in YAML pipeline

Variables give you a convenient way to get key bits of data into various parts of your pipeline. With this update we've added a few predefined variables to a deployment job. These variables are automatically set by the system, scoped to the specific deployment job and are read-only.

• Environment.Id - The ID of the environment.
• Environment.Name - The name of the environment targeted by the deployment job.
• Environment.ResourceId - The ID of the resource in the environment targeted by the deployment job.
• Environment.ResourceName - The name of the resource in the environment targeted by the deployment job.

Link work items with multi-stage YAML pipelines

Currently, you can automatically link work items with classic builds. However, this was not possible with YAML pipelines. With this update we have addressed this gap. When you run a pipeline successfully using code from a specified branch, Azure Pipelines will automatically associate the run with all the work items (which are inferred through the commits in that code). When you open the work item, you will be able to see the runs in which the code for that work item was built. To configure this, use the settings panel of a pipeline.

Cancel stage in a multi-stage YAML pipeline run

When running a multi-stage YAML pipeline, you can now cancel the execution of a stage while it is in progress. This is helpful if you know that the stage is going to fail or if you have another run that you want to start. This feature is also a pre-requisite for us to support retrying a failed stage in the future.

Approvals in multi-stage YAML pipelines

We continue to improve multi-stage YAML pipelines, we now let you add manual approvals to these pipelines. Infrastructure owners can protect their environments and seek manual approvals before a stage in any pipeline deploys to them.With complete segregation of roles between infrastructure (environment) and application (pipeline) owners, you will ensure manual sign off for deployment in a particular pipeline and get central control in applying the same checks across all deployments to the environment.

The pipeline runs deploying to dev will stop for approval at the start of the stage.

Updates to hosted pipelines images

We've made updates to several of the Azure Pipelines hosted VM images. You can find more details about the latest releases here. The following changes were added as part of this update:

• For VS2017 and VS2019:

  • Added Azul Java 7
  • Pinned cached Docker images to match host kernel version
  • Added Az Powershell Module v2.3.2
  • Pinned Mercurial to v5.0.0
  • Updated Python to versions 2.7.16, 3.4.4, 3.5.4, 3.6.8, 3.7.4
  • Added Portable Class Library (VS 2019 only)
  • Changed Rust default paths and environment variables

• For Ubuntu 16.04:

  • Updated helm to always pull latest (no longer pinned at v2.14.0)
  • Added several popular Docker containers
  • Updated Python to versions 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
  • Changed Rust default paths and environment variables

• For all images, added an ImageVersion environment variable for the version of the image

For a full list of tools available for a particular image, go to Settings > Agent pools > Details.

Enhancements to DevOps Project for virtual machine

In this update, we enhanced the DevOps Projects virtual machine (VM) workflow to include the VMs that don't comply with the per location quota restriction. Previously, you had to choose the VM by name and offering. Now, you have an on-demand view with more details about the VM offerings such as cost/month, RAM, data disks etc. This makes it easier for you to select the virtual machine that you need.

Single hosted pool

In the last sprint, we communicated that we are rolling out a new hosted pool called Azure Pipelines to replace all the other hosted pools - Hosted, Hosted VS2017, Hosted Ubuntu 1604, Hosted Windows 2019 with VS2019, Hosted macOS, and Hosted macOS High Sierra. This change will be implemented with this release.

Having multiple hosted pools can be confusing at times. You do not get an accurate picture of where concurrency is being consumed. For example, if you have a concurrency of 10 parallel jobs, you see 10 virtual agents in each of the hosted pools, which is not accurate. When your job is waiting on a specific hosted pool (e.g. Hosted VS2017) with all idle agents, you may think that Azure Pipelines service is broken without realizing that the concurrency is possibly consumed in other hosted pools (e.g. Hosted Ubuntu 1604).

With this change, you will see a single hosted pool that will give you an accurate picture of how many jobs are running in that pool. We plan to roll out this change over the next few sprints. You will not have to make any changes to your pipelines since we will automatically redirect jobs from the old hosted pools to the appropriate image in the new unified pool.

Show correct pool information on each job

Previously, when you used a matrix to expand jobs or a variable to identify a pool, we had trouble showing correct pool information in the logs pages. With this update, we fixed the issues causing incorrect pool information to be shown for certain jobs.

In-product support for flaky test management

Flaky tests can affect developers' productivity since test failures may not be related to the changes under test. They can also impact the quality of shipped code. This is why we added in-product support for flaky test management. This functionality supports end-to-end lifecycle with detection, reporting and resolution. Flaky test management supports system and custom detection.

System detection is available via VSTest task rerun capability. A flaky test is a test that provides different outcomes, such as pass or fail, even when there are no changes in the source code or execution environment. All further executions of test for the same branch are also marked flaky until its resolved and unmarked. You can also plug in your custom detection mechanism using our APIs. Once a test is identified as flaky, you can get the details in the in-context test report in the pipeline. You can then decide whether the flaky tests impact your pipeline failure. By default, flaky test information is available as additional meta-data.

Here is an example of a report with the test summary.

For more details about flaky test management, see the documentation here.

Improvements to the Deployment Center for WebApp in the Azure Portal

We've improved the Deployment Center for WebApp in the Azure Portal with support for pipelines with multiple artifacts. Now, if a non-primary artifact of Azure Pipelines is deployed on the web app, you will get relevant details from the Azure Portal. You will also have a deep link to the deployed repo to navigate directly to the repo from the Azure Portal. The repo can be hosted in Azure Repos or in GitHub.

CI triggers for new branches

It has been a long pending request to not trigger CI builds when a new branch is created and when that branch doesn't have changes. Consider the following examples:

• You use the web interface to create a new branch based on an existing branch. This would immediately trigger a new CI build if your branch filter matches the name of the new branch. This is unwanted because the content of the new branch is the same when compared to the existing branch.
• You have a repository with two folders - app and docs. You set up a path filter for CI to match 'app'. In other words, you do not want to create a new build if a change has been pushed to docs. You create a new branch locally, make some changes to docs, and then push that branch to the server. We used to trigger a new CI build. This is unwanted since you explicitly asked not to look for changes in docs folder. However, because of the way we handled a new branch event, it would seem as if a change has been made to the app folder as well.

Now, we have a better way of handling CI for new branches to address these problems. When you publish a new branch, we explicitly look for new commits in that branch, and check whether they match the path filters.

Terraform integration with Azure Pipelines

Terraform is an open-source tool for developing, changing and versioning infrastructure safely and efficiently. Terraform codifies APIs into declarative configuration files allowing you to define and provision infrastructure using a high-level configuration language. You can use the Terraform extension to create resources across all major infrastructure providers: Azure, Amazon Web Services (AWS) and Google Cloud Platform (GCP).

To learn more about the Terraform extension, see the documentation here.

Integration with Google Analytics

The Google Analytics experiments framework lets you test almost any change or variation to a website or app to measure its impact on a specific objective. For example, you might have activities that you want your users to complete (e.g., make a purchase, sign up for a newsletter) and/or metrics that you want to improve (e.g., revenue, session duration, bounce rate). These activities let you identify changes worth implementing based on the direct impact they have on the performance of your feature.

The Google Analytics experiments extension for Azure DevOps adds experimentation steps to the build and release pipelines, so you can continuously iterate, learn and deploy at an accelerated pace by managing the experiments on a continuous basis while gaining all the DevOps benefits from Azure Pipelines.

You can download the Google Analytics experiments extension from the Marketplace.

Pipeline caching (public preview)

Pipeline caching lets you save the results of a long-running operation, like a package restore or a dependency compilation, and restore it back during the next run of a pipeline. This can result in faster builds.

For more details, see the blog post with the full announcement here.

Pipeline variable group and variable management commands

It can be challenging to port YAML based pipelines from one project to another as you need to manually set up the pipeline variables and variable groups. However, with the pipeline variable group and variable management commands, you can now script the set up and management of pipeline variables and variable groups which can in turn be version controlled, allowing you to easily share the instructions to move and set up pipelines from one project to another.

Run pipeline for a PR branch

When creating a PR, it can be challenging to validate if the changes might break the pipeline run on the target branch. However, with the capability to trigger a pipeline run or queue a build for a PR branch, you can now validate and visualize the changes going in by running it against the target pipeline. Refer az pipelines run and az pipelines build queue command documentation for more information.

Skip the first pipeline run

When creating pipelines, sometimes you want to create and commit a YAML file and not trigger the pipeline run as it may result in a faulty run due to a variety of reasons - infrastructure is not ready or need to create and update variable/variable groups etc. With Azure DevOps CLI, you can now to skip the first automated pipeline run on creating a pipeline by including the --skip-first-run parameter. Refer az pipeline create command documentation for more information.

Service endpoint command enhancement

Service endpoint CLI commands supported only azure rm and github service endpoint set up and management. However, with this release, service endpoint commands allow you to create any service endpoint by providing the configuration via file and provides optimized commands - az devops service-endpoint github and az devops service-endpoint azurerm, which provide first class support to create service endpoints of these types. Refer the command documentation for more information.

Next steps

Note

These features will roll out over the next two to three weeks.

Head over to Azure DevOps and take a look.

How to provide feedback

We would love to hear what you think about these features. Use the feedback menu to report a problem or provide a suggestion.

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Sam Guckenheimer

Hark: here is a strange tale of two Microsoft DevOps tools: Azure DevOps and GitHub. Who comes out on top in Azure DevOps vs GitHub? And how did Microsoft end up with twin DevOps tools anyhow? Let’s dig in!

How did Microsoft end up with two DevOps tools?

Once upon a time, there was a Microsoft product called Team Foundation Server (TFS). The online version of TFS then became Visual Studio Online, which became Visual Studio Team Services, which is now Azure DevOps.

Microsoft bought Github in 2018, which is also a DevOps tool and shares a lot of the same features. I mean, what’s that about?

Microsoft bought GitHub to heighten its focus on open-source development and bring Microsoft’s developer tools to new audiences, and now they have two very mature and very popular DevOps tools. Let me explain some of the differences and similarities between Azure DevOps and Github — giving you a clearer understanding of why there are two, and where each fits in.

Developer tool basics: What is Azure DevOps? What is GitHub?

If you’re looking for a more elementary breakdown of Azure DevOps vs GitHub, below are some common questions you might have. Know the gist of what Azure DevOps and GitHub are and do? Jump ahead!

What is GitHub?
GitHub is one of the most well-known open-source project management tools. Git is a version control system. GitHub is a website — a platform where people share Git repositories online. (Repositories are basically snapshots of a version of a bit of code.)

What is Azure DevOps?
Azure DevOps is a collection of Azure developer services for building software. Azure DevOps includes the ability to do what most people use GitHub for, but it also comes with some other unique features. Azure DevOps is a fully integrated set of services that provide you with all the tools necessary for building and maintaining a backlog, hosting your source code repositories, implementing continuous integration, along with delivery and testing workflows for your products before releasing them. (Translation: It’s basically everything you need to make and launch a product.)

How do people use Azure DevOps?
Azure DevOps is used for planning and collaborating on code development and building and deploying applications. Compared to GitHub, Azure DevOps tends to be more preferred by enterprises. Like Github, it offers both public and private repositories.

How do people use GitHub?
GitHub is used by developers and companies to build, ship, and maintain software. It makes it possible to collaborate and share code and keep tabs of what’s changed along the way. (This process can make it easy to track down, say, when or how a bug was introduced.) Like Azure DevOps, it offers public and private repositories and tends to be the favorite of the developer community. Even Microsoft hosts most of its open-source projects on GitHub.

Is Azure DevOps an alternative to GitHub?
Azure DevOps could be seen as a bit of a GitHub alternative. It has repositories. But it also has other tools. It also integrates with GitHub, so there’s the possibility for a “why not both” type situation.

How do I learn Azure DevOps?
Whether you are a developer or not, working solo or in a team, ACG’s Introduction to Azure DevOps course can help you organize the way you plan, create and deliver software. This course will show you how Azure DevOps works, how to get started, and tips and tricks on how to get the most out of Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans, and Azure Artifacts.

How do I learn GitHub?
GitHub offers learning labs to help you get started. Their one-hour introduction to GitHub course is free and a good way to pick up the basics of how to GitHub.

Want to learn more about Azure certifications?
Check out our Azure Certifications and Learning Paths.

Azure DevOps and Github Comparison

Closed Source vs Open Source Management

• GitHub: Preferred by the community. Offers both public and private repositories.
• Azure DevOps: Preferred by the enterprise. Offers both public and private repositories.
• Which is better? Even Microsoft hosts most of their open-source projects on GitHub.

Traditionally GitHub has been one of the go-to places for open source communities and projects. Large, well-known projects such asBootstrap andNode.js are hosted on GitHub, and even most of the Microsoft code base for developer tools and languages is also available on GitHub as open-source. While public projects are free on GitHub, they also offer paid private repositories.

Microsoft Azure DevOps tool is more corporate in approach and while you can definitely host public projects, this is not what the platform is known for. A lot of enterprise-level companies use Azure DevOps as part of their approved product suite.

DevOps Continuous Integration and Deployment (CI/CD)

• GitHub: New and relatively unproven, but easy to use.
• Azure DevOps: Mature and feature-rich pipelines. Good integration with enterprise tooling.
• Which is better? Azure DevOps already has full integration with GitHub repositories, but GitHub Actions are neat and will improve a lot.

Continuous integration, or CI, is the process of continually merging any new code into the master/common code base and building it to make sure nothing is broken. “Fail early” is one of the mantras connected to CI, the thought being that the earlier you find bugs, the easier and cheaper they are to fix.

GitHub has a relatively new feature called “Actions”. These actions can “automate, customize, and execute your software development workflows right in your repository”, including setting up a CI process.

Azure DevOps has an entire section of the platform dedicated to CI.Pipelines is a mature and fully featured service to handle both your CI and CD, continuous delivery. In fact, a lot of the GitHub Actions functionality is built on the same platform as Azure DevOps.

DevOps Project Management

• GitHub: Good if all your stuff is within GitHub
• Azure DevOps: Mature and full-featured. Integrates with 1000+ extensions.
• Which is better? Azure DevOps is the choice here for any semi-serious project and beyond.

A big part of an effective process means having an effectiveDevOps project management tool to keep track of tasks and timelines, issues, and schedules. Both GitHub and Azure DevOps have tools to help project managers, but are they equal?

GitHub Projects is a lesser-known part of GitHub, which offers a good project management platform for code projects already in GitHub.

The Azure Boards, as the project management side of things is called in Azure DevOps, has its roots in TFS, and is a very mature product. As well as working seamlessly with other parts of Azure DevOps, Boards has over 1,000 extensions too for integrating with almost any other system you need to. Get notifications on Slack, hook into AWS services, or create automated documentation.

Code Repository

• GitHub: Spirit animal
• Azure DevOps: Third-favorite child
• Which is better? For hosting code repositories, nothing comes close to GitHub.

Ask almost any open source project where their code is hosted, and it will be GitHub. Code management is where GitHub has its roots. It is its spirit animal. Everything you could possibly do with pull requests, branching, code reviews, and everything else is here.

Azure DevOps has a good code repository offering too, but it isn’t a spirit animal. More like a third favorite child. It works very well, and it does almost everything you want for your projects.

On-Premises

• GitHub: GitHub Enterprise
• Azure DevOps: Azure DevOps Server
• Which is better? Either self-hosted version comes on 3872 floppy disks.

What if you don’t trust this new-fangled cloud stuff? You may have security concerns about hosting the code for your new Nicolas Cage image hosting service in the cloud. Good news! You can get a self-hosted version of both GitHub and Azure DevOps.

GitHub Enterprise is the offering from GitHub and provides all the features from GitHub.com. Similarly,Azure DevOps Server comes on 3872 floppy disks for your installation pleasure.

Reputation

• GitHub: GitHub has the community feels. Companies with open source projects on GitHub get free karma points.
• Azure DevOps: The scent of TFS still lingers. This is enterprise territory.
• Which is better? Microsoft is definitely looking to borrow some reputation points from GitHub.

Azure DevOps came from TFS, possibly one of the Microsoft products with the biggest love/hate division amongst users. Azure DevOps has inherited some of that division. Throughout the many changes and rebranding exercises has emerged a modern tool that is a far cry from the old TFS days, but the memory still lingers at times.

GitHub on the other hand is the default platform for a lot of DevOps tasks, especially anything to do with code management. Most companies will have a development stack that somewhere uses GitHub.

Want to learn more about DevOps Project Management? We have a course for that:Introduction to Azure DevOps and Project Management

FAQs: Comparing Azure DevOps and GitHub

Looking for a TL;DR version? Here are a few frequently asked questions about Azure DevOps and GitHub.

Azure Devops Slack Integration

• What’s the difference between Azure DevOps and Github?
  Both are used in software development and both offer compelling use cases depending on your needs. Historically, GitHub has been the go-to place for open source; Azure DevOps is more corporate and enterprise-focused, though it can also host public projects.
  
• Is Azure DevOps or GitHub better for CI/CD?
  Azure DevOps is more mature and integrates with GitHub repos; GitHub actions are new but promising.
  
• Which is better for project management?
  Both GitHub and Azure DevOps have tools to help project managers. The lesser-known GitHub projects offer good project management for projects already in GitHub. Azure Boards is a mature product with over 1,000 extensions for integrating with almost any other system imaginable.
  
• Is Azure DevOps or GitHub better for CI/CD?
  Azure DevOps is more mature and integrates with GitHub repos; GitHub actions are new but promising.
  
• Which is better as a code repository?
  Code management is at the heart of GitHub. But Azure DevOps has a good code repository offering too that does almost everything you want for your projects. But for hosting code repos, GitHub is the one to beat.
  
• Is Azure DevOps or GitHub better for on-premises?
  There are self-hosted versions of both GitHub and Azure DevOps: GitHub Enterprise and Azure DevOps Server.
  
• Which has the better reputation?
  Azure DevOps came from TFS, possibly one of the Microsoft products with the biggest love/hate division amongst users. That memory lingers, whether it’s fair or not. GitHub is the default platform for a lot of DevOps tasks.

OK. But really, which is better: Azure DevOps or GitHub?

All those comparisons are well and good, but being that the two products are so similar, why have two? Part of the reason is that GitHub was becoming both a huge repository of Microsoft code and also a competitor. The popularity of GitHub still endures today and now their audience also has access more directly to the, frankly, excellent developer tools that Microsoft produces.

So, which should you choose? The non-committal answer of course is “it depends.” What kind of project are you creating? Which DevOps features do you require? Which kind of systems do you need to connect and automate?

Azure Devops Slack Message

Hopefully, you at least now have an idea of where to start and which platform to try out first. They are both excellent in different ways.

Azure Devops Slack Webhook

Ready to dive deeper? A Cloud Guru has fresh, comprehensive Azure training, including an Azure DevOps course with Microsoft MVP Henry Been.

Azure Alerts To Slack

Recommended

Get more insights, news, and assorted awesomeness around all things cloud learning.