One Project To Rule Them All

Development Consultant Emmanuel Knafo explores the business value of having a single organization, single project approach to DevOps.

In this 3-part series, we will discuss the business value of having a single organization, single project approach in your Azure DevOps journey.

Why a single project approach you ask? Usually, organizations or enterprises start their Azure DevOps journey in one of two ways:

1. A migration from pre-existing on-premise Azure DevOps Server (aka Team Foundation Server) project collection(s). This is usually done using High Fidelity tools such as the TFS Migrator Tool.
2. Organically: meaning the organization or enterprise initially creates an Azure DevOps Organization with a project in it. Sooner or later, the need is felt to add more projects to this initial ADO organization or even create supplementary ADO organizations to house additional projects.

Part 1 of the series examines the business value of taking a single organization, single project approach in your Azure DevOps journey.

Part 2 of the series examines the fundamental techniques used in the Migration Tool which allows us to clone, and more importantly merge, multiple Azure DevOps projects into a single project.

Part 3 of this series takes a look at Security consideration and techniques. Security Requirements can vary widely from one enterprise to another. Under certain circumstances, it may even be a reason to deviate from the “One Project To Rule Them All” strategy and add another project.