¿Está utilizando Git para implementar una mala práctica?

Iría tan lejos como para considerar el uso de git para la implementación muy buena práctica .

Los dos problemas que enumeró tienen muy poco que ver con el uso de git para la implementación en sí. Sustituya .git/ por el archivo de configuración que contiene las contraseñas de la base de datos y tendrá el mismo problema. Si tengo acceso de lectura a su raíz web, tengo acceso de lectura a todo lo que contenga. Este es un problema de fortalecimiento del servidor que debe discutir con la administración de su sistema.

git ofrece algunas ventajas muy atractivas cuando se trata de seguridad.

1. Puede imponer un sistema para implementarlo en producción. Incluso configuraría un gancho post-receive para implementarlo automáticamente en producción cada vez que se realice una confirmación para master . Supongo que, por supuesto, un flujo de trabajo similar a git flow .

2. git hace que sea extremadamente fácil revertir el código implementado en producción a una versión anterior si se plantea un problema de seguridad. Esto puede ser útil para bloquear el acceso a fallas de seguridad críticas para la misión que necesita tiempo para solucionar adecuadamente.

3. Puede imponer un sistema donde sus desarrolladores deben firmar los compromisos que realizan. Esto puede ayudar a rastrear quién implementó qué en producción si se encuentra una falla de seguridad deliberada.

No hay nada de malo en desplegar desde un repositorio git, de hecho es una práctica bastante común y, como usted dice, es mucho menos propenso a errores que copiar archivos a través de ftp o rsync.

Teniendo en cuenta la información que me has proporcionado, debería tener en cuenta los siguientes puntos:

• No solo tire del último maestro. La producción debe desplegarse desde una etiqueta de lanzamiento. Utilice git flow o similar para obtener un poco más de proceso en torno al despliegue del código y creación de las etiquetas. Debido a que las etiquetas son una referencia inmutable a su código en un momento dado, es más estable que apuntar a una rama maestra que podría ser actualizada por una confirmación errante.

• En cuanto a servir el directorio .git, esto no debería ser un gran problema. Simplemente redirija todo lo que tenga el prefijo .git a un 404 en .htaccess.

• Su autenticación git debe basarse en la clave ssh, por lo que no es necesario almacenar contraseñas en el servidor.

¡Hurra para los flujos de trabajo de implementación de git!

Puede usar el argumento --separate-git-dir=<git dir> al llamar a git clone . Esto colocará un enlace simbólico en el directorio .git (simbólico a Git, no creo que sea un enlace simbólico a su sistema operativo), y puede especificar <git dir> en algún lugar fuera de la raíz del documento.

Un enfoque alternativo que he tomado antes es algo similar al comentario de Terry Chia con respecto a los ganchos posteriores a la recepción.

Git tiene varios enganches que se pueden usar para realizar todo tipo de tareas antes / durante / después de múltiples diferentes acciones.

Cree un repositorio bare en cualquier lugar que no sea su carpeta web. El repositorio simple se puede usar como un remoto para empujar hacia , y se puede activar un enlace posterior a la recepción para verifique el nuevo código en un directorio específico.

