4 ms·
People have been building multiple applications from a single codebase for a very long time. Put all the targets on a continuous build, add tests, and you're se
by aboodman 11y ago
People have been building multiple applications from a single codebase for a very long time. Put all the targets on a continuous build, add tests, and you're set.
The only sense in which versioning matters at all is that if the protocol the applications talk to each other over has to be versioned, and an application must understand the oldest version of the protocol they could potentially be spoken to over.
But things like Thrift and Protocol Buffers have this feature built in. You shouldn't need to version the actual code...
- AdrianRossouw 11y agothe question is about building an application that is easier to split into microservices later. it all comes down to this - http://www.infoq.com/news/2015/01/microservices-sharing-code http://www.infoq.com/news/2015/01/microservices-sharing-code If you have multiple components that are depending on the same code, if you try to split them into multiple services that are being independently deployed, you need to keep the code they are depending on in sync. So making a change to the code shared by multiple services, means you have to deploy multiple services for a single change. I completely agree with you about the protobuf/thrift angle though. If you're in that situation, you are already doing it right.