toggle quoted messageShow quoted text
My second point was about just breaking the compilation. Some
module not compiling because of changes in another repo.
On 18/12/17 16:01, Jeremy Phelps wrote:
These are actually all really good points, I appreciate
you bringing them up. I agree that we need to discuss
this as there are some cases where it could cause us
For example...if the dependencies are vendored is there a
way to pin to a specific version?
1) Each time a repo changes we all will need to update the
vendor folder manually. I think it will be wearisome and
Not only that but how do we manage different versions
under vendoring...there may be a case where the vendored
code will be a release branch and not the tip of master for
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.
This is not a unique problem in this case I think. This
is just an issue with mico-services in general. We can lessen
the impact by strict adherence to sematic versioning and some
smoke tests before we kick off blackbox-testing.
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.
I think this is what blackbox-testing would cover no?