Boss es escéptico de usar un sistema de control de versiones para un nuevo proyecto, ¿debería hacerlo de todos modos?

Consulte /software/109817/superior-refusing-to-use-subversion

Mi pregunta es similar, pero aquí están las principales diferencias en mi escenario:

• Estamos comenzando un nuevo proyecto desde cero, usando PHP y tecnología web. No habría tiempo de inactividad en el desarrollo, ya que lo estaríamos adoptando desde el principio, si tengo lo que quiero.

• Mi equipo de desarrollo está formado por mí y mi jefe. Somos el departamento de "TI" de una empresa relativamente pequeña.

La aplicación web reemplazará una aplicación heredada sin absolutamente ningún control de origen. Debido a las variaciones en los requisitos legales geográficos, se tomó la decisión (antes de ser contratado) de bifurcar la aplicación en 7 directorios completamente separados para cada versión. Diferentes desarrolladores hicieron cosas diferentes en diferentes lugares en diferentes momentos después de eso. Parchear los cambios entre ellos, bueno, creo que podría hacerse mejor, supongo que es por eso que estoy publicando.

La propuesta de mi jefe, directamente pegada desde un correo electrónico:

• Las actualizaciones deben enviarse como paquetes en la carpeta SUBMISSIONS. El paquete debe contener todos los archivos relevantes, así como un archivo 'UPDATE.NFO' que contiene una descripción de la actualización, una lista de todos los archivos nuevos incluidos (con descripciones) y una lista de todos los archivos modificados con detalles de modificación.

• Los paquetes de actualización deben centrarse en un elemento individual y no desviarse de su propósito previsto. El código debe estar diseñado para ser modular y reutilizable siempre que sea posible.

• Todos los paquetes enviados deben instalarse en el entorno de prueba de cada desarrollador poco después del envío. Cada desarrollador debe revisar la nueva incorporación y expresar cualquier inquietud sobre su instalación en el entorno de producción. Una actualización de paquete estándar debe realizarse durante un mínimo de 3 días hábiles para este proceso de revisión antes de cargarse en el entorno de producción. Las actualizaciones / correcciones de alta prioridad pueden omitir este requisito.

La razón por la cual se inventó el control de fuente es para hacer todo eso automático, ¿verdad? Sugerí subversión, porque eso es lo que usé en la universidad. A Boss no le gusta la subversión porque "Desordena el código" (es decir, usa magia binaria y no es legible). Lo intentamos una vez, pero creo que intentar usarlo en Windows produjo errores extraños en mayúsculas y minúsculas y no pudimos revisar nuestros archivos. No sé si es solo subversión o todos los productos de control de fuente que son objetables.

Entonces, ¿qué tipo de argumento debería hacerle a mi jefe? ¿O tiene razón, y podría existir el peligro de perder todo nuestro trabajo por algún error extraño?

¿O estoy completamente equivocado? ¿Es realmente necesario el control de la fuente en mi situación? Estamos hablando de nuestro principal software crítico para el negocio, por lo que terminará siendo enorme, sin duda. Pero solo hay 2 desarrolladores (ahora).

Además, si no puedo convencerlo, ¿tendría algún sentido que lo use solo para mí? Estoy hablando como alguien con experiencia muy limitada que en realidad usa svn; Todo lo que realmente sé es pagar y comprometerse. ¿Cuáles son las características del control de código fuente (pueden incluir otros productos además de svn) que ayudarían en mi esfuerzo de desarrollo individual?

Por favor no hay comentarios de "conseguir otro trabajo". Eso no es útil para el debate.

No le preguntes No le digas Muestrale.

Instale svn, o git, o lo que quiera en alguna máquina adicional. Practique usarlo usted mismo hasta que se sienta cómodo no solo usándolo, sino explicándolo. Si vas a hacer que se sienta cómodo con tu nuevo sistema, tendrás que sentirte más que cómodo con él. Tendrás que poder ayudarlo a recuperarse fácilmente cuando arruina una fusión o verifica algo en el lugar equivocado.

Cuando estés listo, muéstrale exactamente de qué estás hablando. Muéstrele que no "ensucia" nada. Señale que no solo le permite recuperar cualquier versión anterior de su código con facilidad, sino que también permite saber exactamente qué cambió entre dos versiones.

