Hacer el cambio al control de fuente

La nuestra es una empresa bastante pequeña (3-4 programadores y 3-4 diseñadores de sitios) que desarrolla una aplicación web PHP de propósito único que proporciona la funcionalidad a más de 100 sitios web. Hemos operado durante un par de años en un entorno de desarrollo y producción separado que ha funcionado bastante bien. Siempre se han desarrollado suficientes características separadas para que los programadores nunca entren en conflicto y fue más conveniente trabajar sin el control de la fuente; a pesar de que tenía el riesgo de pérdida de datos y nuestra parte justa de archivos se perdió en un movimiento inadvertido.

La otra consideración es que nuestros diseñadores no son expertos en tecnología (les presenté el marcado html, en lugar de usar WYSIWYG). Esta ha sido una de las razones para dudar en hacer el cambio a las versiones.

Sin embargo, ahora que hemos llegado a más de 100 sitios y el equipo de desarrollo está creciendo, estoy tratando de estandarizar nuestros procedimientos y el control de la fuente parece un paso lógico en lo que respecta a los programadores. Espero que esto también acelere nuestras implementaciones de parches.

Desafortunadamente, tengo una experiencia muy limitada con la configuración de un sistema de control de fuente. Tengo curiosidad por saber de personas con una configuración similar o experiencia haciendo el cambio:

1) ¿Versiona todo (sitios, css, plantillas html y código de la aplicación) y obliga a los diseñadores a aprender versiones? ¿O son solo los desarrolladores los que trabajan en el código de la aplicación?

2) ¿Cuáles son algunas trampas a tener en cuenta al configurar inicialmente el control de fuente?

3) Implementación de dev => consejos de producción para el control de código fuente.

Gracias por toda su comprensión.

Edición 1: Dang. Todo el mundo hasta ahora recomienda controlar todo. Eso me hará perder el cabello temprano. Probablemente va a provocar una nueva pregunta en el futuro cercano. Gracias por el consejo hasta ahora, ¡sigan llegando!

Edición 2: muchas buenas respuestas, y analizaremos los diversos sistemas de control de versiones. ¡Gracias por las respuestas a todos!

Es útil tener todo versionado, incluso para diseñadores. Y si se implementa bien con una buena capacitación, creo que lo encontrarán más útil que pesado.

Si recién está comenzando, le sugiero que use un sistema de control de versiones distribuido como git o mercurial . Esta es la tendencia general en el mundo, y hay muchas ventajas. Es fácil trabajar en un modo desconectado, sin dependencia de la red y la capacidad de hacer trabajo privado sin pulir aún bajo control de versión, verificando todo de manera centralizada cuando esté listo.

Y, no recurrir a apelaciones a la autoridad ni nada, sino ver lo que Joel Spolsky tiene que decir sobre el tema . (Cita de elección: "Subversión = sanguijuelas. Mercurial y Git = antibióticos".) Entre otras cosas, destaca el punto interesante de que estos nuevos sistemas utilizan un nuevo modelo mental, diferente del control de versiones tradicional, razón por la cual entrar en este tipo de El enfoque desde el principio es una victoria.

Yo diría que poner todo bajo control de versiones. Una vez que todo funciona, puede copiarlo en una etiqueta que para la mayoría de los sistemas SCM no requiere mucho espacio en disco en el servidor.

En cuanto a los escollos iniciales, no debería tener que preocuparse demasiado; compromete todo al servidor y, si no es correcto, puedes mezclarlo y eliminar el contenido adicional más adelante. Lo único que no cometería son los artefactos que se crean desde la fuente, es decir, los archivos de código Java pertenecen al control de versiones, pero no las clases compiladas o los ISO / DVD completos de los binarios "construidos desde la fuente".

Desarrollar la producción es fácil, en cada hito importante crear una sucursal. El diseño del directorio en el sistema de control de versiones generalmente se parece a:

/ tronco / proyecto / sucursales / proyecto / versión1 / sucursales / proyecto / versión2 / sucursales / proyecto / versión3

Digamos que encuentra un error en la versión 2 del producto, navega a esa rama, lo arregla y lanza la versión 2.1. Mientras trabajas en la carpeta / trunk / project para la nueva versión 4 y depende de ti qué características se combinan hacia adelante y hacia atrás.

