Despliegue parcial usando comstackciones VSTS – estrategia de control de origen

Estoy construyendo una línea de construcción de VSTS para continuar la integración y la implementación de un proyecto web de MVC. Mi cliente quiere 0 time de inactividad en caso de continuar la implementación, por lo que hemos considerado reestructurar la estrategia de control de origen y dividir el repository de código único en los siguientes:

Funciones principales

  1. Característica 1
  2. Característica 2 …..
  3. Característica n

Estamos planeando mantener las características como sucursales secundarias de la function Core y colocar templates de compilation individuales para cada una de las twigs y subdirecciones. Por lo tanto, el escenario ideal es que si hay algún cambio en la twig de características principales, la compilation debe implementarse con código completo (twig + subdirecciones) pero si solo se cambia una twig de function, la implementación continua solo se ejecutará para esa twig o la característica en la twig.

Entonces las preguntas que necesitan alguna orientación son:

  • ¿La idea de la function de ramificación es buena y se puede usar en producción?
  • La aplicación .Net MVC es una aplicación de n niveles que tiene niveles de web, service y niveles de repository. ¿Debo dividir las capas de service y repository también en el núcleo y las twigs de características para separarlo?
  • Si dividiera el service y el repository, ¿cómo debería ocurrir la comunicación entre las diferentes características?

  • A través del service al service de llamadas? Al igual que si la function 1 requiere alguna funcionalidad de la function 2, las llamadas de service de la function 1 ofrecen service 2 y fusionan el resultado para enviarlo a la function 1 GUI?

  • Las llamadas a la característica 1 del repository tienen 2 repositorys, pero este enfoque hará que la dependencia de la function 1 en la característica 2 signifique que si la function 2 está desactivada en el momento de la implementación, la característica 1 también es un error de experiencia.

  • ¿Divide el repository en varias características es una buena idea?

Gracias

Dividir el repository en varias características está bien, ya que podrían usarse en otras aplicaciones (por ejemplo, aplicaciones mobilees)

Recomiendo que pueda considerar la característica de packages VSTS u otra alimentación del tercer package. El flujo de trabajo:

  1. Empuje los cambios al server> Desencadenar la creación de CI> Empaquetar y publicar el package en la fuente VSTS mediante la tarea NuGet
  2. Instale los packages necesarios para el proyecto web y la encoding.
  3. Empujar los cambios del proyecto web al server> Disparar la creación de CI con el package instalado actual (No actualizar el package)
  4. Actualice el package necesario para el proyecto web para la nueva característica
  5. Empujar los cambios del proyecto web al server> Disparar la creación de CI