Diferencia entre DevOps y la gestión de configuración de software


16

¿Cuál es la diferencia entre las operaciones de desarrollo y la gestión de configuración de software?

Para mí, parece ser lo mismo, siempre que tanto DevOps como Software Configuration Management se centren en:

  1. Establecimiento de infraestructura de desarrollo : estar a cargo del control de versiones , la gestión de compilación, la gestión de implementación, la gestión de dependencias, la integración y entrega continuas , etc.
  2. Uso de mejores prácticas para organizar el entorno de desarrolladores .
  3. Aseguramiento de la calidad de los procesos de desarrollo: recopilación de métricas de efectividad del desarrollo, trabajo para eliminar cuellos de botella del proceso de desarrollo (ejecución de pruebas unitarias, evaluación de la cobertura de pruebas unitarias, ejecución de inspecciones, etc.)
  4. Gestión de infraestructura : plataformas objetivo y sus características.
  5. Gestión de versiones : asegurarse de que la versión se haya entregado al cliente a tiempo.

Tal vez me estoy perdiendo algo? Este enlace muestra que prevalece el uso del término 'Administración de configuración de software'. Pero aún así, ¿qué combinación de palabras preferiría usar para describir el rango de actividades enumeradas: Operaciones de desarrollo o Gestión de configuración de software ?

Respuestas:


19

Los términos describen conceptos y responsabilidades muy similares, y en general son algo sinónimos. El término "DevOps" es relativamente nuevo, popularizado por la conferencia Devopsdays Ghent 2009 y los eventos posteriores de Devopsdays . Se describe mejor en este diagrama :

ingrese la descripción de la imagen aquí

Por otro lado, Software Configuration Management es un término mucho más establecido dentro de la profesión y deriva del término no específico de software Configuration Management . La Gestión de la configuración de software a menudo se hace referencia en un contexto de ingeniería de software, Roger Pressman da una definición simple en "Ingeniería de software: un enfoque profesional" :

es un conjunto de actividades diseñadas para controlar el cambio mediante la identificación de los productos de trabajo que pueden cambiar, estableciendo relaciones entre ellos, definiendo mecanismos para administrar diferentes versiones de estos productos de trabajo, controlando los cambios impuestos y auditando e informando sobre los cambios realizados.

Aunque todos los términos a los que hace referencia son vagos, DevOps parece ser una forma menos formal de describir más o menos el mismo conjunto de principios que la Gestión de la configuración, o la Gestión de la configuración del software si se ve desde la perspectiva de un desarrollador de software, especialmente priorizando equipos estrechamente vinculados :

DevOps es una respuesta a la creciente conciencia de que existe una desconexión entre lo que tradicionalmente se considera actividad de desarrollo y lo que tradicionalmente se considera actividad de operaciones. Esta desconexión a menudo se manifiesta como conflicto e ineficiencia.

En el mismo artículo, se observan las similitudes con SCM:

Agregar al Muro de Confusión es el desajuste demasiado común en las herramientas de desarrollo y operaciones. Eche un vistazo a las herramientas populares que los desarrolladores solicitan y usan a diario. Luego, eche un vistazo a las herramientas populares que los administradores de sistemas solicitan y usan a diario. Con algunas excepciones notables, como los rastreadores de errores y tal vez SCM , es dudoso que vea mucho interés en usar las herramientas de los demás o una integración significativa entre ellos. Incluso si hay alguna superposición en los tipos de herramientas, a menudo las implementaciones serán diferentes en cada grupo.

En cuanto al uso de los términos, su comparación realmente no tiene sentido:

  1. SCM es un subconjunto de CM, no un término competitivo,
  2. DevOps es un término bastante nuevo, no tiene sentido compararlo con los términos establecidos,
  3. DevOps deriva de las Operaciones de desarrollador (obviamente), pero rara vez se expande como tal.

¿Te refieres a SCM como gestión de código fuente o gestión de configuración de software es un subconjunto de CM?
altern

@zaphod_beeblebrox: esa imagen está tomada del artículo de wikipedia: en.wikipedia.org/wiki/DevOps :)
alterna

@altern Párrafo debajo de la imagen bonita: "Por otro lado, Software Configuration Management es un término mucho más establecido dentro de la profesión y deriva del término no específico de software Configuration Management". : P También la foto está tomada del blog al que me he vinculado. Si el autor lo tomó de Wikipedia, no lo sabría.
Yannis

@zaphod_beeblebrox: Probablemente debería cambiar el título de mi pregunta entonces
altern

@altern ¿Qué quieres decir? Software Configuration Management no está solo en el título. Además, qué diablos es "Gestión del código fuente". ¿Te refieres al control de revisión? En caso afirmativo, el control de revisión es un aspecto de la Gestión de la configuración del software, por lo que la respuesta se mantiene como está. Pero comparar el control de revisión con los devops es extraño, por decir lo menos.
Yannis

6

Personalmente como Gerente de Configuración de Software Sr. por muchos años (10+) escucho que los términos no coinciden en una variedad de situaciones de la vida real. No es raro para el personal no técnico debido a la naturaleza relativa de los puestos. Ambos tienen roles, necesidades y requisitos específicos que son similares pero que, sin embargo, se pueden dividir claramente en mi opinión.

