Conversión de un equipo de desarrollo de FTP a un sistema de control de versiones

Question

Trabajo en un pequeño estudio de desarrollo de LAMP donde la idea ha sido simplemente hacer el código y pasar al siguiente elemento de la lista.

El equipo trabaja en Zend Studio 5.5 conectado al servidor en vivo a través de FTP o SFTP. Lo que les gusta de esto es la velocidad de su implementación de código (ya que solo está modificando el código en vivo).

Pero, por supuesto, esto no es bueno debido a muchas razones obvias.

Me gustaría moverlos a un sistema de control de versiones (CVS, SVN o cualquier otra herramienta), pero el problema es que no soy su principal, así que necesito una zanahoria para que comiencen a usar esto.

¿Qué tipo de configuración necesitaría construir en su máquina para que puedan programar como siempre?

Lo que haría sería crear esta configuración en mi máquina y luego mostrarla.

Sé que esto es un poco inusual, pero se ha convertido en una de mis pasiones cambiar su forma de pensar, desde el pirateo habitual de código hasta la estructura y la elegancia. Gracias.

ACTUALIZACIÓN (la respuesta de Jonathan Leffler):

1. Sí
2. Sin
3. Sí, realmente lo hacen

pregunta también, el estudio hace un sistema CMS centralizado que está alojada en cientos de sitios, necesitan modificar sitios individuales, ¿deberían los sitios estar en la composición principal o dentro de la suya propia?

Answer 1

Preguntas:

1. ¿Tiene usted (que) nunca tuvo un desastre en el que (ellos) necesarios para volver a una versión anterior del sitio web, pero no pudo porque se había roto?

2. ¿Utilizan un servidor web de ensayo para probar los cambios?

3. Seguramente no modifican el código en el servidor de producción sin algunas pruebas en algún lugar?

Sospecho que la respuesta a la primera es "(desastres que han tenido) Sí" y el segundo "no", y no me atrevo a adivinar la respuesta a la tercera (pero. A partir de los sonidos de la misma, la respuesta podría ser "sí, realmente lo hacen"). Si eso es correcto, admiro su valentía y estoy sorprendido de que nunca se equivoquen. Nunca me arriesgaría a hacer cambios directamente en un sitio web en vivo.

Yo recomendaría usar usted mismo un sistema de control de versiones o VCS (cualquier VCS). Resuelva las arrugas del código que cuida y desarrolle una distribución elegante que facilite (probablemente aún use SFTP) distribuir el código VCS al sitio web. Pero también muestran que preservar las versiones anteriores tiene sus méritos, porque puedes recuperar quién hizo qué y cuándo. Para empezar, es posible que deba descargar la versión actual de cualquier página (archivo) en la que necesite trabajar y poner esa última versión en el VCS antes de comenzar a modificar la página, porque es posible que alguien la haya modificado ya que fue actualizado por última vez en su repositorio principal.También es posible que desee hacer un "raspado" diario de los archivos para obtener las versiones actuales y realizar un seguimiento de los cambios. No tendrías el 'quién', ni exactamente 'cuándo' (mejor que el día más cercano), ni el 'por qué', pero tendrías el (acumulativo) 'qué' de los cambios.

---

En respuesta a los comentarios en la pregunta, Ólafur Waage aclarado que han tenido los desastres debido a la falta de un VCS.

Eso generalmente hace la vida mucho más fácil. Ellos hicieron tonterías; no podían deshacer la tontería, probablemente habían molestado a los clientes, y deberían haber estado increíblemente molestos consigo mismos. Un VCS hace que sea mucho más fácil recuperarse de esos errores. Obviamente, para cualquier sitio personalizado dado, necesita la copia de seguridad (central) de la versión 'correcta' u 'oficial' de ese sitio disponible en el VCS. Probablemente vaya a buscar un único repositorio para todos los clientes, usando un VCS que tenga un buen soporte para la bifurcación y la fusión. Al principio puede ser más difícil tratarlo (mientras las personas se están acostumbrando a usar un VCS), pero probablemente conduzca a mejores resultados a largo plazo. Consideraría seriamente usar el VCS distribuido moderno (por ejemplo, git), aunque muchas personas también usan SVN (aunque no es un VCS distribuido).

Answer 2

puede utilizar tortuga cliente SVN para crear y trabajar con un repositorio en su máquina local en alguna otra ruta de archivo, entonces su ruta de trabajo es ....

