3 ms·

> Whenever a change in any service is merged to master, the CI rebuilds _all_ the services and pushes new Docker images to our Docker registry. Why are you reb

by iamtew 9y ago

> Whenever a change in any service is merged to master, the CI rebuilds _all_ the services and pushes new Docker images to our Docker registry. Why are you rebuilding _all_ the services, wouldn't it make sense to just rebuild the ones that have changes? You're now rebuilding perfectly working services without any new changes just because some other service changed, or am I misunderstanding something here?

clintonb11 9y ago
My guess is that it is because of the mono-repo. Since it would take some work to figure out what changed and what to build, they just did it the easy way and re-build everything :-)
dhinus 9y ago
Because we want to make sure that in the Docker registry we have _all_ services tagged with the latest commit. For example you might have a Git history like this: * 89abcde Fix bug in service_b * 1234567 Initial commit including service_a and service_b When 89abcde is pushed, the CI rebuilds both service_a and service_b so we can simply "deploy 89abcde" and you always have only one hash for all services, that is also nicely the same hash of the corresponding Git commit. The trick to avoid rebuilding perfectly working services is to use Docker layer caching so that when you build service_a (that hasn't changed) Docker skips all steps and simply adds the new tag to the _existing_ Docker image. The second build for service_a should take about 1 second. In our Docker registry we end up with: service_a:1234567 service_a:89abcde service_b:1234567 service_b:89abcde But the two service_a Docker images are _the same image_, with two different tags.
- segmondy 9y ago
  Why? Microservices are suppose to be truly independent.
  - dhinus 9y ago
    For ease of deployment and to solve the problem of "what version of service_b is compatible with version x of service_a"? IMHO this makes sense if the microservices are developed by the same team. If we're talking about services developed and managed by different teams... maybe it's not a good idea.

by iamtew 9y ago

clintonb11 9y ago

My guess is that it is because of the mono-repo. Since it would take some work to figure out what changed and what to build, they just did it the easy way and re-build everything :-)

dhinus 9y ago

Because we want to make sure that in the Docker registry we have _all_ services tagged with the latest commit. For example you might have a Git history like this: * 89abcde Fix bug in service_b * 1234567 Initial commit including service_a and service_b When 89abcde is pushed, the CI rebuilds both service_a and service_b so we can simply "deploy 89abcde" and you always have only one hash for all services, that is also nicely the same hash of the corresponding Git commit. The trick to avoid rebuilding perfectly working services is to use Docker layer caching so that when you build service_a (that hasn't changed) Docker skips all steps and simply adds the new tag to the _existing_ Docker image. The second build for service_a should take about 1 second. In our Docker registry we end up with: service_a:1234567 service_a:89abcde service_b:1234567 service_b:89abcde But the two service_a Docker images are _the same image_, with two different tags.

segmondy 9y ago
Why? Microservices are suppose to be truly independent.
- dhinus 9y ago
  For ease of deployment and to solve the problem of "what version of service_b is compatible with version x of service_a"? IMHO this makes sense if the microservices are developed by the same team. If we're talking about services developed and managed by different teams... maybe it's not a good idea.