Jenkins vs Azure DevOps Pipelines

He estado investigando la solución Azure DevOps que Microsoft presentó recientemente .

Algunos antecedentes, he estado usando Jenkins durante años, y recientemente comencé a explorar el agujero del conejo en contenedores (Docker, Kubernetes, etc.),

No estoy seguro acerca de algunos de los aspectos de Azure DevOps Pipelines, y sería increíble obtener comentarios y claridad.

TL; DR

1. ¿Azure DevOps ahora está compitiendo con Jenkins, donde anteriormente apoyaban a la comunidad de Jenkins a través de complementos de código abierto para Jenkins?
2. ¿Es posible para mí alojar Azure DevOps Pipelines completamente en las instalaciones, no solo agentes?
3. ¿Es posible usar una solución git autohospedada (como GitLab in situ) con Azure DevOps Pipelines?

Versión más larga

1. Microsoft ha desarrollado varios complementos de código abierto para Jenkins, como el complemento Azure App Service Jenkins . Hay muchos ejemplos Para mí, parece que la solución Azure DevOps (específicamente Pipelines) ahora está compitiendo directamente con Jenkins, ¿o me estoy perdiendo algo?
2. Para mí, parece que no hay forma de alojar la solución Azure Pipelines en las instalaciones o en un proveedor de nube de mi elección. Sí, puedo alojar a mis propios agentes donde se realiza la mayor parte del trabajo, pero la ejecución real de la lógica de canalización ocurre en los servidores de Microsoft. Y luego tengo que pagar por trabajos paralelos . Estoy comparando esto con una instancia de Jenkins alojada en las instalaciones (o proveedor de nube de elección), donde no se requiere pago, y ningún tercero es consciente de que nuestras canalizaciones se están ejecutando. ¿Me estoy perdiendo de algo?
3. Por lo que puedo decir, Azure Pipelines no tiene soporte para repositorios autohospedados, puse mi código en GitHub o en repositorios de Azure , nada más. Por lo tanto, ¿ni siquiera puedo usar esta solución de Pipelines si tengo una instancia de GitLab alojada de forma privada?

Gracias por cualquier aportación.

Me encantaría obtener algo de claridad también, tal vez de una fuente más autorizada que yo (estoy seguro de que también soy culpable de FUD).

He estado buscando implementar en Azure usando Kubernetes. Estoy igualmente confundido, pero creo que es porque no hay un camino claro. No puedo hablar por Microsoft, pero su actitud hacia la nube parece ser que están felices de convertirse en " todo para todos los hombres ". Si está utilizando Azure, Microsoft no parece tener una opinión sólida sobre cómo llegar allí.

Microsoft está tratando activamente de evolucionar; por ejemplo, Linux ahora domina Azure

Claramente, la implementación de Azure DevOps hace exactamente lo que Jenkins puede hacer, por lo que, en ese sentido, es un competidor. También existe ese precio inicial de Azure DevOps un poco desagradable para las canalizaciones paralelas.

Por un lado, Azure DevOps parece ser un cambio de marca de Visual Studio Team Services. Por lo tanto, será familiar para las personas que ya están dentro del ecosistema de desarrollo tradicional de Microsoft. Al mismo tiempo, Microsoft está haciendo grandes esfuerzos para adoptar tecnologías que no son tradicionalmente Microsoft ( Go, Java, Node.js, Python, Ruby, PHP, etc.).

Es temprano, pero no es una sorpresa que las canalizaciones de Azure DevOps prefieran las propiedades de Microsoft Git de Azure Repos y GitHub. De la misma manera que las tuberías de BitBucket prefieren BitBucket y las tuberías de GitLab prefieren GitLab.

Mientras tanto;

Azure Marketplace ofrece una implementación de Jenkins que viene con complementos de implementación de Azure listos para usar.

Muchos complementos de Jenkins han sido desarrollados por el equipo de Azure DevOps .

Adicionalmente;

Microsoft ha respaldado los proyectos relacionados con Kubernetes, Helm and Draft . Helm es un administrador de paquetes para Kubernetes. Incluso puede usar Helm para implementar una instalación de Jenkins en Kubernetes.

-

Sería interesante ver a alguien sopesar los beneficios, los costos y el esfuerzo de ejecutar sus propios Jenkins en versos de Azure utilizando las canalizaciones de Azure DevOps.

... y luego está Jenkins-X .

Entonces parece que tenemos muchas opciones y decisiones que tomar.

En respuesta a la parte 2 (tal vez), parece que lo están lanzando como una alternativa a Jenkins, aunque hay mucha documentación que sugiere que todo se puede usar juntos (y aquí ). Sin embargo, cuando se usa con Jenkins, parece estar más centrado en un puente de implementación. Esperaba poder usarlo como agente de compilación con Jenkins como orquestador, como podría hacer con Jenkins y AWS CodeBuild. Todavía no he visto nada que sugiera que podría hacerlo, pero tal vez ... Sin embargo, las implementaciones en varias nubes son muy interesantes ...

1. Sí, porque Azure Pipelines puede hacer lo que hace Jenkins. Sin embargo, no tiene que tirar al bebé con el agua del baño. Microsoft continúa posicionando sus plataformas de manera que las integraciones pueden ocurrir con instalaciones existentes de casi cualquier cosa. Muchas organizaciones tienen grandes inversiones en herramientas que son difíciles de cambiar. En lugar de adoptar una postura de todo o nada, Microsoft adopta estándares y una mentalidad de traer su propia identidad, ofreciéndole la mejor opción en cuanto a cómo desea implementar las herramientas.

2. Los agentes son técnicamente su canalización, ya que las tareas se ejecutan en los agentes seleccionados dentro de la canalización. Todo lo que está configurando dentro del portal son los pasos que ejecutará la canalización. Los agentes descargan las herramientas / extensiones necesarias para ejecutar las tareas. Además, con las nuevas tuberías de YAML, las tuberías se definen dentro de los repositorios de código. En lo que respecta al alojamiento, puede alojar Azure DevOps Server completamente en las instalaciones, dentro de cualquier proveedor de la nube o una combinación de máquinas virtuales de Azure y Azure SQL.

3. Los repositorios genéricos de Git son compatibles con Azure DevOps Services que usan el editor clásico o YAML y el editor clásico si se usa Azure DevOps Server (on-prem) en este momento. Puede agregar la integración del repositorio de GitLab instalando la extensión.