I thought about microservice architecture and wondered if people have good practice for development environments.
My working assumption is that each microservice will live in its own git repository for isolation and ease of deployment. I also assume that every developer will create the fork of any repo they are working on.
The problem that I am considering occurs where you are working on a problem related to several microservices. For example, there is a defect that affects one microservice and how it accordingly consumes another microservice.
Assuming n projects are involved in the defect, you will need to check the n git repositories and configure them to work together. If each of them has a Vagratefile and a Dockerfile, you start n virtual machines. Ideally, you will have only 1 Vagrant VM, and each serivce will be just a new Docker instance in the same virtual machine.
A master repo / project with git helper modules might work. The problem is that if we create a common repo / master project, the add-on module will point to the upstream, and not to the fork for the developer.
Currently, I think that a master project that had some configurations, roving and figs, could do the trick. I am currently considering two methods for implementing this approach.
- Provide a configuration with some default values, i.e. project_1 should be located at .. / project _id, etc.
- Provide a script that will create the submodules based on the github user account, this will create the remote user fork as well as the remote file for the upstream project.
Has anyone else solved this problem or had a good workflow?
source share