InnerSource with Azure DevOps

Developer Support

April 4th, 20201 0

This post is brought to you by Brian Blackman, Principal Consultant with Microsoft Premier Developer, focusing on all things DevOps and Developer tools such Visual Studio and unit testing as well as Eldon Gormsen, Senior Consultant with Microsoft Premier Developer, focusing on all things DevOps and more such as containers.

An introduction to InnerSource

Developers are at the core of innovation!

It’s not just your traditional competitors who recognize this. There’s a new class of competitors who are starting with disruptive software and working backwards into your industry. Think of UBER, Lyft, and Robinhood.

In a technology driven world, developers are at the heart of your company’s future innovation. Therefore, giving your developers the best tools to unleash their know-how and increase their productivity is central to your company’s success potential.

We know that innovation does not just come from great tools, you also need to facilitate collaboration and code re-use across teams as well as bring the best practices of modern software development into your organization. In doing so, you can accelerate your ability to solve problems and focus your efforts on solving new problems important to your business, versus those that have already been solved by others.

Take a look at the several practices established in foundations such as Apache Software Foundation, Linux Foundation, and Eclipse Foundation.

You want to leverage open source practices where you can benefit from open collaboration, open communication, and quality assurance through separation of contribution from integration. All artifacts such as code repositories, documentation, work items, Bugs, Issues, etc., must be accessible for all employees in your company in order to leverage InnerSource. Today we have that ability to leverage InnerSource within Microsoft. I have at least read permission to all internal projects I don’t contribute to and the ability to Fork if I want to reuse or contribute; this is a different Microsoft from twenty years ago and we love it.

An organization can adopt InnerSource even when the don’t have self-organizing teams; InnerSource allows individuals, organizational units, and project communities a higher degree of self-organization.

InnerSource projects and programs rely on open communication to make all communication openly accessible for all employees. Open communication is communication that is public (within the company), written, archived, and complete. The goal is to allow any individual or party that has stake or interest in an InnerSource project to participate in the communication.

Enabling open source culture and best practices inside your organization can result in the following possible benefits.

More efficient and effective development
- Faster Time-to-Market
- Reduced development costs
Overcoming organizational unit boundaries
- Cost and risk sharing among organizational units
- Collaboration across organizational unit boundaries
- Program-wide information exchange
More successful reuse
- Use of competences missing at component providers
- Independence between reusers and providers
- Relief of component providers
Better software product
- increased code quality
- More innovative development
More flexible utilization of developers
- Simplified developer deployment
- Collaboration of detached developers
Enhanced knowledge management
- Community-based learning
- Openness and availability of knowledge
Higher employee motivation

Encourage teams to collaborate within your organization using the same processes and practices as open source communities breaking down silos that we find are still very prevalent. You want to simplify collaboration across teams, the sharing of knowledge, improved code reuse, and secured workflows.

What successful companies have learned is that becoming digital is not just about “lift and shift” or new tools. It is about enabling your people, and Walmart is the perfect example of putting this into practice. In order to compete with Amazon, they had to change how they do business. They opened Walmart Labs and changed their organizational design—breaking down silos and creating an inner sourcing culture led by their CTO at the time, Jeremy King. They’ve also made open source a key part of their competitive strategy—with a priority on both consumption and contribution to the open source community. These cultural changes have significantly helped them compete with the Facebooks, Amazons, and Googles for top talent as well.

With all these organizational changes, they still shipped to production 14K times during October, one of their busiest times of the year. How many times do you ship per month?

Another internal antidotal example, as far as I can remember and as I understand it, the Bing team wanted a way to have reviewers automatically added to a pull request based on the path of the code under review. Of course, we said we will put it on the back log and let you know when we can do it as the developer division is highly tasked with priority work. We could not transfer developers from Bing to Azure DevOps as that would be an HR nightmare for short term. The solution was to implement Forking and accept the Bing contribution and boom a new very cool feature and a win-win for both organizations. Eldon and I were not there for all of this but that is what we learned from the Azure DevOps team some time ago; InnerSource in action.

When you embark on an InnerSource journey we suggest you look at the features of Open Source providers and what they offer. You will find that they have repositories, code reviews, work Items or Issues, boards, package management and a marketplace for extensions.

If you are using Azure DevOps then you already have all of these tools for InnerSource.

InnerSource with Azure DevOps

Azure DevOps Services and Server has the following features than enable collaboration and open communications.

Azure Boards enable connecting ideas to releases and is Scrum ready to help your teams run sprints, stand-ups, and plan your work. As well as integration (see our previous blog) with GitHub commits and pull requests. Azure Boards provide for insights into your project’s status and its overall health.

Azure Repos provide private Git and TFVC repos for your teams where they can have code reviews via branch pull requests. We support this through branch policies and build validation for pull requests. Azure Repos provide for an easy migration path to and from GitHub.

Azure Pipelines are cloud-hosted and private self-hosted pipelines for Linux, macOS and Windows. We are supporting any language, any platform, and any cloud. We also have native support for containers and Kubernetes providing a best-in-class tool for inner and open source.

With Azure Artifacts, you share code efficiently and still use your Maven, npm, NuGet and Python packages and more in one central place. Azure Artifacts can aggregate from public registries and internal teams and then publish and track from any pipeline.

With Azure DevOps Wikis, you create and organize content to learn and collaborate with your team members and stakeholders. Use the Wiki to explain project objectives, epics, specs, release notes, best practices, or other content to ensure all your team members and stakeholders learn.

How to get started

Traditionally teams have been able to contribute to projects using Pull Requests. This works great for projects that your team is working on, but what if you want to contribute to a different project that you are not part of the core team by fixing a bug or adding a feature? This is where forks can be used and is the heart of InnerSource.

The first step is to fork the repository that you want to contribute to:

Then you need to provide 1) Repository name 2) Which Project to Fork into and 3) Decided if you want all branches or just the master branch

Then click on Fork and you will have your own copy which you can now experiment as you wish. Since it is a true repo you can use any of the AzureDevOps tools (I.e pipelines, etc) as you would with any of your other repositories.

For example, let’s say you had a new idea and wanted to submit it to be included in the original repository. What you could do is simply create a new branch, start working on, experimenting with it on your forked copy of the repository. Once you are confident the feature is ready and bug free you can now contribute your idea back to the original repository via a pull request.

Now since my repository is a fork of another repository, I am given the option to open a pull request in the original repository that I fork from

So by opening the pull request this way I will have created a pull re quest in the original project. Now the team that is working on that project and review my pull request and approve it, or make comments and suggestions on changes or improvements to make and then when everything is ready they can merge my code into their code base.

You have now contributed to a project using InnerSource methodologies!

If you would like a more in-depth overview of putting InnserSource into practice with Azure Devops you can watch this presentation by Brian which he did as part of our Global Webcast – Developer Update Series. Click on this link and look for the February 2020 presentation “Developer Update Series: Integrating GitHub with Azure DevOps”

Summary

Azure DevOps provides features that enable your organization and teams adopt modern software engineering practices, such as InnerSource using features like forks and pull requests. Thus, enabling and encouraging code sharing and reuse thereby reducing engineering costs, facilitating faster time to market, and additional feature enablement.