Azure DevOps, canalizaciones de lanzamiento de YAML? [cerrado]

85

Estoy siguiendo este proceso para crear una canalización de compilación YAML para un proyecto de API web de .NET Core:

https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started-yaml?view=vsts

Cuando se trata de lanzarlo, observo que Azure DevOps (recientemente renombrado) no parece ser compatible con YAML para definir las canalizaciones de lanzamiento. Sin embargo, puedo ver que se han definido las tareas de implementación, por ejemplo:

https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-rm-web-app-deployment?view=vsts

¿Esperamos una actualización de la funcionalidad de canalizaciones de versiones para admitir YAML y, de ser así, cuándo?

Michael12345
fuente
Pronto, en Build 2019: youtube.com/watch?v=ORy3OeqLZlE Pipelines de múltiples etapas (y Release YAML) ahora están en vista previa. Habilítelo en el elemento de menú Funciones de vista previa.
nullforce
2
¿Alguien podría ayudarme a entender por qué esta pregunta está fuera de tema? Para mí, parece una buena pregunta para stackoverflow.
Tobske

Respuestas:

58

En el momento de redactar esta respuesta, la cronología de las funciones refleja que los lanzamientos de yaml llegarán al tercer trimestre de 2018.

https://docs.microsoft.com/en-us/azure/devops/release-notes/

Actualización: esto se ha golpeado varias veces. Se recomienda consultar los comentarios a continuación, ya que la gente ha estado proporcionando actualizaciones a medida que las encuentran.

Actualizar

Según los comentarios, esto ahora es posible: https://devblogs.microsoft.com/devops/whats-new-with-azure-pipelines/ . Lo siguiente se copia y pega del artículo y demuestra el uso de varias etapas:

stages:
- stage: Build
  jobs:
  - job: Build
    pool:
      vmImage: 'Ubuntu-16.04'
    continueOnError: true
    steps:
    - script: echo my first build job
- stage: Deploy
  jobs:
    # track deployments on the environment
  - deployment: DeployWeb
    pool:
      vmImage: 'Ubuntu-16.04'
    # creates an environment if it doesn’t exist
    environment: 'smarthotel-dev'
    strategy:
      # default deployment strategy
      runOnce:
        deploy:
          steps:
          - script: echo my first deployment
Justin Holbrook
fuente
9
Ahora está en las características del cuarto trimestre de 2018.
sschoof
4
Hay un elemento de trabajo para rastrear este dev.azure.com/mseng/Azure%20DevOps%20Roadmap/_workitems/edit/…
sschoof
6
Me comuniqué a través de Twitter ayer. Las definiciones de lanzamiento de YAML se están trabajando en este momento con el objetivo de que entre en vista previa privada a fines de marzo. Hilo completo en twitter.com/gopinach/status/1088320931745935360?s=21
rh072005
5
Último elemento de trabajo que rastrea esto: dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1364226
antmeehan
10
¡finalmente! devblogs.microsoft.com/devops/whats-new-with-azure-pipelines 7 de mayo de 2019
Kat Lim Ruiz
6

La experiencia de creación de canalizaciones de compilación YAML está en versión preliminar. (hoy es 2018-12-04)

YAML para los pipelines de lanzamiento parece estar aún muy lejos: 2019 Q2

Las funciones de vista previa se pueden habilitar desde su perfil de esta manera:

menú de perfil

Función YAML

EDITAR: como señala nullforce en los comentarios, esto solo habilita una experiencia YAML para construir canalizaciones y no lanzar canalizaciones.

ACTUALIZACIÓN (2019-05-16): Siguiendo la "Build 2019" de Microsoft, la experiencia YAML completa tanto para la compilación como para la implementación ahora debería ser posible en el mismo archivo de canalizaciones YAML.

Jim Wolff
fuente
3
Esta pregunta se refiere a las canalizaciones de lanzamiento, no a las canalizaciones de compilación. La función de vista previa que indicó solo activa la canalización de compilación YAML.
nullforce
@nullforce Gracias, agregué su corrección a mi respuesta e intentaré mantenerla actualizada si está habilitada para las canalizaciones de versiones o cuando yaml también sale de la vista previa.
Jim Wolff
1
Aún no está disponible.
ATL_DEV
@ATL_DEV ¿podría explicar un estado o un enlace a recursos relacionados con esto, para que pueda corregir la respuesta? Para mí, parece que está disponible: documentos
Jim Wolff
@Jim Wolff-- ¡Microsoft son unos mentirosos! Las partes de lanzamiento e implementación solo se pueden configurar a través de su interfaz de usuario de mierda.
ATL_DEV
5

