New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feedback] Projects in multiple repositories #86

Closed
atrauzzi opened this Issue Mar 7, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@atrauzzi
Copy link

atrauzzi commented Mar 7, 2017

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

This comment has been minimized.

Copy link
Collaborator

CESARDELATORRE commented Mar 7, 2017

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! :)

@CESARDELATORRE CESARDELATORRE self-assigned this Mar 7, 2017

@atrauzzi

This comment has been minimized.

Copy link

atrauzzi commented Mar 7, 2017

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

This comment has been minimized.

Copy link
Collaborator

CESARDELATORRE commented Mar 7, 2017

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

@jbogard

This comment has been minimized.

Copy link
Collaborator

jbogard commented Mar 7, 2017

@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

This comment has been minimized.

Copy link
Collaborator

CESARDELATORRE commented Mar 7, 2017

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.

@CESARDELATORRE CESARDELATORRE changed the title Projects in multiple repositories [Feedback] Projects in multiple repositories Mar 8, 2017

@MichaCo

This comment has been minimized.

Copy link

MichaCo commented Mar 26, 2017

@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

This comment has been minimized.

Copy link
Collaborator

ardalis commented Mar 26, 2017

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

@atrauzzi

This comment has been minimized.

Copy link

atrauzzi commented Mar 26, 2017

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

This comment has been minimized.

Copy link
Collaborator

CESARDELATORRE commented Mar 26, 2017

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

This comment has been minimized.

Copy link
Collaborator

mvelosop commented Apr 3, 2018

Closing this as the conversation can be considered finished!

@mvelosop mvelosop closed this Apr 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment