Control de versiones; elecciones, elecciones, elecciones!

Nuestra configuration de la siguiente manera:

Tenemos un server de desarrollo local que ejecuta Ubuntu, con una configuration para reflejar la de nuestro host en vivo. Cada desarrollador trabaja en una máquina con Windows y accede a los files desde el server de desarrollo local.

Los proyectos en cuestión son una serie de sitios web creados en PHP. Dado que no hay buenas razones para no usar el control de versiones , tenemos la intención de activar SVN, Git, Mercurial u otra cosa en el server.

La pregunta es, ¿cómo hacemos eso, sino que le hacemos cambios desde las máquinas con Windows, y cómo revisamos un área terminada de un sitio (proyecto), o un sitio en su set, para cargarlo en vivo (remoto)? ¿server?

Por qué usar SVN:

  • Base de código madura
  • Herramientas de GUI maduras en Windows (si a su equipo le gustan): TortoiseSVN
  • Curva de aprendizaje más superficial (especialmente si ya has usado CVS)
  • Pagos parciales

Por qué usar git (probablemente también se aplica a mercurial):

  • Bifurcación y fusión más fáciles
  • Los desarrolladores pueden interactuar con su propio repository local sin necesidad de contactar al repository "maestro"
  • Puede trabajar con repositorys SVN o CVS en sentido ascendente (pero si tiene otra opción, seguiría usando git upstream si los desarrolladores están usando git)
  • Herramientas gráficas de Windows "lo suficientemente buenas" (TortoiseGIT puede ser tan bueno como TortoiseSVN ahora … no lo ha visto en un año o dos).
  • Comandos más potentes

Una forma de manejar su caso de uso es: – Cada desarrollador tiene su propio repository de git privado – Los desarrolladores envían cambios de código al repository del server de desarrollo cuando se testingn y están listos para su uso en producción. – El server en vivo tiene una salida que se actualiza en una progtwigción regular, se actualiza manualmente o se actualiza mediante un enlace de confirmación en el repository del server de desarrollo (cuando se confirma, "ssh live.server.com (cd / my / dir; git pull origin CABEZA)").

Este procedimiento también podría adaptarse para SVN, pero los repositorys privados simplemente se convertirían en cajas.

Subversion funcionaría maravillosamente. Tenemos Subversion ejecutándose en una máquina Linux y todo nuestro trabajo de desarrollo se realiza en máquinas Windows. El 90% de las veces controlamos los proyectos de input y salida a través de IDE (generalmente subclipse dentro de Eclipse) y el otro 10% de las veces que utilizamos TortoiseSVN, cualquiera de los cuales funcionará bien.

Puede enviar cambios al repository a través de IDE o Tortoise. Puede vincular un server de continuous integration con el repository para comstackr automáticamente el proyecto cuando se confirma un cambio de código en el repository.

Estamos utilizando Subversion con TortoiseSVN. Funciona bien. La última vez que miramos a Git (¿hace seis meses?), Las herramientas de Windows aún no estaban allí. Perforce ( http://www.perforce.com ) es la mejor solución comercial que he usado.

Asegúrese de comprender las diferencias del control de revisión distribuido (Git) versus Subversion y otros sistemas de control de revisiones tradicionales. Ellos no son lo mismo.

GitSvnComparison Git para diseñadores

Si está trabajando en sitios PHP, puede crear files tar del repository y enviarlos a un server de testing para realizar testings. Una vez que haya verificado que el sitio funciona, puede enviar ese file tar al sitio en vivo.

A less que malinterprete tu pregunta …

Cada uno de los proveedores de control de origen que ha mencionado tiene una versión de Windows o trabaja bajo cygwin, por lo que debe funcionar bajo Windows exactamente como lo haría bajo * nix; por lo tanto, debe basar su decisión en qué proveedor de control de origen utilizar con los mismos criterios como lo harías normalmente

Mercurial sería un gran ajuste. Con las máquinas de desarrollo basadas en Windows, obtienes mejor soporte y herramientas que git, pero terminas con un sistema más flexible que la subversión.

En nuestra configuration, servimos los repositorys a través de apache con mod_wsgi , que fue fácil de configurar, y nos ha servido muy bien.

Para el deployment, le aconsejo que mire los ganchos mercuriales si quiere que se hagan automáticamente.

Las máquinas con Windows deberían poder conectarse al server de control de cambios, no hay problema, usando el cliente de su elección (por ejemplo, TortoiseSVN para Windows).

Para hacer comstackciones automáticas desde su repository de origen, puede usar algún tipo de software de continuous integration (CI). No estoy familiarizado con ninguno de esos productos para la stack LAMP, pero estoy seguro de que hay muchos. Y, si se trata de PHP para la web, realmente no necesita una compilation, tanto como si necesitara algún tipo de copy automática 🙂

Cómo configuras las cosas dependerá un poco del software de control de origen que elijas.

Me gustaría configurar un repository central en un server interno. Esto es necesario para svn, y le brinda una location canónica para extraer los cambios si usa git o hg.

Los desarrolladores pueden verificar / clonar el repository en sus máquinas locales y volver a enviar / enviar los cambios. Sugeriría usar twigs para distinguir entre código de producción y código de desarrollo.

Para implementar en el website, tendría un process que verifica desde el depósito central, las actualizaciones en la twig de producción o la label, y luego copy los files en el server activo.

Los detalles exactos dependen en gran medida del sistema de control de versiones que utilice.

Creo que la respuesta fácil a su pregunta es: estos no son desafíos. Así es como funciona.

Usamos SVN aquí. La mayoría de los desarrolladores trabajan en Windows, pero nuestro grupo de testing usa Linux y nuestros serveres de producción son Linux.

Los desarrolladores revisan desde el repository SVN usando el plug-in SVN para Eclipse. También visité Windows usando TortoiseSVN y la línea de command de SVN. Cuando estamos listos para implementar en uno de los serveres de testing o producción, simplemente verificamos desde SVN en el server apropiado, comstackmos y terminamos. Con PHP, ni siquiera tiene el paso de compilation.

Para jugar con cosas que hago en casa, en casa es todo Windows, pero utilizo la línea de command SVN para administración, y luego Subcommander para hacer cosas en la estación de trabajo.

Si desea trabajar desde Windows, también le recomendaría echarle un vistazo a Bazaar , que tiene buenas herramientas de interfaz de usuario en todas las plataforms (incluida Windows). Una cosa buena de esto es que puede configurar fácilmente una twig de seguimiento y aún así trabajar localmente fuera de línea / bifurcar localmente, que es una especie de model híbrido distribuido / centralizado. Puede parecer bastante extraño al principio, pero en realidad es muy útil si tu equipo es pequeño. Siempre puedes utilizar la versión central para tu server de desarrollo y labelr / duplicar desde ella al sitio en vivo; mientras que cada uno de tus desarrolladores trabaja en copys locales y lo envía al server de desarrollo.