El equipo de producto está trabajando en ello. Puede realizar un seguimiento de la actualización a través de las notas de la versión .

starian chen-MSFT
fuente
1
"El equipo de producto" no ha hecho nada después de 1 año. La interfaz de usuario de Azure Dev Ops sigue siendo horrible y la compatibilidad con yaml para la implementación sigue sin aparecer a pesar de todas las promesas vacías. La documentación es inexistente y se encuentra dispersa por toda la red, ¡Azure Dev Ops es muy fácil de usar! Microsoft debería encontrar algo más que hacer
ATL_DEV
Solo por el bien de la precisión técnica, a pesar de que ese comentario se publicó en noviembre de 2019 y decía que el soporte de YAML para la implementación "todavía no está allí", en realidad se agregó a Azure DevOps (sin espacio) en mayo de 2019. Otras respuestas y los comentarios se adentran más en esto. Solo quería asegurarme de que alguien que lea esto tenga una idea equivocada.
MikeBaz - MSFT
4

Estoy en medio de hacer algo como esto en este mismo momento, pero estoy usando las API REST actuales. Lo que estoy haciendo es algo similar a lo que documenté aquí ( ¿Cómo se importa una definición de lanzamiento en VSTS? ). Básicamente, estoy guardando un archivo JSON Release Pipeline con plantilla en el repositorio de código fuente con marcadores de posición variables y un número de versión incrustado. A continuación, tenga un script de PowerShell que llame a Azure DevOps (esa es una palabra larga, preferí escribir VSTS, tal vez empiece a escribir AD)

  • Existe una API REST para verificar el canal de lanzamiento - funciona
  • Crear si no existe - funciona
  • Compare las versiones integradas y actualice y, si es necesario (estoy atascado aquí, pero lo resolveré, devolviendo el error de que la canalización que se está actualizando no ha cambiado aunque la haya cambiado)

Quiero que esto se ejecute durante la canalización de compilación para que ya no tenga que modificar manualmente muchas canalizaciones de versiones similares. Preferiría que este también fuera un archivo YAML, pero esto es lo que tengo hoy. Espero que esto ayude.

Antebios
fuente
1
Estoy atascado y he detenido mi esfuerzo laboral en el proceso de ACTUALIZACIÓN. ¿Por qué? La plantilla json de definición de versión tiene un ID para cada paso de compilación. Los ID deben ser un número específico cuando se crea el canal de lanzamiento. El número de identificación se cambia después de que se crea. Por lo tanto, cuando ACTUALIZA el canal de lanzamiento, ya no puede usar los "nuevos" números de ID de etapa (están reservados cuando se crea inicialmente un canal de lanzamiento), sino que necesita usar el ID de etapa ahora válido que podría ser cualquier cosa.
Antebios
Entonces, el proceso real debería ser: Para crear el proceso, use la plantilla. Para el proceso de actualización, descargue la definición de la versión y compárela con la plantilla y actualice la definición de la versión descargada y luego actualice esa de nuevo a VSTS. ¡Uf! Eso significa que necesito escribir mi propio proceso de comparación y verificación de errores.
Antebios
de hecho, para una nueva definición de lanzamiento (POST), puede ignorar la idpropiedad; idpara el objeto de definición de lanzamiento y en todos los environmentobjetos se puede ignorar; establecer la rankpropiedad debería ser suficiente (junto con otras requeridas); la llamada POST debería crear automáticamente los ID y volver en el objeto de respuesta. Una vez que se crea la definición de la versión, para obtener todas las definiciones en su organización, puede hacer una LISTen las definiciones de la versión - la llamada GET se documenta aquí
ofuscar el
-4

Las canalizaciones están formadas por uno o más trabajos y pueden incluir recursos y variables. Los trabajos se componen de uno o más pasos más algunos datos específicos del trabajo. Los pasos pueden ser tareas, scripts o referencias a plantillas externas. Esto se refleja en la estructura del archivo YAML. Visite aquí para más detalles

catlight.io -Obtener alertas
fuente
5
No agregue firmas a sus publicaciones; podrían considerarse spam.
Zoe