GitHub Enterprise for the Azure DevOps User - Part I Organization Configuration

With Microsoft buying GitHub in 2018, Microsoft now has two of the most popular team development productivity tools with GitHub and Azure DevOps.  GitHub is obviously hugely popular with open source software (OSS) projects. As an experienced user of Azure DevOps (and previous versions/names) since 2005 and Azure DevOps Microsoft MVP, I hadn't thought about using GitHub for enterprises until recently learning more about GitHub Enterprise (GHE).  I am using this series of posts to go through the functionality of GHE and how it compares to Azure DevOps to help come up with my own conclusions on when each tool is the right tool to use and how these two tools can be used together. I'm going to break this into multiple parts to cover some of the areas in detail like boards/issues, repos, and pipelines.

Part 1 - Organization Configuration

In part one, I am going to focus on the initial experience and how to configure GHE for an organization.   This will go through the capabilities for organizing teams, projects, and repos while comparing it to the experience in Azure DevOps.

What is GitHub Enterprise (GHE)?

GitHub offers several plans.  The Enterprise plan supports key features that an enterprise organization would need.  These include features like using existing user accounts with LDAP, SSO (SAML), and auditing to name a few.

Here is a full comparison of the plans. In addition, GHE supports on-prem, cloud, and hybrid (connecting on-prem to cloud) deployments. The on-prem and cloud offering options are similar to the Azure DevOps deployment options but I'll discuss the hybrid option in a future post.

I have worked with many organizations to help configure Azure DevOps and all of the variants/names over the years.  The features and services in Azure DevOps are feature rich for managing work from requirements to production.  However one challenge can be configuring Azure DevOps to support multiple teams that work on one or more products that roll up to the program and portfolio levels.   Setup and configuration decisions and tradeoffs are made based on how team projects are configured.  I was curious to see if any of this is supported in GHE and how it is implemented.

Organizations

In GHE, the primary container is called an Organization. A single organization can hold all of your organization's assets. The name and intent are consistent with Azure DevOps.

In Azure DevOps, the Organization is primarily a container for Projects (Team Projects) and almost everything else is contained within the project.  The project is the container for permanent/product based artifacts like repos, teams, and pipelines and project specific artifacts like the requirements and other work items for a project.  This has led many to configure Azure DevOps using a single team project or the entire organization but this approach also has some drawbacks.

In GHE, there are projects, teams, and repos that are configured at the organization level.  This allows more flexibility in the tool to support different enterprise organizational structures.  Scenarios like multiple teams to work on a project with repos that are included with a project are easily supported.  GHE is more flexible than the organizational configuration options in Azure DevOps.

Projects

Projects are created at the organizational level.  This is great because it can give you a list of all of your projects.  When you create a new project, you can choose from a list of templates.

I chose the Basic Kanban template for now and will go through these options in more detail in the next post.  I had two repos that are needed for this project and I was able to link these to the project.  

I like this because most projects will affect one or more products or applications that live in repos.  Once the project is created I'm taken to the board.  I didn't know GitHub had a Kanban board view.  I'm excited to investigate this more in my next post, Part 2 - The Boards.

Teams

Every organization has teams.  With GHE, teams can be set up to represent each of these teams in your organization.  In addition, teams can have parents so you can create a hierarchy of teams to match your organizational structure.

This also provides navigation throughout the organization.

This is something we can set up in Azure DevOps with the use of Area Paths and/or Iteration Paths however the Teams view is flat and every team sees every team in the team selection menus.  Favorites does provide a way.  One thing I really like about Azure DevOps is how that allows work to rollup so we can see how the organization is doing from the program and portfolio levels.  In my next post, I'll see if work can be organized and viewed by parent teams.  Within a team, you can have discussions.  These discussions can be private to the team or visible across the organization.

A team can be assigned to zero to many projects.  This is great because there are scenarios where it is one team working on one project, one team working on multiple projects, and multiple teams working one on project.  All of these scenarios can be supported with this.  In this model, the repos for the team are linked through the project.  Repos can also be linked directly to the team.  This could be useful for teams that are not  part of a project like a support team that may have to make fixes to multiple repos.  However, I would think a support team would still want a project Kanban board to work from.  In a future post on the developer experience, I'll find out if there are any advantages to a team additionally linking to repo.

Marketplace

Both GitHub and Azure DevOps offer marketplaces to provide additional functionality to the platforms and integration to other tools.  We use several extensions in Azure DevOps such as Estimate and Retrospective.  I searched the GitHub Marketplace and found comparable options.  I'll dive deeper into this more in a post of Azure DevOps / GHE hybrid use.

Thoughts and First Impression

I was very impressed configuring GHE for the first time.  I had some misconceptions about GitHub.  I hadn't thought of GitHub as being enterprise friendly and didn't know it had capabilities beyond rich features to support issues and repos that I had used with open source projects.  I really like how GHE can be configured for an enterprise. I'm excited to keep investigating the other areas like the project boards in my next post and the developer experience in the following post.

Additional Posts

‍GitHub Enterprise for the Azure DevOps User Part 2 - The Boards