¿Qué flujo de trabajo de scm (git) funciona bien cuando se desarrollan services múltiples? (SOA)

Estamos a punto de comenzar a dividir nuestra aplicación web en múltiples services, cada uno de los cuales es su propio repository. Usamos git como nuestra scm y me pregunto si alguien tiene alguna recomendación para un flujo de trabajo para nuestra scm (en este caso, git).

En este momento, utilizamos un flujo de trabajo similar al que se muestra aquí: http://nvie.com/posts/a-successful-git-branching-model/ .

Me gustaría pasar a un model más simple, como el funcionamiento de Github: http://scottchacon.com/2011/08/31/github-flow.html . ¿Es esto factible para desarrollar SOA?

Curioso en cuanto a si alguien tiene una opinión sobre esto. Gracias.

El flujo de Github relaciona las twigs de características con un solo producto, pero no hay ninguna razón para que no pueda implementarse. Sus opciones de flujo de trabajo dependen de cómo deployment su aplicación. Considere "MyApp", que tiene tres services componentes:

MyApp |- ServiceA |- ServiceB |- ServiceC 

Si puede implementar ServiceA independientemente de ServiceB y ServiceC y, lo que es más importante, implementarlos independientemente del código que contiene MyApp pero que no existe en ninguno de los repositorys de Service* , simplemente aplique el flujo de Github, su flujo de trabajo preferido, a cada repository y equipo .

Si los services están estrechamente entrelazados, y la implementación de ServiceA necesariamente requiere una implementación de ServiceB o, lo que es más importante, MyApp representa una porción significativa de andamios o código de routing que debe avanzar cada vez que uno de los Services* repos hace, entonces es posible que desee algo como submodules o subtree . En ese model, tendría un flujo Github y un paso adicional entre el # 4 y el # 5, es decir, la recostackción de actualizaciones de submodules (o subtreees) para los services antes de la implementación. Evitaría la anidación de repositorys sin subtreees o submodules, a less que usted (y su equipo) lo supieran muy bien.

Una vez escrito todo, sugiero que analice en profundidad sus motivaciones para dividir la aplicación. Tiene ventajas y flujos de trabajo exitosos, pero tienen un costo: es más difícil get una "image completa" de su historial; en determinadas circunstancias puede ser más difícil depurar con herramientas como git bisect ; cada nuevo desarrollador tiene que aprender su infraestructura de git antes de que pueda sentirse cómodo trabajando en su base de código. Estas no son razones para abandonar su plan, solo para pensar.

Usted querría que cada repository de sus services tenga un submodule que apunte a su repository de posts o contratos. Este repository haría cumplir un model solo aditivo. Esto significa que una vez que se ha publicado un post o contrato, no se puede borrar. Simplemente puede agregar una nueva versión del masaje y dejar de usar el anterior. Esto le permite tener implementaciones incrementales.