Este enfoque tiene algunas ventajas: la ubicación de implementación actúa como una calle "de un solo sentido" donde el código debe pasar por el control de fuente para terminar en producción. Puede implementar diferentes sucursales / versiones en diferentes ubicaciones (todas desde el mismo repositorio). También proporciona una manera fácil y fácil de deshacerte utilizando el proceso de pago estándar de git. Sin embargo, una advertencia / consecuencia de esto es que los cambios de código en el servidor no se reflejarán en git (los repositorios no tienen directorios de trabajo), por lo que tendría que realizar manualmente git --work-tree=/path/to/code status para ver los cambios (pero no debería De todos modos, no cambiará el código de producción, ¿verdad?

Estoy de acuerdo con Terry Chia en que es una muy buena práctica. Asegura:

• que la revisión en su lugar es la correcta,
• con todos los archivos necesarios y verifica que la versión esté completa,
• hacer que el procedimiento de implementación sea rápido y fácil

Pero, debo agregar que hay advertencias que me gustaría compartir.

Por lo general, en un repositorio de git pones:

• código,
• documentos,
• pruebas unitarias,
• scripts de implementación,
• herramientas de integración,
• .deb archives,
• parches sql
• o cosas por el estilo, y tal vez un montón de otras cosas

Bueno, en producción, ¡solo quieres el código!

Porque, los documentos, las pruebas de unidad, las herramientas o los archivos .deb pueden ocupar mucho espacio en el disco y no tienen nada que hacer en la producción.

Con Subversion (antes de la versión 1.7), puedes ingresar solo al directorio src/ y tienes todas las ventajas. Pero con Subversion > 1.7 y con Git, no puedes hacer eso.

Una alternativa sería usar los submódulos de git para hacer ese tipo de arquitectura: %código% Pero entonces tu proyecto / tests y el código de project-src no se sincronizarían y eso realmente apestaría.

La solución sería utilizar "pago disperso", ver: enlace

Para que pueda usar git, pero tenga cuidado con estos inconvenientes.

Voy a estar en desacuerdo con la opinión popular aquí. Git es para el control de versiones, no es para la implementación / CI.

Los métodos que la gente aboga aquí están bien para proyectos pequeños, pero en general no se escalan muy bien.

... lo cual no quiere decir que no debes seguir haciendo lo que estás haciendo. Solo tenga en cuenta, a medida que avanza su carrera, que los proyectos en los que está trabajando probablemente superarán un flujo de trabajo de implementación basado únicamente en git.

El cambio principal en el paradigma es dejar de pensar en implementar sucursales y comenzar a pensar en implementar resultados de compilación e inyectar dependencias del entorno para desacoplar su infraestructura de su estrategia de bifurcación.

Por ejemplo, para usar el paradigma anterior sobre 'implementación de archivos' y reversión. Si estaba implementando archivos, podría mantener varias versiones de la aplicación en el servidor de producción, y si necesita revertir, puede apuntar su servidor web a una versión anterior volviendo a vincular la raíz web. Dos comandos de shell, microsegundos de tiempo de inactividad, menos margen de error que el uso de git.

Otro ejemplo: tiene la rama dev estándar > rama escenificadora > flujo de trabajo maestro, con un servidor para cada uno. Tienes cosas listas para el desarrollo, pero algunas otras cosas en la preparación fallaron en el control de calidad. Por lo tanto, debe realizar algunas operaciones feas: elimine los compromisos incorrectos de la etapa, vuelva a desplegarlos, elimine o corrija los compromisos incorrectos en el desarrollo y espere que el desarrollo y la puesta en escena no se desincronicen.

En su lugar, ¿qué sucede si corta una rama de lanzamiento del maestro, fusiona las cosas que están listas para ingresar a esa rama de la versión y construye el resultado, elabora un servidor de prueba en AWS y lo implementa, ejecutó su control de calidad y ¿Pruebas funcionales contra ese servidor provisional temporal y luego enviaron ese mismo resultado al clúster de producción y lo implementaron? Luego retire el cuadro provisional provisional que giró, fusione el lanzamiento en el maestro y etiquete el maestro con un número de lanzamiento.

Obviamente esos son ejemplos extremos. Por lo general, no está tan limpio, incluso si queremos que lo esté, es probable que necesite ejecutar algunos procesos de compilación en el entorno de destino porque es necesario que ocurran cambios en la base de datos. Y si tiene mods de base de datos no idempotent entre versiones, bueno, revertir no será tan fácil, no importa qué método use, ya que necesitará revertir la base de datos (en general, intente implementar una base de datos idempotent cambios, luego elimine los bits de la base de datos obsoletos en una versión posterior, una vez que esté seguro de que están fuera del flujo de la aplicación).

De todos modos, supongo que a lo que me refiero es a que mi respuesta a "¿Está utilizando git para una mala práctica de implementación?" es, en términos generales, 'Sí', de la misma manera que usar las ruedas de entrenamiento es malo para andar en bicicleta. Es una mejora sobre el hecho de romper tu trasero en el concreto repetidamente, pero es de esperar que eventualmente lo superes.

Aquí está el script que uso para hacer git para empujar a prod.

enlace

Supone que todo lo que se envíe a la rama maestra está listo para la producción. Todas las otras ramas empujadas son ignoradas. Puede modificar este script de enganche para satisfacer sus necesidades.

En cuanto a sus preocupaciones, coloco mi directorio git debajo de / var / git y mis archivos de producción en otro lugar (como / var / www) y restringo el acceso a estos directorios.

También puede tener su repositorio git en un servidor separado de su servidor de producción y luego usar algo como scp y ssh en el script anterior para mover sus archivos desde el servidor git al servidor de producción. Esto le permitiría seguir usando git para presionar a la vez que mantiene su código separado de su producción.