I was thinking about the micro services architecture and wondering if folks have a good best practice for development environments.
My working assumption is that each micro service will live in it's own git repository for isolation and ease of deployment. I'm also assuming that each developer will create a fork of any repo that they are working on.
The issue I'm considering arises where you are working on an issue that involves multiple micro-services. For example, there is a defect that impacts one micro service and how it appropriately consumes another micro-service.
Assuming n projects are involved in the defect, you would have to check out n git repositories and configure them to work together. If they each have a Vagratefile and Dockerfile, you end up running n VMs. Ideally you'd only have 1 Vagrant VM and each serivce would just be a new Docker instance in that same VM.
A master repo/project with git sub modules could work. The problem with that is if we create a generic master repo/project then the sub module will point to the upstream not the fork for the developer.
I'm currently thinking that a master project that had some configs, vagrant and fig might do the trick. I'm currently considering two methods of implementing this approach.
- Provide a config with some defaults i.e. project_1 should be located at ../project_id, etc
- Provide a script that will create submodules based on the user's github account, this would create the remote for the user's fork as well as the remote for the upstream project.
Has anybody else solved this problem or have a good workflow?