¿Qué sistema de control de versiones puede gestionar todos los aspectos? [cerrado]

17

Hace unos meses busqué Subversion y GIT y me decepcionó. Manejan bien el CÓDIGO FUENTE pero no otros aspectos. Por ejemplo, un sitio web bajo control de versiones necesita administrar la propiedad de archivo / directorio, acceso de lectura / escritura de archivo / directorio, Listas de control de acceso, marcas de tiempo, contenido de la base de datos. y enlaces externos. ¿Existe un sistema de control de versiones que pueda hacer una reversión tan perfecta como la recarga desde una copia de seguridad de un mes?

Andy Canfield
fuente
12
¿Parece como si quisieras un sistema de respaldo?
Macke
2
¿Has considerado ejecutar tu sitio web bajo OS X en una Mac? Time Machine es quizás la solución de respaldo más simple actualmente disponible y hace que sea muy fácil revertirla si es necesario.
1
Si está seriamente interesado en el tema, debe echar un vistazo a la investigación en sistemas de archivos de versiones y en bases de datos de versiones, que van más allá de los sistemas de control de versiones para el código fuente.
Jakob
¿Qué hay de malo en escribir un poco de secuencias de comandos para manejar cosas que SCM no maneja? de esa manera obtienes lo que quieres Y lo tienes bajo el control de la fuente.
Newtopian

Respuestas:

44

Está confundido sobre el papel de un sistema de control de versiones. No es y nunca fue un sistema de respaldo para un sitio web en ejecución. Hace un trabajo extremadamente bueno al administrar contenido estático para que pase a la producción de manera controlada. Con el uso adecuado del etiquetado y los pagos automáticos, incluso los sitios que cambian rápidamente se pueden mantener en un sistema de control de versiones.

Un sistema de control de versiones podrá decirle cómo pasó de cómo se veía el sitio el mes pasado a cómo se ve hoy (al menos para aquellos componentes que están bajo control de fuente). Debe incluir todo lo que necesita para reconstruir el sitio web (excepto el contenido dinámico). Como otros han señalado, cualquier cambio en los permisos y la propiedad debe ser programado, y ese script debe incluirse en el control de versiones.

Los permisos de acceso para sitios web suelen ser bastante simples. (Básicamente, debe asegurarse de que el servidor web pueda leer todo el contenido y escribir muy poco). Con la excepción de la propiedad del directorio de los pocos directorios que la subversión del servidor web debe poder escribir, y posiblemente git, ciertamente puede manejar permisos. Los directorios que el servidor web puede escribir suelen contener contenido dinámico (creado y actualizado desde el sitio web), que se gestiona por separado de la fuente de los sitios web.

Si me pidieran trabajar con un sitio web con permisos complicados y ACL en su sitio web, tendría serias preocupaciones sobre el proceso utilizado para administrar el sitio web. Implementar un sistema de control de versiones y mover las ACL a él sería una de las soluciones que consideraría seriamente.

El contenido dinámico, como entradas de blog o comentarios, generalmente está contenido en una base de datos u otro almacén de datos en lugar del control de versión utilizado para construir el sitio. El almacén de datos puede organizarse para proporcionar control de versión de su contenido (como es este software). Muchos wikis usan un sistema de control de versiones para rastrear las revisiones.

EDITAR:

La solución que estoy usando es (a) Sin control de versión, (b) El sitio de producción es el sitio maestro, (c) Archivar cada vez que algo cambia, (d) El script de archivo elimina basura como ACL, y (e) la secuencia de comandos de instalación corrige otros permisos de archivos basura.

Estos problemas se pueden manejar importando el sitio a un sistema de control de versiones y cambiando su proceso para que el sitio maestro se actualice a través de ese sistema. (a), (b) y (c) se manejan directamente mediante el control de versiones. Es posible que desee etiquetar lanzamientos para que (c) funcione mejor. (d) generalmente no es un problema si solo tiene el sistema de implementación cambiando su sitio. Nunca he necesitado ACL en el contenido del sitio.

(e) solo debería ejecutarse en la creación inicial y los cambios importantes. También puede incluir el script que actualiza el sitio desde el control de versiones y se ejecuta con frecuencia. Estos scripts tienden a ser bastante simples cuando mantiene su sitio en un sistema de control de aversión.

Pero, ¿por qué nadie ha construido un sistema general para hacer esto?

Porque no es necesario si usa un sistema de control de versiones.

Un sistema de control de versiones PODRÍA seguir todo esto, pero ninguno lo hace.

Tanto CVS como Subversion rastrean lo que necesita rastrear si los está usando. No rastrearán lo que necesita rastrear porque no está utilizando un sistema de control de versiones, ni deberían hacerlo. Rastrean lo que necesita rastrear cuando está utilizando un sistema de control de versiones.

He trabajado con varios sitios que administraron su contenido mediante el control de versiones. Todos tenían requisitos diferentes para los sitios de preparación, la frecuencia de implementación y la integridad de las actualizaciones. Una vez que los sitios estaban en control de versiones, el resto de los requisitos eran relativamente fáciles de cumplir. La documentación para CVS y Subversion hace sugerencias para posibles métodos de actualización.

Es posible que necesite ACL para limitar el acceso a áreas particulares dentro del contenido controlado por la versión. Sin embargo, tiendo a trabajar con confianza. El control de versiones facilita ver quién hizo qué y cuándo. Si no reformatea los archivos, es fácil obtener un historial anotado de un archivo que muestre quién agregó qué líneas y cuándo.

