Reevaluate setup concept

[BerndNK]

Our current concept is difficult to understand and not thought out well enough. Example:
Suppose an Azure DevOps collection called "CollectionA".
In this collection there are 3 builds and 2 repositories.

Build definitions:

• Backend.CI
• Backend.Shared
• Frontend.CD

Repositories:

• Backend
• Frontend

Both "Backend.*" definitions build code from the "Backend" repository, while the "Frontend.CD" build, builds code from the "Frontend" repository.

In BuildNotifications, you would setup 3 connections and 2 projects for this:

1. Build connection for the whole collection (including ALL build definitions)
2. Source connection for "Backend" repository
3. Source connection for "Frontend" repository
4. Project with the build connection and the "Backend" source connection
5. Project with the build connection and the "Frontend" source connection

Side note: In the current state of the app, you have to additionally setup black-/whitelists for the projects, as even "Frontend" builds are listed in the "Backend" project. This, however, is a different bug that is not directly relevant to this issue.

Proposed changes

I suppose we restructure the setup view and our concept by

• Removing build/source differentiation from connections
• Adding differentiation of build/source to projects (select within a project for which purpose a connection shall be used)
• Allowing multiple source provider for a single project
• Adding repository black-/whitelist to projects

Desired results

• Reduce friction for first time users, as it is way clearer to setup a single connection first and then specify what to use from that connection.
• Remove redundant input, which was always a result of the source/build differentiation on connection level.
• Give the use the freedom to group all of his builds from a build connection into one project OR have one project per repository/definition/builds via black-/whitelists.

My main argument is, that you have to configure way to much if you have a simple Azure DevOps setup. With the proposed changes, this is the setup you would have to do, given the same example as described above:

1. Azure DevOps connection
2. Project using the DevOps connection as both build and source provider

While still allowing the same complexity as before.

[BerndNK]

What do you think @TheSylence ?