On Fri, Sep 22, 2017 at 1:08 PM, <charles.al...@metamarkets.com> wrote:
> Hi all, > > I have a question regarding modern best practices for go repositories. As > we are building out services in go, we still have the opportunity now to > refactor the service code pretty dynamically. So now is a good time to > check and see if we're growing the repositories in a reasonable way. Our > version management system is git (github). > > There are two major routes I can see going down with regards to our > organization's go code. > > 1. All internal code is in a single repository, and any time a > developer wants to update an external dependency (ex: logrus or whatever), > they are responsible for making sure the new version works on the rest of > the code base by resolving function signature changes. This is closer to > the mono-repo workflow. > 2. All internal code resides in repositories which are split up into > much smaller components. Each service service would be its own repository > with its own build definitions, and the different "common libraries" would > have their own repositories also. Each service lazily and independently > updates their dependencies only when a dependency update is needed. This is > closer to how the common Maven/SBT (java / scala) based artifact system > works. > > Does anyone in the go community have some good suggestions or pitfalls > regarding the above approaches? Or is there a different way that is > suggested. > Today I think the best approach is still to use a single repository as in your (1), with a vendoring tool such as dep (or glide, as Steven Hartland suggested) to make a local copy of the code. Shawn Milochik pointed out that a monorepo causes extra up-front coordination to prevent or resolve merge conflicts, but that work usually has to happen one way or the other. In #2 it is just taken on as debt, and worse as debt that may not be obvious at the time. Front-loading the coordination can help avoid taking on too much of this debt. In the longer term we hope to provide better tooling around all of this, but it's not ready yet. Russ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
