Control de versiones y gestión de versiones

¿Existen algunos de los llamados "sistemas de control de versiones" que también admiten la administración / implementación de versiones reales?

La tienda de mainframe para la que solía trabajar tenía una herramienta de gestión de versiones automatizada que no solo controlaba las modificaciones concurrentes a las fonts, sino que también se ocupaba de ejecutar comstackdores, precomstackdores, utilidades de enlace de bases de datos, etc., convirtiéndolo en nuestra implementación totalmente automatizada herramienta también.

Tengo entendido que las herramientas de control de versiones "más modernas" solo admiten la parte de gestión de origen. Es ese entendimiento correcto?

Esto es absolutamente incorrecto Cualquier herramienta moderna de control de versiones admite ganchos de confirmación previa y posterior, en cuyo punto puede ejecutar cualquier código que desee.

En subversión, utilizamos el gancho post-commit para implementar una copy de la aplicación en el server de desarrollo cada vez que un desarrollador ingresa el código.

En nuestros serveres de producción reales, tenemos un código que verifica y luego implementa tags de versión secundaria estables, ya que están comprometidas con el repository por los administradores de versiones.

El control de versiones tiene poco que ver con la administración o implementación de versiones, por lo que tiene sentido que los VCS no intenten hacer esto también.

Lo que he visto en esta área son serveres de compilation o continuous integration (CI) . Estos escuchan los cambios en el VCS, hacen un nuevo checkout en cualquier commit y luego intentan build todo. Así que integran el VCS y las herramientas de compilation, recostackn los loggings de ellos y presentan todo en una bonita interfaz de usuario web.

De esta manera, cada herramienta puede ser simple.

[EDITAR] Valor agregado de un server de CI:

  1. Puede analizar el resultado de sus scripts de compilation y presentar una descripción general en un correo o una página web.

  2. Se asegura de que todas las testings se ejecuten después de una confirmación. No más "pero corre por mí".

  3. Algunos de ellos admiten confirmaciones diferidas (solo confirmarán cambios en el VCS cuando se ejecuten todas las testings)

  4. Puede ejecutar comstackciones en varios proyectos que dependen el uno del otro.

Depende de cuánto dinero y time desea invertir en dicho sistema. muchas personas usan control de versiones simple, como svn, y administran versiones manualmente (usando tags y twigs). Hay otras herramientas (gratuitas) para la continuous integration (creación constante de la aplicación) como cruisecontrol.

En el campo de la database, no sé nada bueno en el mundo libre, pero alguien aquí podría completar esto. así que ahora administro las versiones de la database manualmente …

Creo que lo que usted llama administración de versiones aquí se llama más automation de compilation . Hay varias herramientas en este espacio (make, ant, Nant, etc.), pero tienden a existir como herramientas separadas. Con frecuencia, se puede extraer el código del control de fuente separado, y se obtienen productos diseñados para supervisar el process (lo que se denomina continuous integration cuando se realiza automáticamente).

Hay algunos proveedores que envían herramientas de extremo a extremo que se encuentran bajo el título Application Lifecycle Management

-> Entiendo que las herramientas de control de versiones "más modernas" solo admiten la parte de gestión de fonts. Es ese entendimiento correcto?

El VCS solo trata con la parte de administración de la fuente, y no tiene sentido si no puede get notifications de los cambios (y después de que alguien implementó los principios básicos de la vcs no habrá dificultades para proporcionar esto ;-))

-> La tienda de mainframe para la que solía trabajar tenía una herramienta de gestión de versiones automatizada que no solo controlaba las modificaciones concurrentes a las fonts, sino que también se ocupaba de ejecutar comstackdores, precomstackdores, utilidades de enlace de bases de datos, etc., convirtiéndolo en nuestro herramienta de implementación totalmente automatizada también.

Esto se llama automation de compilation, y sí, es muy deseable que las mejores partes del proyecto estén "lists para enviarse" cuando alguien hace un cambio pero no es necesario. Puede hacer lo que quiera con las herramientas mencionadas anteriormente (son extensibles).

La práctica de continuous integration es la interpolación de estos puntos de forma que solo tenga un código limpio, estable y noble en los repositorys. Existen los llamados serveres de CI que conectan las partes VC y BA.

revise esta página para CI http://martinfowler.com/articles/continuousIntegration.html

y si alguien necesita un server de CI compatible con muchas herramientas de BA y muchos VCS echen un vistazo a JetBrains TeamCity

espero que esto ayude

En el mundo de ruby ​​on rails, Capistrano es la herramienta de implementación preferida.

http://www.capify.org/index.php/Capistrano

Actualmente estoy desarrollando una aplicación web para la gestión de lanzamientos y, si desea ser un usuario beta, hágamelo saber. Tengo una versión funcional para processs de gestión de versiones esenciales, como la capacidad de crear lanzamientos seleccionando los cambios que desee (mientras se ocupan automáticamente de los cambios de dependencia) y deployment o repliegue en cualquier punto del historial de versiones en muchos entornos diferentes (testing o producción serveres). Actualmente, admite la integración con SVN.

Por favor, http://www.ngashint.com para el sitio de blog del proyecto. Puede dejar su correo electrónico para comenzar a recibir una versión beta o enviarme un correo electrónico kzt001 [at] gmail.com

Esta pregunta llamó mi atención, debido a la

'… los llamados "sistemas de control de versiones" …'

en la pregunta, y debido a que la pregunta está labelda con control de versión …

Vengo del mundo de mainframe (también), y el mainframe 'SCM' (= Administración de cambios de software) es todo lo que hemos estado haciendo durante los últimos 25 años más o less.

Estoy un poco sorprendido (¿tal vez "conmocionado"?) De ver todos los llamados sinónimos de la label de control de versiones . Especialmente la label scm (y no estoy seguro de lo que sugiere el process SE para dejar de considerarlo como un sinónimo). SCM, al less en el mundo de mainframe, es mucho más que solo control de versión (eso es solo parte de SCM). ¿Qué pasa con cualquiera de estos temas de alguna manera relacionados (que son, en mi humilde opinión, subfunciones de SCM):

  • gestión de lanzamientos (parte de la pregunta original).
  • processs de implementación (parte de la pregunta original).
  • análisis de impacto.
  • flujos de trabajo de aprobación.
  • entornos de testing confiables y utilizables.
  • procedimientos de emergencia, por ejemplo, durante ningún horario laboral.
  • Retrocesos automatizados (retrocesos) que toman solo unos segundos.
  • auditoría (processs de gobernanza).
  • … (sigue y sigue la list).

Para ilustrar cuán importantes son todos, a menudo hago esta pregunta para pensar: "¿Qué se necesita para aplicar un (error)? – corregir el software de piloto automático en un avión … ¡¡En vuelo!?!?" En otras palabras: "¿Cuáles son todos los pasos y procedimientos que tienen que estar en su lugar antes de que se sienta cómodo para que se aplique esa corrección durante un vuelo en el que se encuentra?".

De las diversas respuestas proporcionadas anteriormente, no estoy seguro (todavía) de cuál de ellas, si es que hay alguna, seleccionar para tal inflight-bugfix.