Control de versiones vs. distribución automática vs. administración de dependencies

Imagine un sistema de software distribuido, instalado en un grupo de unos pocos cientos de computadoras (nodos). Los nodos son responsables de ejecutar automáticamente las tareas progtwigdas. Hay cientos de tareas, y cada tarea está progtwigda para ejecutarse en aproximadamente 5-10 nodos. Los nodos pueden detenerse durante días y pueden ser eliminados del sistema. Cada tarea está definida por uno o más files fuente y files de configuration específicos del nodo. El código se desarrolla y testing directamente en los nodos (usando acceso remoto), ya que solo estos están equipados con el hardware especial y tienen el context de networking requerido para ejecutar las tareas (build un sistema de testing separado sería demasiado caro). Los files de origen de cada tarea se refieren a files de origen compartido (bibliotecas) y las bibliotecas pueden hacer reference a otras bibliotecas. El tree de dependencies de tareas y bibliotecas es complicado.

No tengo ninguna experiencia con los sistemas de control de versiones distribuidas , pero creo que este sistema podría buildse en torno a un DVCS. Diferentes bibliotecas y files fuente de diferentes tareas tendrían su propio repository. Cada nodo que ejecuta una tarea determinada debe tener una instancia del repository de esa tarea. El repository de cada biblioteca, utilizado por al less una tarea de un nodo, también debe estar presente en ese nodo. Los desarrolladores modificarían y commit código localmente en los nodos, y distribuirían las modificaciones a repositorys en otros nodos usando técnicas DVCS.

Pregunta n. ° 1 ¿Cuál sería el mejor enfoque para distribuir los cambios de código a otros nodos?

Algunos escenarios posibles:

  1. Los desarrolladores push sus modificaciones a cada otro nodo que tenga una instancia del mismo repository. (Pero pueden olvidar / no tienen time para hacerlo).
  2. Los nodos extraen automáticamente cada cambio de todos los repositorys remotos y se update automáticamente. (Pero puede haber conflictos)
  3. Para cada repository, una de las instancias se usa como una "reference". Los desarrolladores push sus modificaciones a esta instancia, y cada otro nodo que tiene una instancia pull automáticamente s desde aquí y update s mismo. (Pero el nodo que tiene la instancia de reference puede detenerse)

Pregunta # 2 ¿Cuál sería la mejor manera de manejar las dependencies?

Si más de una tarea (o biblioteca) se refiere a la misma biblioteca, y la biblioteca referida tiene que ser modificada, una o más tareas de reference (o bibliotecas) pueden dejar de funcionar ( infierno de dependencia ). Sería mejor seguir con la versión referida originalmente y actualizar a la nueva después de las testings adecuadas. Es decir, más de una versión del mismo file fuente debe estar presente en el mismo repository, lo que no parece posible. ¿Tengo que crear una nueva branch para la nueva versión de la biblioteca referida? En caso afirmativo, ¿cómo debo actualizar los repos de reference?

Gracias por tu ayuda.

No tengo ninguna experiencia con los sistemas de control de versiones distribuidas, pero creo que este sistema podría buildse en torno a un DVCS.

Sentimiento equivocado, en común. VCS (SCM) es el sistema de control de versiones (gestión de control de fuente), es decir, la pista

  • cambios
  • en aspecto histórico principalmente
  • como una matriz plana sin dependencies complejas (algunas dependencies aún se tienen en count)

Debe ver en otra categoría de herramientas, el software de gestión de configuration , que maneja deployments, políticas, dependencies complejas, condiciones, etc. de forma nativa.

Puede get alguna iteración a CM con DVCS, pero será un trabajo duro y una apariencia pálida de herramientas existentes bien establecidas como resultado