Creo que la mejor manera de describir la división de estos roles es enfocarse en su relatividad con la interacción. Es decir, la Gestión de la configuración del software se centra en los sistemas y entornos internos, junto con la integración, implementación, lanzamiento y gestión del código fuente. Where as Developer Operations (DevOps) se enfoca más en el aspecto operativo de la arquitectura de aplicación externa, mientras que mantiene una comprensión clara del código tal como fue diseñado para su uso y la práctica de su entorno. Si el rendimiento de una máquina muestra signos de degradación, la comunicación entre múltiples aplicaciones es defectuosa, la comunicación de empresa a empresa (BtB) y / o las limitaciones de arquitectura en relación con un entorno de producción, entonces debería consultar a las Operaciones del desarrollador para su diagnóstico y solución.

Por lo general, en mi experiencia, el Administrador de configuración de software también puede hacer estas cosas, pero esto les quita su enfoque principal de seguimiento, administración e implementación de configuraciones de entorno y revisiones de software. Administrar el software que permite la separación de tareas, seguimiento de errores y defectos, seguimiento de proyectos y el ciclo de vida y flujo de trabajo del desarrollo de software. Estas tareas no son el foco principal de las Operaciones del desarrollador y, por lo tanto, son menos imperativas, pero aún se pueden hacer.

He visto muchos casos de la confusión de cada uno, y en cada uno hay un cruce limitado. Sin embargo, es muy importante pensar en las diferencias entre las responsabilidades de cada una de las posiciones independientes en relación con su enfoque principal. Principalmente cuando se trata de sistemas y hardware utilizados internamente para administrar la configuración de entornos y el lanzamiento del producto, buscaría un Administrador de configuración de software. Por otro lado, cuando se trata del rendimiento del sistema, el monitoreo, la investigación y el diagnóstico de los sistemas utilizados por sus clientes, debe consultar las Operaciones del desarrollador o DevOps.

Ahora, esto no se entiende como una queja, ni como una respuesta definitiva, sino más bien una identificación personal de las diferencias de cada una de las posiciones. Me gustaría saber si estoy fuera de lugar, o si esta respuesta aclara las cosas.


2
Honestamente, cuando todo se reduce, DevOps se trata de hacer que los desarrolladores de software sean totalmente conscientes y responsables de la Gestión de la Configuración del Software. Cuando haces eso, obtienes un enfoque de SCM completamente diferente al que se ha hecho tradicionalmente: uno más enfocado en la integración continua y la entrega continua, y uno con (típicamente) menos seres humanos en la mezcla. DevOps se puede ver (y a menudo se ve) como Lean aplicado a SCM, así como Agile se puede ver como Lean aplicado al desarrollo de software.
Calphool

4

Sería difícil encontrar una definición sólida para DevOps. Es más una idea que un trabajo por hacer. Y es una idea demasiado nueva para que todos estén de acuerdo exactamente en lo que significa. Sin embargo, aquí está mi opinión.

DevOps es realmente un nuevo término para la gestión de la configuración, pero se eligió para mostrar que el rol no es de una sola persona, es una colaboración entre el equipo de desarrollo y el equipo de operaciones.

Históricamente, la gestión de la configuración la llevaría a cabo únicamente el equipo de desarrollo y luego se entregaría a las operaciones que lo verían con profunda sospecha. Lo cual es bastante justo, para ser honesto. Ellos son responsables de ello. Son los primeros en ser llamados a las 4 de la mañana cuando sale mal. Realmente deberían tener alguna participación en su desarrollo.


1

Esta es la simple aclaración de la pregunta: DevOps es un término utilizado para describir la coordinación o relación entre Desarrollo (desarrollo de los códigos del programa en el entorno de desarrollo) y Operaciones (que garantiza el máximo tiempo de actividad del entorno de producción).

La gestión de la configuración de software es un medio para lograr esta coordinación. SCM incluyó herramientas y técnicas para gestionar la automatización del proceso de pasar del desarrollo a la producción (operaciones)

Para resumir, SCM conecta Dev y Ops.

La conexión entre desarrollo y operaciones es SCM


-1

Veo que DEVOP está en el final de la ejecución operativa: scripts de automatización de implementación, desarrollos de entornos, ese tipo de cosas. SCM, por otro lado, trata sobre la integridad de los productos y la gestión efectiva y la trazabilidad de los cambios en los productos. Siempre he visto a ALM como parte de SCM; después de todo, ¿cómo puede gestionar los cambios en un producto si no tiene idea de los impulsores del cambio o quién los realizó? Los marcos de implementación pueden caer en cualquier lado, y ese lado dependerá invariablemente de las necesidades reguladoras de la organización para la que trabaja, después de todo, ¿desea que un desarrollador pueda realizar un corte rápido que significa que su máquina de diálisis solo funciona correctamente 99.99% de las veces, ¿o necesita esa situación para poder hackear el código de su sitio web porque sus desarrolladores tienen direcciones IP codificadas?


44
Esto se parece más a una diatriba que a una respuesta a la pregunta formulada
mosquito

Deer Hunter, A Rant, sí claro, lo es, pero ¿relevante? 100% Confía en mí en esto: hasta que la industria crezca y detenga los trucos, las marchas de la muerte no solo continuarán, sino que empeorarán. Esto es una promesa.
Jack

Las diatribas están bien, pero stackexchange no es el lugar para ellas.
Matt Freake
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.