No dejes que los bebedores de Kool-aid SCM te engañen, hay muy pocas diferencias funcionales entre los sistemas de control de versiones populares, a saber, Subversion y Git. Lo más importante para su equipo será qué tan bien se integran esos servidores con sus herramientas existentes. Tampoco me gustan los WYSIWYG, pero seguro que es bueno tener eclipse-php u otros IDE que sean compatibles con el servidor.

Soy desarrollador y he estado involucrado en trabajar como administrador de TI antes.

Para responder a sus preguntas específicas:

1) Sí, versionar todo.

2) Sugiero que configure un repositorio ficticio de control de versiones y un proyecto ficticio para que la gente aprenda.

3) Etiquete las versiones que se ponen en producción. incluso las pruebas. Luego, siempre puede consultar una versión específica que alguien está ejecutando.

Veo que has etiquetado la pregunta CVS.

Mi sugerencia es considerar seriamente la subversión, combinada con TortoiseSVN, lo que hace que sea muy fácil de usar. También hay un TortoiseCVS también.

Le sugiero que ejecute un tutorial interno sobre el control de versiones. Me sorprendería si sus desarrolladores / diseñadores no se han encontrado con esto antes. Tortoise solo lo hace muy fácil de usar.

También puede ser beneficioso instalar una de las interfaces web en cvs o subversion.

La razón por la que sugiero subversión sobre CVS es que si bien CVS es muy bueno, tiene algunos problemas serios de diseño e implementación. Lo más importante para mí fueron: 1) No se pueden versionar directorios 2) El manejo de archivos binarios no es demasiado bueno ya que muchas cosas son texto por defecto. 3) Sin compromisos atómicos. 4) Recuerdo que a menudo se equivoca y deja archivos de bloqueo que tuve que eliminar manualmente del almacén de códigos. Había espacio para la corrupción al hacer esto, ya que su rm los archivos de bloqueo. 5) Soporte SSL y gestión de usuarios / contraseñas

Subversion básicamente soluciona todos esos problemas, probablemente son muchos otros. También tiene muchas características avanzadas como externas (que en realidad uso). Y es posible vincular los usuarios / grupos en el directorio activo que puede resultarle útil. En ese momento usé CVS que no estaba disponible. Puede ser ahora, no lo he comprobado.

Probablemente la mayor diferencia para entender svn al usarlo es que no creas etiquetas. En su lugar, crea lo que parecen ser copias donde el directorio del proyecto se copia en la carpeta Etiquetas y se le asigna un nombre. Echa un vistazo a la documentación y verás a qué me refiero. Sé que se ve raro, pero te acostumbras.

Este sitio web puede ser de algún beneficio (aunque no puedo garantizarlo): Configuración de un repositorio svn modular para sitios web php http://www.howtoforge.com/set-up-a-modular-svn-repository-for -php-sitios web

Con gran respeto a gran parte de la sabiduría que aparece arriba, y es sabio, la implementación del control de versiones es como la implementación de los sistemas de monitoreo. Mis clientes dicen "qué debo monitorear", y la respuesta obvia es "monitorear todo". Pero esta no es una buena noticia: tienen 350 sistemas, cada uno de los cuales tiene entre 20 y 30 variables del sistema, además de un montón de variables específicas de uso, y todos pueden ser monitoreados de manera útil; pero solo hay uno de mí, y les gustaría ver algunos resultados dentro de quince días.

Entonces, aunque estoy de acuerdo en que la mejor práctica es controlar todo la versión, si esto no es práctico en primera instancia, comience por controlar aquellas cosas cuya falta de control le ha causado la mayoría de los problemas hasta ahora .

Si la mayoría de las interrupciones son causadas por el código de la aplicación, comience por controlar eso; si la mayoría son parches CSS no planificados, controle eso; y así.

Esto no solo le dará el mejor retorno de la inversión de tiempo, sino que también le dará razones sólidas para extender el uso del control de versiones en el futuro: "Dado que agregamos el control de versiones al código de la aplicación, interrupciones no planificadas durante 30 minutos han caído de 11 al mes a 2. Esos dos fueron causados ​​por cambios estáticos de HTML, por lo que tenemos la intención de controlar la versión de los siguientes ".