Señale que si alguna vez le sucede algo al servidor (error grave, virus, pirata informático, bloqueo de disco ...) , ambos se verán como héroes si pueden reconstruir instantáneamente la versión necesaria. Señale también que se verá el doble de bueno si puede producir cualquier versión a pedido. Busque en su correo electrónico anterior y compile una lista de problemas que haya tenido durante el año pasado que podría haber evitado con el control de versiones.

Dele una hoja de trucos que le facilitará el uso de su sistema de control de versiones.

Finalmente, sugiera algunas opciones, pero deje la decisión a él . ¿Debería configurar su propio servidor o utilizar uno de los muchos servicios alojados ? ¿Deberías usar svn, git u otra cosa? ¿Debería migrar los siete proyectos al sistema, o probarlo con uno o dos al principio?

Los beneficios del control de fuente van mucho más allá de permitir que múltiples desarrolladores trabajen en una sola pieza de código. Eric Sink, el fundador de SourceGear , enumera algunas razones convincentes para usar el control de código fuente como único desarrollador :

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

Eric también tiene un Tutorial de Control de Fuente para principiantes muy agradable . Hay un tutorial gratuito en línea de Mercurial disponible por Joel Spolsky, Mercurial es un popular sistema distribuido de control de versiones.

Como siguiente paso, le sugiero que comience a usar el control de origen localmente en su máquina, como desarrollador exclusivo. Muy pronto, su jefe se dará cuenta de que es capaz de hacer magia pura, como decirle en minutos, si no segundos, qué tan atrás va un error súper crítico y luego le dirá con precisión qué cuentas de clientes se vieron afectadas y necesitan repararse antes de todo. El infierno se desata. O poder deshacer cualquier cambio que el CEO desapruebe súper rápido.

Y finalmente, antes de intentar convencer a su jefe, es posible que desee profundizar en el tema del manejo de objeciones . Son 101 de ventas.

Si no tiene éxito, continúe tan pronto como sea posible, no tiene mucho sentido perder el tiempo inclinando los molinos de viento.

Sí, vale la pena usar el control de fuente, aunque solo sea para usted. Git, por ejemplo, funciona muy bien para un desarrollador independiente y le permite hacer cosas como ramificar y fusionar (con el menor costo posible) y modificar sus cambios a medida que avanza.

SVN, o cualquier sistema de control de versiones, realmente le permite hacer esto también, pero la fusión es un poco más problemática.

Si no puedo convencerlo, ¿tendría algún sentido que lo use solo para mí?

Si. Es beneficioso usarlo solo para usted. Obtiene el historial de cambios para que pueda ver qué es diferente.

No. No hay ningún beneficio porque su jefe ha condenado su proyecto a una gran cantidad de reelaboraciones inútiles porque ensuciaron las cosas.

Recomiendo altamente como se mencionó antes del uso de git, la razón # 1 es porque cualquier VCS es una red de seguridad en caso de desastre. Busque la etiqueta "En caso de incendio: git commit, git push, abandone el edificio". El código puede almacenarse en otro lugar, pero no en una computadora portátil que pueda averiarse, ser robada o lo que sea ... incluso un servidor de red local no es el lugar más seguro para algo tan valioso como el código.

Número 2. Trazabilidad de los cambios, quién hizo qué, cuándo, etc. Fusiones, deshacer. Número 3. Difunde la herramienta mágica para # 2 y muchos más casos. Número 4. Ramas Número 5. Etiquetado de versiones, lanzamientos, etc.

Puede encontrar más información sobre uno de los flujos de trabajo de git más comunes aquí: https://nvie.com/posts/a-successful-git-branching-model/

Sé que usar git puede ser intimidante al principio, pero es una buena inversión para una habilidad, y una necesidad para cualquier equipo de desarrollo.

Acerca de su problema con el caso de texto, evite usar Tortoise, sé que la mayoría de la gente lo usa como GUI para git, ya que era muy común para SVN, por lo que puede ser la primera opción, en su lugar use la línea de comandos u otra GUI como github desktop o el SourceTree de Atlasian.