quizás tratar de configurar y usar que por sí mismo y mostrar después de un tiempo, qué puede hacer por ti. Otra cosa interesante podría ser la instalación de trac (http://trac.edgewall.org/) en su servidor si tiene acceso y privilegios para hacerlo, o tal vez en alguna máquina virtual en su propia máquina de desarrollo. puede asignar trac a su svn y obtener cambios svn en la interfaz web que puede mostrar al administrador del proyecto. tal vez se enamore de eso, podrá ver cambios de código fácilmente a través de la interfaz web. por supuesto, puedes hacer eso solo con el módulo apache + svn, pero esto es más agradable ya que ofrece un camino a ticketing y roadmapping (hitos y cosas que los gerentes pueden cavar: o))

buena suerte de todos modos :) . al menos, úsalo para tu trabajo en tu máquina local ya que solo hay una ganancia para ti al hacer eso.

Answer 3

Puede instalar SVN en su sistema local para la demostración. Hay algunas herramientas para integrar Zend y Eclipse a SVN. Creo que además de hacer una demostración de SVN, probablemente debas darles una presentación de algunos de los beneficios que traerá (probablemente durante la demostración).

haga clic aquí para ver algunas ideas: Do I Really Need Version Control?

Answer 4

Ólafur, se menciona que "el estudio hace un sistema CMS que está alojada en cientos de sitios". Esto en sí mismo puede ser la zanahoria que necesitas. Si el equipo a menudo despliega actualizaciones en estos cientos de sitios, entonces usar ramas dentro de un sistema de control de versiones puede hacer que este proceso sea mucho más fácil para todos. Eso podría ser un gran ahorro de tiempo y, por lo tanto, proporcionaría un incentivo para que las personas aprendan el sistema de control de versiones.

Parece que todos estos sitios están relacionados: versiones personalizadas del mismo CMS. En ese caso, debe colocar todos los sitios en el mismo repositorio, además del producto CMS no personalizado. Luego puede configurarlos como ramas del mismo producto central. Si usa repositorios separados, no hay formas fáciles de crear ramas para relacionar las personalizaciones con el producto principal. (Creo que puede hacerlo con Subversion, y muy probablemente otros, pero esto es complicado e innecesario si todos los desarrolladores trabajan para la misma organización.)

Answer 5

VisualSVNServer y TurtoiseSVN son los dos programas que uso, que son a la vez bien documentado y se integra muy bien con Windows Explorer y Visual Studio.

Answer 6

Haga que la implementación forme parte de un proceso automatizado de "compilación" para que ningún desarrollador tenga que preocuparse por ello. Use 'streams' para mantener el trabajo en un área de desarrollo, un área de área de lanzamiento y luego tenga procesos automatizados que implementen los últimos entornos de desarrollo, qa y release.

Answer 7

Aquí hay un truco que cada uno amará:

que incluyen este 'plug-in' en la mayoría de mis centros de producción: Por supuesto, es necesario crear una cuenta de los derechos limitados robot SVN para este primer y SVN debe ser instalado en el servidor.

echo(' updating from svn<br>'); 
    $username = Settings::Load()->Get('svn','username'); 
    $password = Settings::Load()->Get('svn','password'); 
    echo(" <pre>"); 
    $repos = Settings::Load()->Get('svn' , 'repository'); 
    echo system ("svn export --username={$username} --password {$password} {$repos}includes/ ".dirname(__FILE__)."/../includes --force"); 
    echo system("svn export --username={$username} --password {$password} {$repos}plugins/ ".dirname(__FILE__)."/../plugins --force"); 

    die(); 

Asegúrese de poner esto detrás de un sitio .htpasswded por supuesto, y asegurarse de que no actualiza los ajustes de producción '' desde el SVN. Et voila, Actualiza su base de códigos completa con una consulta HTTP a su sitio :) SVN sobrescribe los archivos automáticamente, no hay archivos ocultos o carpetas dejados atrás y se adapta fácilmente para actualizar o volver a una versión específica. Ahora todo lo que su equipo necesita hacer es comprometerse con su repositorio SVN, ejecutar este código en el entorno de prueba, asegurarse de que todo funcione y luego ejecutarlo en producción :)

Answer 8

Simplemente ponga, por ejemplo, SVN en el medio.

El equipo de desarrollo puso las cosas nuevas en subversión, y luego tiene un script que exporta las cosas de svn y las envía al servidor web.

Esto es bastante parecido a la forma en que funcionan hoy en día, , pero cada pequeño cambio se ha registrado en subversión, por lo que si cae un rayo es posible retroceder todo a tiempo realmente rápido.

/Johan