Una implementación gradual también le brinda usuarios expertos dentro de la organización. Sí, tenía que enseñar a los seis desarrolladores de aplicaciones cómo usar el sistema, pero aprendieron y están de acuerdo; ahora que es hora de implementar el sistema en el equipo CSS, tiene seis expertos internos más que hace tres meses. Incluso puede tener conversos en este momento; un desarrollador al que le hayan salvado el culo por la capacidad de retroceder rápidamente un cambio dañino puede ser su mejor evangelista para el equipo de CSS.

Edición 1: si decide ir por esta ruta, un tope económico es agregar un cable trampa en la parte superior, al menos en una caja de producción. De esa manera, si las cosas se rompen pero el VCS dice que no era nada de lo que actualmente es responsable, puede identificar rápidamente lo que ha cambiado, lo que acelera la solución y sugiere su próximo candidato para el control de versiones.

La versión controla todo. No tiene sentido tener archivos HTML bajo control de versiones y luego tener un sitio completamente atornillado debido a un cambio en CSS que no se está controlando y, por lo tanto, no se puede revertir fácilmente.

Errores: personalmente no me he encontrado con ninguno durante mi uso ciertamente limitado del control de versiones.

Implementación: Actualmente uso subversion alojado en cajas de Windows, tanto en el trabajo como en casa. Windows solo porque eso es lo que está disponible. De lo contrario, podría haber sido fácilmente otro sistema operativo. La clave para los usuarios no tecnológicos es darles una herramienta simple basada en GUI para manejar importaciones, exportaciones, confirmaciones, diferencias, etc. La herramienta que se utilizará dependerá un poco del sistema operativo y el sistema VCS utilizado.

Uso: cuando realizo cambios en el código, pruebo y confirmo con frecuencia. Esto me permite volver tan lejos como sea necesario cuando me equivoco. Además, al comparar varias revisiones y copiar partes del código, no tengo que perder todos los cambios solo porque necesito volver a una versión anterior para arreglar algunas cosas en otra parte del código.

Beneficio adicional: puede dar acceso al repositorio de origen a través de una VPN o conexión segura, lo que permite a los usuarios trabajar desde casa o en otro lugar. Por ejemplo, podría tener una idea en casa y editar mi código de trabajo allí y luego, antes de perder el pensamiento.

Versión de todo.

La implementación depende de cuánto tiene que "personalizar" para cada uno de estos sitios. Si son idénticos, excepto por un archivo de configuración o dos, simplemente puede retirar una copia del código y hacer pequeños cambios. Según sea necesario, ejecute el comando de actualización de su control de versiones para cada uno de los clientes.

Si utiliza el modelo de distribución "pagar directamente en el sitio del cliente", querrá asegurarse de que su servidor excluya el acceso a los directorios de control de versiones para que las personas no puedan navegar a http://example.com/. git / y echa un vistazo a tus partes internas. Además, definitivamente tendría un host virtual de prueba y producción para cada cliente para asegurarme de que una actualización del sitio no se vuelva loca. Especialmente si está realizando cambios personalizados en los archivos de clientes individuales, entonces deberá manejar los conflictos antes de que los cambios se activen. En este caso, pagaría / actualizaría el host virtual de prueba, y cuando todo funcione correctamente, copiaría el host virtual de prueba al host virtual de producción.

Todo lo que la gente dice sobre qué versión es buena.

Si decides utilizar Subversion, ¿puedo recomendar probar la pila de Bitnami Trac? http://bitnami.org/stack/trac

Simplifica la configuración de la subversión para usted, viene con un sistema de tickets (que puede elegir usar en esta etapa o no) para realizar un seguimiento de los cambios y errores, y un wiki que puede usar para documentar cómo desea que usen sus desarrolladores el sistema.

Dele a todos sus desarrolladores de Windows TortoiseSVN. Enseñe a todos algunos conceptos básicos de la línea de comandos de svn.

Al final del día, la herramienta es menos importante que la mentalidad que necesita inculcar en sus desarrolladores. Esperemos que pronto vean que el control de versiones es una buena cosa, ya que les impide perder el trabajo y les permite volver de los callejones sin salida que no los llevan a ningún lugar a los buenos estados conocidos. Los beneficios superan la sobrecarga (leve).