Re: go repos concerns

Drasko DRASKOVIC <drasko.draskovic@...>
 

Hi Fede,
this was the layout I was proposing from the start for Go rewrite -
this is what I was referring to when I said "monorepo". A single repo
would hold all the EdgeX code, separated in independent services that
live in different directories. We did the same thing with Mainflux -
which in the beginning had separate repos, and now all services are
live in one repo with identical structure:
https://github.com/Mainflux/mainflux. The result was significant
simplification of development and maintaining process.

Monorepo would simplify CI, testing and would keep overall project
code more consistent. I support the idea.

Best regards,
Drasko

On Mon, Dec 18, 2017 at 3:40 PM, Fede Claramonte
<fclaramonte@...> wrote:
Hi all,

First of all I want to thank Dell for the initial go code for the core
microservices. Good work.

I have been learning about the core Go code and I have some concerns about
the layout of the code on different repositories.

We have several repos, each one with one different edgex module or lib. Each
repo uses glide to vendor all dependencies, including the other edgex
modules. So we have the same code copied over all the repositories in the
vendor folder(e.g. core-domain-go, support-domain-go). My concerns:

1) Each time a repo changes we all will need to update the vendor folder
manually. I think it will be wearisome and error-prone.

2) Another problem is to know if a change in any module (e.g.
core-domain-go) breaks some other module. We will need to manually compile
all the dependent modules to make sure we will not break any other module.

3) Previous point will be also influence how CI is implemented, it will need
to launch several jobs after a change to test if it breaks some other
module.

On the other hand we have the layout Drasko set up for export services. It
contains all the needed code to compile several microservices and it is
trivial to know when any change breaks some other module in the repo.

I would propose to use something similar to what Drasko did, i.e. having
all/most of the edgex Go code in only one repo as follows:

edgex-go
├── cmd // The main file for each microservice in each
folder
│ ├── core-data
│ ├── core-metadata
│ ├── export-client
│ ├── export-distro
│ └── support-logging
├── core // core-domain-go
│ ├── clients // core-clients-go
│ ├── data // core-data-go
│ └── metadata // core-metadata-go
├── device // Device helplers
│ └── virtual // device virtual
├── dockerfiles
├── export // The export repository
│ ├── client
│ └── distro
└── support // support-domain-go
└── logging

With this layout it will be easier to work with the code, all in only one
repo. After changing something in edgex-go/core/XXX.go you just need to
build and run the tests locally to know if the change breaks something. This
is also a lot easier for CI, as there is no dependencies between different
repos.

Opinions?

Fede

_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang

Join EdgeX-GoLang@lists.edgexfoundry.org to automatically receive all group messages.