¿Cómo especificar las dependencies de la twig entre la API y el front-end para las testings de integración?

Tenemos una aplicación angular respaldada por una API de Rails. El código angular y el código de Rails viven en repositorys separados. Cuando construimos nuevas características usamos twigs de características, por lo que podríamos tener, por ejemplo

angular/foobar

Dependiendo de

rails/foobar

¿Cómo podemos decirle a Travis que angular/foobar depende de rails/foobar cuando se ejecutan testings de integración?

En términos más generales, ¿existe una forma mejor de ejecutar testings de integración en front-end y repositorys API que lo que estamos considerando? Esto tiene que ser un problema resuelto, pero no he encontrado nada que sea de mucha ayuda.

El desarrollo API / UI a través de repos múltiples no es un problema resuelto, y todas las gotas de sabiduría son más que bienvenidas.

En cuanto a mí, esto es lo que recomiendo: siempre desarrollar en el lado de la interfaz de usuario contra la twig master API (o cualquier twig que considere su twig base).

La idea detrás de esto es: los cambios en la API se deben hacer primero antes de implementar nuevas funciones de la interfaz de usuario dependiendo de estos cambios. Asegúrese de que los cambios en la API no rompan la versión real de la interfaz de usuario (su UI master o twig base).

En este punto, su cliente de UI real aún funciona con los nuevos cambios de API. Ahora es el momento de comenzar a trabajar en la interfaz de usuario.

Este flujo de trabajo también ayudará en el process de implementación, ya que sabe que podrá implementar primero la API y luego solicitará a los usuarios que actualicen la aplicación.

Traté de mantener mi respuesta simple por el simple hecho de ser breve, pero espero que esto ayude.