Eshoponcontainers: [Feedback] Projects in multiple repositories

[atrauzzi]

I'm interested in hearing more about or engaging in a discussion about conventions and advice around projects that are spread across multiple git repositories.

Currently the solution model guides people to keep all their code in a single repository. I'm wondering however if there's anything in VS2017 and the project system that would allow me to aggregate multiple source repositories with projects, processes and deliverables together under a single editor and UI experience.

[CESARDELATORRE]

Good point about multiple source/Git repos.
From .NET Core code and Docker point of view, in a large project I would certainly recommend that approach as each microservice might surely be autonomous, owned and evolved by a different development team, so independent Git repos fits better in large projects.
From a tooling point of view in VS 2017, the Docker Tools team is researching that approach as well. I can put you in contact with Steve Lasker if you'd like further engagement about it.
In regards this sample application, this is an easy to get started sample to introduce developers to containers and microservices, it is not large enough to have it split in multiple Git repositories and would make it too complex for folks getting started.
Thanks for pointing it out and remind me about this scenario. I'm going to include a section about it in the Guide/eBook discussing possible approaches for this.
Thanks a lot for your good feedback! :)

[atrauzzi]

Yes, very interested as I have some scenarios and approaches I'd like to share. And yeah, it totally involves docker containers, except from a nodejs application, not .net core (although some of my concerns still apply in dockerized .net core apps).

[CESARDELATORRE]

Please, send me your email address to cesardl at microsoft.com or [email protected] and I will start an offline thread with Steve Lasker (VS Docker tooling team) about what you'd like to share, ok? :)

[jbogard]

@CESARDELATORRE that's absolutely what we see in larger teams, each team owns its own pipeline and we strongly discourage git submodules or monolith repositories. It enforces autonomy, and probably more important, discourages the "works on my machine because everything is localhost" problems that people can run into.

[CESARDELATORRE]

Yes, I completely agree. We're starting a thread with Steve Lasker (VS Docker Tooling) and Alexander.
Jimmy, would you also like to be engaged and discuss about this subject?

I will include this approach into the Guide/eBook. However, for this initial small microservices application for learning purposes on containers/microservices I think it would be kind of overkill. At least for this version. When evolving and growing the sample, we might want to split it.
I'm, however, eager to know more about your experiences on this approach.

[MichaCo]

@CESARDELATORRE I have to agree with @jbogard and @atrauzzi. Real world solutions will have many solutions (if the team uses Visual Studio). Those solutions might be on Github or TFS or what not. But clearly not one large solution.
It might be easier to start with, but you just ignore the fact that you'll run into certain issues when splitting this solution down into dedicated parts.

• Shared code for example, is it a shared nuget? What about different versions of that each service might use one day? Same for service clients?
• You are not going to deploy all services together anymore.
• etc..

My team is currently building an new application with Microservices on .NET Core. We started with separated projects from the beginning.
Sure, its harder to get started, but if you want to build Microservices, you should probably not start with a monolith in the first place ;)

I'm eager to hear what you guys discussed.

Thanks
m

[ardalis]

I agree and have found Nuget packages to be the best way to share dependencies between solutions.

[atrauzzi]

I suspect @SteveLasker kept better notes than me for the call. The general gist was that I spoke a little about some of my issues with multi-repository strategies.

With VS 2015, setting up a parent "omni project" wasn't really easy because nuget got messed up on a lot of paths. Beyond that, I worry that Visual Studio is just too stateful to offer a solid developer experience with such a scenario.
I still want to, but I haven't tried the same again with 2017 as it takes so much time & effort to set up. With many other more sure things on my plate, I'm sure anyone can appreciate that editing a bunch of csproj files for a weekend, manually resolving path errors and other issues just doesn't scream _priority_.

The next detail is to do with running mixed projects. We spoke a bit about the docker and the compose support that exists at the solution level in VS2017. That could be useful for running other services that aren't based on VS project structures as it just plugs right into the yml format.

After spending more time thinking about that approach though, I realized the true problem: Any desire to have Visual Studio responsible for bootstrapping your local environment - rather obviously - constrains you to thereafter always be running Visual Studio.
I'm putting it that way because the truth is that Visual Studio may not always have the best editor experience for every aspect of most microservice architectures. Sure, for .NET Core, it's a shoe in. But even TypeScript editing is better in WebStorm right now.

Perhaps if a whole release or update cycle was spent focus grouping the heck out of it, this story could be improved. I think I'm coming to a better understanding now that mixed, multi-repository projects from within Visual Studio just isn't realistic to expect.

Now that all this understanding has had a chance to settle in my brain, I actually think there's an opportunity here for a very interesting new product...

✏️

[CESARDELATORRE]

I agree, real world solutions will have many solutions (if the team uses Visual Studio) one per autonomous development and deployment microservice and each solution would be stored in a different Git repo managed by potentially a different team, like a Bounded-Context in that regard.
However, this is a sample application for introducing microservices and containers to devs who are not familiar to Docker containers and microservices. We need to balance the solution in some cases favoring an easy to get started environment. If we set this up based on 10 GitHub repos and 8 or more different deployment procedures, not many devs will follow it due to the complexity to get it started.

The important rule is that each microservice must be independent in regards development and data, plus being able to be deployed autonomously. The microservices in eShopOnContainers are independent projects, no code shared across microservices (except libraries of re-usable building blocks like the "Service Bus" library that should be managed through NuGet packages in the same way that you re-use newtonsoft.com/json or any other lib) and they do have or own independent databases, one per microservice.
For a real world scenario, sure, I agree, you should take each of the microservice projects and put it in a different Git repo and deploy it with a smaller docker-compose.yml that would be related just to that specific container/microservice (you just need to take that part of the yml code).
Our current architecture/design supports that approach because the eShopOnContainers microservices are autonomous.
As mentioned above, the setup procedure to set up the whole application up and running if having 8 or more different Git repos and solutions would be too complex or time consuming for anyone new to containers and microservices.

[mvelosop]

Closing this as the conversation can be considered finished!