BillThor
fuente
+1 por desarrollar razones por las cuales la pregunta es incorrecta desde el principio.
Macke
2
+1 Sin embargo, es bueno que se haya hecho la pregunta para que otros puedan beneficiarse de su respuesta.
Oliver-Clare
Se supone que un sistema de control de versiones me da la capacidad de decir "OK, en esta otra computadora aquí, construyan el sitio a partir del 28 de julio". El control de versiones es más eficiente que las copias de seguridad porque rastrea los cambios. De lo contrario, sí, una copia de seguridad diaria haría bien el trabajo.
Andy Canfield
Sí, la solución que estoy usando es (a) No hay control de versión en absoluto, (b) El sitio de producción es el sitio maestro, (c) Archivar cada vez que algo cambia, (d) El script de archivo elimina basura como ACL, y ( e) el script de instalación corrige otros permisos basura como archivos. Pero, ¿por qué nadie ha construido un sistema general para hacer esto? Un sistema de control de versiones PODRÍA seguir todo esto, pero ninguno lo hace.
Andy Canfield
+1: Gran respuesta. Sin embargo, me gustaría agregar que ningún sistema de control de versiones rastrea esas cosas porque NO PODRÍAN. Los permisos y los nombres de usuario son específicos del host y su formato es específico del sistema; no hay forma de que la herramienta pueda transferirlos automáticamente a un host diferente, especialmente cuando se trata de un sistema operativo diferente.
Jan Hudec
10

Todos y ninguno de ellos.

Es una mala idea obtener el control de origen para administrar esos detalles directamente, en la forma en que su pregunta se insinúa.

Sin embargo, puede escribir un script bash (* nix) o un script powershell (Windows), que logra cualquiera o todos esos objetivos. Este script podría almacenarse en el control de origen.

Luego puede hacer que el script sea uno de sus artefactos de compilación y ejecutarlo como parte de su implementación.

pdr
fuente
Esta. La idea de tener fuentes es que puede extraerlas de su VCS y usarlas para construir el producto terminado.
Blrfl
2

En mi humilde opinión, un sistema de control de versiones en sí mismo no está destinado a ser utilizado de esa manera.

Pero lo que tiendo a hacer es asegurarme de que pueda obtener una versión del control de origen, solo necesita ejecutar un archivo de compilación / archivo de PowerShell y todo volverá a funcionar.

Para esto necesitas:

  • todas las bibliotecas de las que depende su aplicación en el control de origen
  • un archivo de compilación que establece su entorno
  • una instrucción sobre los requisitos de su entorno (no desea poner una instalación de servidor sql en su control de origen)
KeesDijk
fuente
1

Creo que lo que necesita en su caso es una herramienta de administración de configuración . El que he usado es títere .

Citandote:

gestionar la propiedad de archivo / directorio, acceso de lectura / escritura de archivo / directorio,

Lo he hecho con una línea (asegúrese de que el usuario exista, asegúrese de que exista el directorio, etc.) ...

Listas de control de acceso,

Si se trata de ACL de Windows, existen herramientas CM específicas para Windows ...

marcas de tiempo,

de nuevo, el comando touch unix en una línea en un guión de títeres podría hacer esto por usted.

contenido de la base de datos.

Esa es la construcción en muchos marcos, ¿un trabajo cron que garantiza que todo esté allí de lo contrario?

y enlaces externos.

No se nada de eso.

Por supuesto, después de escribir su código de Gestión de configuración, es posible que desee ponerlo (o recuperarlo en los sistemas involucrados) en un sistema de control de versiones. No te alejarás de esos :-).

Dimitrios Mistriotis
fuente
No entiendo lo que quiere decir con "marcas de tiempo: una vez más, un comando de Unix en una línea en un guión de títeres podría hacer esto". En mi sitio, para obtener la versión del sitio, escanea todo el árbol del sitio y devuelve la fecha y la hora del archivo más reciente. Quiero que mi control de versiones "Checkout" les dé a los archivos la misma marca de tiempo que tenían al registrarse, no configurada como "ahora". ¿Cómo se hace eso en un comando de Unix?
Andy Canfield
por supuesto, está buscando "tocar", verifique esto: en.wikipedia.org/wiki/Touch_(Unix) . En general, al retirar el tiempo actual se aplicará, pero si por alguna razón desea una marca de tiempo diferente, esta es la forma de hacerlo.
Dimitrios Mistriotis
De hecho, me gustó la razón de su pregunta, desea automatizar tanto como sea posible, que es la "forma correcta", necesita algunos conocimientos sobre cómo hacerlo y qué va a VControl y qué no. Desearía que más personas en
nuestra
0

Hay un último sistema de control de versiones que gestiona todos los aspectos de todos los documentos digitales. Se llama Xanadu y fue creado por Theodor Holm Nelson en 1960, incluso antes de que los sistemas de archivos fueran comunes. Entonces, en teoría, todo está perfectamente resuelto. En la práctica, Xanadu nunca se implementó según lo previsto por Nelson, pero inspiró muchos más sistemas especializados, incluidos la Web y los sistemas de control de versiones. Las obras de Nelson todavía merecen una nueva lectura, y pueden responder la pregunta de por qué no hay un VCS general que gestione todos los aspectos.

Jakob
fuente